Azure Security Fundamentals

Module 1 – Microsoft Defender for Cloud

Definition

• CNAPP (Cloud Native Application Protection Platform): unified platform for cloud security.
• Covers Azure, AWS, and GCP (multi-cloud).
• Two main functions:
  • CSPM (Cloud Security Posture Management): assess and improve security posture.
  • CWP (Cloud Workload Protection): protect workloads (VMs, containers, databases).

Secure Score

• Score from 0 to 100% representing the security posture.
• Based on implemented recommendations.
• Each recommendation has a potential impact (points).

Secure Score: 62/100
  Recommendations:
  ├── [High]   Enable MFA for admin accounts (+15 points)
  ├── [Medium] Encrypt VM disks (+8 points)
  └── [Low]    Enable boot diagnostics (+3 points)

Defender Plan Levels

Module 2 – Encryption in Azure

Encryption at Rest

Key concepts:

Data → encrypted with DEK (Data Encryption Key)
DEK  → encrypted with KEK (Key Encryption Key)
KEK  → stored in Azure Key Vault

Key management types:

Algorithm: AES-256 (industry standard).

Azure Portal → Storage Account → Encryption → Key type
  → Microsoft-managed keys (default)
  → Customer-managed keys → Key Vault + selected Key

Encryption in Transit

TLS/HTTPS:

• All Azure communications are encrypted via TLS 1.2+.
• Azure services exposed on HTTPS only (App Service, Functions, etc.).
• Minimum TLS version: configurable (enforce 1.2 at minimum).

Data link layer encryption:

• Between Microsoft datacenters: automatic encryption of physical traffic.
• Protection against physical interception on cables.

Module 3 – Microsoft Sentinel

Definition

• Cloud-native SIEM (Security Information and Event Management).
• Collects, analyzes, and responds to security incidents.

Architecture

Data sources                    Microsoft Sentinel
  ├── Microsoft Defender     →  Data Connectors
  ├── Azure Active Directory  →  Log Analytics Workspace
  ├── Office 365             →  Analytics Rules
  ├── AWS/GCP Events         →  Incidents
  └── Third-party (Cisco, Palo) → SOAR (Playbooks → Logic Apps)

Key Components

Playbook Example

Incident "Suspicious Sign-In"
  → Logic App triggered
    ├── Notify security team (email/Teams)
    ├── Block user in Entra ID
    └── Create a ServiceNow ticket

Module 4 – Regulatory Compliance

Azure Policy

• Azure service to enforce rules and standards on resources.
• Continuous evaluation → non-compliant resources identified.
• Can block non-compliant deployments (Deny effect).

Azure Policy → Assign Policy
  Scope: Subscription or Resource Group
  Policy: "Storage accounts should use encryption"
  Effect: Deny (prevents creating unencrypted accounts)

Regulatory Compliance Dashboard

Microsoft Defender for Cloud → Regulatory Compliance
  ├── Microsoft Cloud Security Benchmark (MCSB)
  ├── PCI-DSS 3.2.1
  ├── HIPAA/HITRUST
  ├── NIST SP 800-53
  └── ISO 27001

• Each standard divided into controls.
• Each control linked to assessments (compliant or non-compliant resources).
• Compliance score per standard.

Compliance Manager (Purview)

• Cross-Microsoft tool (Azure + Microsoft 365 + Dynamics).
• Compliance actions assignable to individuals.
• Overall compliance score for the organization.

Summary

Extended Sections – Azure Security Deep Dive

Section A – Microsoft Defender for Cloud (Deep Dive)

Security Posture and Secure Score

The Secure Score is the central measure of security posture in Defender for Cloud. It reflects the percentage of applied recommendations out of the total weighted available.

Secure Score = (Points earned / Maximum possible points) × 100

Example:
  Max points    : 241
  Points earned : 149
  Secure Score  : 61%

Each recommendation belongs to a Security Control. Implementing all recommendations in a control grants that control’s points.

CSPM vs CWPP

flowchart LR
    subgraph CSPM["CSPM – Posture Management"]
        A[Configuration assessment] --> B[Recommendations]
        B --> C[Secure Score]
        C --> D[Attack Path Analysis]
    end
    subgraph CWPP["CWPP – Workload Protection"]
        E[Defender for Servers] --> F[Runtime alerts]
        G[Defender for Containers] --> F
        H[Defender for SQL] --> F
        F --> I[Incidents]
    end
    CSPM --> J[Microsoft Defender for Cloud]
    CWPP --> J

Defender Workload Plans

Alert Suppression and Workflow Automation

Alert suppression: rules to hide known false positives to reduce noise.

Defender for Cloud → Security Alerts
  → Create suppression rule:
    ├── Rule name    : "Test-VM-Pentest"
    ├── Reason       : Planned test/maintenance
    ├── Scope        : Subscription / Resource group
    ├── Target alert : "Suspicious PowerShell cmdlets"
    └── Duration     : 7 days

Workflow automation: integration with Logic Apps to automatically respond to alerts or recommendations.

Trigger: "High" severity alert created
  → Logic App triggered:
    ├── Send email to SOC team
    ├── Post a Teams message
    ├── Create an incident in ServiceNow
    └── Launch an Azure Automation runbook (auto-remediation)

Regulatory Compliance Dashboard

Compliance in Defender for Cloud is assessed continuously. Each standard is broken down into controls, which are in turn linked to resource assessments.

Standard: PCI-DSS 3.2.1
  ├── Control 1.1 – Firewall standards
  │     ├── Assessment: NSG configured ✓
  │     └── Assessment: Unnecessary ports closed ✗
  ├── Control 3.4 – Cardholder data encryption
  │     └── Assessment: SQL encrypted ✓
  └── Control score: 67%

Section B – Microsoft Sentinel (Deep Dive)

Complete SIEM + SOAR Architecture

flowchart TD
    subgraph Sources["Data Sources"]
        A1[Microsoft Defender XDR]
        A2[Microsoft Entra ID]
        A3[Office 365 / M365]
        A4[Azure Activity Log]
        A5[AWS / GCP via connectors]
        A6[Network devices – Cisco, Palo Alto]
        A7[Endpoints – Syslog, CEF]
    end

    subgraph Sentinel["Microsoft Sentinel"]
        B1[Data Connectors]
        B2[Log Analytics Workspace]
        B3[Analytics Rules]
        B4[Incidents & Alerts]
        B5[Workbooks]
        B6[Threat Hunting KQL]
        B7[UEBA]
        B8[Playbooks – Logic Apps]
    end

    Sources --> B1 --> B2
    B2 --> B3 --> B4
    B2 --> B5
    B2 --> B6
    B2 --> B7
    B4 --> B8

Data Connectors

Data connectors ingest logs from various sources using different mechanisms:

Analytics Rules – Types

KQL Rule Example – Suspicious Sign-ins

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != "0"  // Sign-in failures
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)
| where FailedAttempts > 10
| project TimeGenerated, UserPrincipalName, IPAddress, FailedAttempts
| order by FailedAttempts desc

Incidents and Severity

Incident: "Multiple failed sign-ins followed by successful login"
  ├── Severity    : High
  ├── Status      : Active
  ├── Alerts      : 3 correlated alerts
  ├── Entities    : User: j.doe@contoso.com, IP: 192.168.x.x
  ├── Tasks       : Review post-login activities
  └── Assigned to : SOC Analyst Tier 2

UEBA – User and Entity Behavior Analytics

The UEBA module builds behavior profiles for each user and entity (machine, application). It detects abnormal deviations.

• Analyzes sign-in logs, Azure AD activities, resource access.
• Assigns an investigation priority score to each user.
• Identifies compromised accounts, malicious insiders, lateral movements.

User: alice@contoso.com
  Investigation Priority Score: 87/100 (High)
  Detected anomalies:
    ├── Login from unusual country (Russia)
    ├── Abnormal download volume (+500% vs baseline)
    └── Access to sensitive resources never accessed before

Workbooks

Sentinel workbooks are interactive dashboards built on Azure Monitor Workbooks. They allow visualizing:

• Incident trends over time
• Geolocation of sign-ins
• Data connector status
• Threat hunting results

Threat Hunting

Threat hunting is a proactive approach: the analyst formulates a hypothesis and searches logs for evidence of compromise before an alert is triggered.

Hypothesis: "An attacker is exfiltrating data via DNS"
  KQL Query:
    DnsEvents
    | where Name endswith ".ru" or Name endswith ".xyz"
    | summarize count() by Name, ClientIP
    | where count_ > 100
    | order by count_ desc

Playbooks (Logic Apps)

Playbooks automate responses (SOAR). They are triggered on alerts or incidents.

Playbook: "Auto-Block-Suspicious-IP"
  Trigger  : Sentinel incident created (severity ≥ Medium)
  Actions  :
    1. Extract the IP from the incriminated entity
    2. Call Azure Firewall API → add blocking rule
    3. Send Teams notification to SOC
    4. Add comment to Sentinel incident
    5. Change incident status → "In Progress"

Section C – Azure Key Vault (Deep Dive)

Types of Managed Objects

flowchart LR
    KV[Azure Key Vault] --> S[Secrets]
    KV --> K[Keys]
    KV --> C[Certificates]

    S --> S1[DB connection strings]
    S --> S2[Passwords, API keys]
    S --> S3[OAuth tokens]

    K --> K1[RSA 2048/3072/4096]
    K --> K2[EC P-256/P-384]
    K --> K3[AES symmetric keys]

    C --> C1[X.509 Certificates]
    C --> C2[DigiCert / GlobalSign integration]
    C --> C3[Automatic renewal]

Access Policies vs RBAC

Two access control models for Key Vault:

Key Vault Built-in RBAC Roles:

Soft Delete and Purge Protection

• Soft Delete: logical deletion — objects are retained 7 to 90 days (default: 90 days) before permanent deletion. Enabled by default since 2021.
• Purge Protection: prevents permanent purging during the retention period. Critical for CMK (if the key is purged, data is unrecoverable).

az keyvault update \
  --name myVault \
  --enable-soft-delete true \
  --enable-purge-protection true \
  --retention-days 90

Managed HSM

Azure Managed HSM is a fully managed, single-tenant (dedicated), FIPS 140-2 Level 3 compliant service for high-security use cases.

Key Vault References in App Service and Functions

Key Vault References allow applications to access secrets without storing the value in the application configuration.

# Application Setting in App Service
ConnectionString = @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/DBConn/version)

# Or with the current version (no fixed version)
ConnectionString = @Microsoft.KeyVault(VaultName=myvault;SecretName=DBConn)

The application must have a Managed Identity with the Key Vault Secrets User role.

Private Endpoints for Key Vault

By default, Key Vault is accessible via the Internet (with authentication). For strictly private access:

Key Vault → Networking → Private endpoint connections
  → Create a private endpoint
    ├── VNet: production-vnet
    ├── Subnet: private-endpoints-subnet
    └── DNS integration: privatelink.vaultcore.azure.net

Then: Key Vault → Networking → Firewalls
  → "Allow trusted Microsoft services": Yes
  → "Public network access": Disabled

Section D – Azure DDoS Protection

Basic vs Standard

Adaptive Tuning

Adaptive tuning automatically builds normal traffic profiles for each protected public IP. Mitigation thresholds are dynamically adjusted.

Public IP: 52.x.x.x (Application Gateway)
  Normal baseline:
    ├── Packets/s  : ~50,000 pps
    ├── Bps       : ~200 Mbps
    └── Connections: ~5,000 CPS

  During a DDoS attack:
    ├── Detected traffic: 2,000,000 pps (× 40 baseline)
    ├── Mitigation automatically activated
    └── Legitimate traffic: uninterrupted pass-through

DDoS Metrics and Alerts

Azure Monitor → Metrics → Public IP address
  Available metrics under DDoS Protection Standard:
    ├── Under DDoS attack or not          (0/1 – critical alert)
    ├── Inbound packets dropped DDoS      (blocked packets)
    ├── Inbound packets forwarded DDoS    (legitimate traffic passed)
    ├── Inbound bytes DDoS                (total volume)
    └── TCP bytes dropped DDoS

Protected Attack Layers

flowchart TD
    A[Incoming DDoS attack] --> B{OSI Layer}
    B --> C[L3/L4 – Volumetric\nEx: UDP flood, ICMP flood]
    B --> D[L4 – Protocol\nEx: SYN flood, Smurf attack]
    B --> E[L7 – Application\nEx: HTTP flood, Slowloris]

    C --> F[DDoS Standard – Automatic protection]
    D --> F
    E --> G[DDoS Standard + WAF\nAzure Application Gateway / Front Door]

DDoS Attack Simulation

Microsoft allows DDoS testing via approved partners (BreakingPoint Cloud, Red Button). The request must be submitted before the test.

Microsoft-approved partners for DDoS testing:
  ├── BreakingPoint Cloud – https://breakingpoint.cloud
  └── Red Button          – https://red-button.net

Process:
  1. Contact the partner
  2. Define the target IP and attack type
  3. Test → observe Azure Monitor metrics
  4. Analyze the post-test attack report

Section E – Microsoft Entra ID (Azure Active Directory)

Fundamental Concepts

flowchart TD
    T[Entra ID Tenant\ncontoso.onmicrosoft.com] --> U[Users]
    T --> G[Groups]
    T --> A[App Registrations]
    T --> SP[Service Principals]
    T --> MI[Managed Identities]

    U --> U1[Members – internal]
    U --> U2[Guests – B2B]

    G --> G1[Security]
    G --> G2[Microsoft 365]
    G --> G3[Dynamic – auto rules]

    A --> SP
    MI --> MI1[System-assigned identity]
    MI --> MI2[User-assigned identity]

Users and Groups

App Registrations and Service Principals

• App Registration: the application’s registration in Entra ID. Defines the app’s identity (client ID, API permissions).
• Service Principal: the instance of the application in a specific tenant. This is the object that receives RBAC permissions.

App Registration: "MyApp"
  Client ID  : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  Permissions: Microsoft Graph – User.Read

  → Service Principal automatically created in the tenant
    → Can receive Azure RBAC roles (e.g.: Contributor on a RG)

Managed Identities

Managed Identities allow an Azure resource to authenticate with other services without storing credentials in code.

# Example: VM accessing Key Vault without a password
  1. Enable Managed Identity on the VM (system-assigned)
  2. Grant the "Key Vault Secrets User" role to the identity
  3. In the VM's code:
     credential = ManagedIdentityCredential()
     client = SecretClient(vault_url, credential)
     secret = client.get_secret("DBPassword")
  → No credentials stored in code or config

Conditional Access

Conditional Access is Entra ID’s access decision engine. It evaluates signals to grant or block access.

flowchart LR
    Signals[Input signals] --> CA[Conditional Access Engine]
    CA --> Decision{Decision}
    Decision --> Allow[Allow]
    Decision --> MFA[Require MFA]
    Decision --> Block[Block]
    Decision --> Compliant[Require compliant device]

    Signals --> S1[User / Group]
    Signals --> S2[Location / IP]
    Signals --> S3[Platform / Device]
    Signals --> S4[Target application]
    Signals --> S5[Entra ID Protection risk score]

Conditional Access policy examples:

MFA – Multi-Factor Authentication

MFA adds an authentication layer beyond the password.

Privileged Identity Management (PIM)

PIM enables Just-In-Time (JIT) access: administrators only have elevated rights when they need them, for a limited duration.

Without PIM:
  alice@contoso.com → "Global Administrator" role (permanent)

With PIM:
  alice@contoso.com → "Global Administrator" role (eligible)
    → JIT Activation:
        ├── Max duration: 4 hours
        ├── Required justification: "Planned maintenance"
        ├── Approval required: manager
        └── MFA required at activation

Section F – Identity and Access – Core Principles

Least Privilege

The principle of least privilege states that a user, service, or system should only have the permissions strictly necessary to accomplish their task.

❌ Bad practice:
  Developer → "Owner" role on the subscription

✓ Good practice:
  Developer → "Contributor" role on their Resource Group only
  CI/CD pipeline → "Contributor" role on the target RG only
  App Service → Managed Identity with "Key Vault Secrets User" only

Zero Trust – Zero Trust Model

Zero Trust is based on the principle: “Never trust, always verify”.

Identity Governance

Access Review:
  Resource  : "Finance-Admins" group
  Frequency : Quarterly
  Reviewers : Members' managers
  If no response: access automatically revoked

Section G – Encryption in Azure (Deep Dive)

Encryption at Rest – Key Hierarchy

flowchart TD
    Data[Data\nBlob, Disk, SQL...] -->|Encrypted with| DEK[DEK\nData Encryption Key\nAES-256]
    DEK -->|Encrypted with| KEK[KEK\nKey Encryption Key\nRSA-2048+]
    KEK -->|Stored in| KV[Azure Key Vault\nor Managed HSM]
    KV -->|Controlled by| Customer[Customer\nCMK]
    KV -.->|Alternative| Microsoft[Microsoft\nPMK]

Storage Service Encryption (SSE) is enabled by default on all Azure storage accounts. AES-256, transparent, no performance impact.

Azure Disk Encryption (ADE) encrypts the OS and data disks of VMs.

• Windows: uses BitLocker.
• Linux: uses DM-Crypt.
• Keys stored in Azure Key Vault.

az vm encryption enable \
  --resource-group myRG \
  --name myVM \
  --disk-encryption-keyvault myVault \
  --volume-type All

Encryption in Transit – Protocols and Standards

flowchart LR
    Client[Client Browser\nMobile App] -->|TLS 1.2 / 1.3\nHTTPS| AppGW[Application Gateway\nFront Door]
    AppGW -->|TLS backend\nHTTPS| AppSvc[App Service\nAKS\nVMs]
    AppSvc -->|TLS 1.2+\nSMB 3.x| Storage[Azure Storage\nAzure SQL\nKey Vault]
    DC1[Azure Datacenter A] -->|Data Link Encryption\nMACsec| DC2[Azure Datacenter B]

Minimum TLS configuration on App Service:

Azure Portal → App Service → TLS/SSL settings
  → Minimum TLS Version : 1.2 (recommended)
  → HTTPS Only          : On (HTTP → HTTPS redirect)
  → Client Certificate  : Optional / Required (mTLS)

Azure Confidential Computing

Confidential Computing protects data in use, meaning during processing in memory. Uses hardware Trusted Execution Environments (TEE).

Section H – Azure RBAC (Deep Dive)

Scope Hierarchy

flowchart TD
    MG[Management Group] --> Sub[Subscription]
    Sub --> RG[Resource Group]
    RG --> R[Individual Resource]

    MG -.->|Role assigned here\ninherited in cascade| Sub
    Sub -.->|Inheritance| RG
    RG -.->|Inheritance| R

Role assignments propagate downward in the hierarchy. A role assigned at the Management Group level applies to all subscriptions, resource groups, and resources below.

Main Built-in Roles

Common specialized roles:

Custom Roles

When built-in roles are too broad, create a custom role with exactly the needed permissions.

{
  "Name": "VM Start/Stop Operator",
  "Description": "Can start and stop VMs only",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId}"
  ]
}

Control Plane vs Data Plane Difference

Section I – Azure Policy (Deep Dive)

Azure Policy Components

flowchart TD
    PD[Policy Definition\nSingle JSON rule] --> I[Initiative\nInitiative Definition\nGrouping of Policy Definitions]
    I --> A[Assignment\nAssignment to a scope]
    A --> E[Evaluation\nResource assessment]
    E --> CR[Compliance Report]
    E --> RT[Remediation Task\nAutomatic remediation]

Policy Effects

Common Policy Examples

Policy: "Storage accounts should use TLS 1.2"
  Type  : Built-in
  Effect: Deny
  Scope : Subscription
  Action: Blocks creating a storage account with TLS < 1.2

Policy: "Deploy Log Analytics agent for VMs"
  Type  : Built-in
  Effect: DeployIfNotExists
  Action: Automatically deploys the agent if missing

Policy: "Allowed locations"
  Type     : Built-in
  Effect   : Deny
  Parameter: ["eastus", "westeurope", "canadacentral"]
  Action   : Blocks deployment outside authorized regions

Initiatives (Policy Sets)

An initiative groups multiple policy definitions to achieve a common goal.

Remediation Tasks

Some policies with DeployIfNotExists or Modify effects can trigger remediation tasks on existing non-compliant resources.

Azure Portal → Policy → Remediation
  → Create a remediation task:
    ├── Policy     : "Deploy Defender for SQL on SQL VMs"
    ├── Scope      : Subscription
    ├── Locations  : All
    └── Re-evaluate compliance: Yes

  → Result:
    ├── Resources evaluated : 47
    ├── Resources remediated : 12
    └── Resources failed     : 2 (permission error)

Section J – Shared Responsibility Model

Responsibility Matrix

Reading the table:

• IaaS (e.g.: Azure VM): Microsoft manages hardware and virtualization. The customer manages the OS, runtime, application, and data.
• PaaS (e.g.: App Service, Azure SQL): Microsoft manages up to the OS and runtime. The customer focuses on application and data.
• SaaS (e.g.: Microsoft 365, Dynamics): Microsoft manages everything except customer data and user access management.

Practical Implications

Scenario: SQL database exposed on the Internet
  Microsoft layer: Secure network infrastructure ✓
  Customer layer : SQL firewall not configured ✗
                   Default admin password ✗
  → Breach = CUSTOMER responsibility

Scenario: CMK encryption key accidentally deleted
  Microsoft layer: Key Vault available ✓
  Customer layer : Purge protection not enabled ✗
                   Data unrecoverable
  → Data loss = CUSTOMER responsibility

Section K – Zero Trust Architecture

Core Principles

Zero Trust does not trust any network or user by default, even inside the enterprise perimeter.

flowchart TD
    subgraph ZeroTrust["Zero Trust – Three Pillars"]
        V[Verify Explicitly]
        LP[Least Privilege Access]
        AB[Assume Breach]
    end

    subgraph Signals["Evaluation Signals"]
        U[User identity\nEntra ID + MFA]
        D[Device health\nIntune Compliance]
        L[Location\nIP / Country]
        A[Target application\nData classification]
        R[Risk Score\nEntra ID Protection]
    end

    subgraph Controls["Applied Controls"]
        CA[Conditional Access]
        PIM2[PIM – JIT Access]
        NSG2[Network segmentation\nNSG / Firewall]
        ENC[End-to-end encryption]
        MON[Continuous monitoring\nSentinel + Defender]
    end

    Signals --> ZeroTrust
    ZeroTrust --> Controls

Traditional Model vs Zero Trust

Zero Trust Implementation in Azure

Identity Layer:
  ├── Entra ID + MFA (phishing-resistant FIDO2)
  ├── Conditional Access – all applications
  └── PIM – privileged access JIT only

Network Layer:
  ├── Microsegmentation – NSG per subnet
  ├── Azure Firewall – inbound/outbound traffic inspection
  └── Private Endpoints – PaaS services on private network

Application Layer:
  ├── WAF (Application Gateway / Front Door)
  ├── API Management – authentication, rate limiting
  └── Managed Identities – no credentials in code

Data Layer:
  ├── Encryption at rest – CMK for sensitive data
  ├── Encryption in transit – TLS 1.2+ everywhere
  └── Purview – data classification and protection

Monitoring Layer:
  ├── Microsoft Defender for Cloud – posture + alerts
  ├── Microsoft Sentinel – SIEM/SOAR
  └── Azure Monitor + Log Analytics – centralized logs

Section L – Review Questions

Multiple Choice Questions

Question 1: Which score measures overall security posture in Microsoft Defender for Cloud?

• A) Compliance Score
• B) Security Index
• C) Secure Score ✓
• D) Risk Score

Question 2: What is the main difference between CSPM and CWPP in Defender for Cloud?

• A) CSPM protects workloads, CWPP assesses posture
• B) CSPM assesses and improves security posture, CWPP protects workloads in real time ✓
• C) They are two names for the same service
• D) CSPM is free, CWPP is always paid

Question 3: In Azure Key Vault, which feature prevents the permanent deletion of a key during the retention period?

• A) Soft Delete only
• B) Purge Protection ✓
• C) Private Endpoint
• D) RBAC

Question 4: An App Service application needs to access a Key Vault secret without storing credentials in the code. What is the best approach?

• A) Store the secret in environment variables
• B) Use an App Registration with a client certificate
• C) Enable a Managed Identity and use a Key Vault Reference ✓
• D) Base64-encode the secret in the code

Question 5: What encryption mechanism is used between Microsoft datacenters for physical network traffic?

• A) TLS 1.3
• B) IPSec VPN
• C) Data Link Layer Encryption (MACsec) ✓
• D) SMB 3.0

Question 6: In the shared responsibility model, who is responsible for configuring the firewall of an Azure VM (IaaS)?

• A) Microsoft
• B) The customer ✓
• C) Both share this responsibility
• D) Nobody – it’s automatic

Question 7: Which Microsoft Sentinel feature detects abnormal user behaviors based on their historical habits?

• A) KQL Analytics Rules
• B) UEBA (User and Entity Behavior Analytics) ✓
• C) Data Connectors
• D) Workbooks

Question 8: What is the difference between DDoS Protection Basic and Standard?

• A) Basic is paid, Standard is free
• B) Basic only protects VMs
• C) Standard offers adaptive tuning, alerts, attack reports, and an SLA; Basic is automatic and limited ✓
• D) There is no functional difference

Question 9: In PIM (Privileged Identity Management), what does “eligible” access mean?

• A) The user has the role permanently
• B) The user can temporarily activate the role via a JIT request ✓
• C) The user is awaiting permanent approval
• D) The role is disabled

Question 10: Which Azure Policy effect automatically deploys a missing resource when a parent resource is created?

• A) Audit
• B) Deny
• C) DeployIfNotExists ✓
• D) Append

Question 11: An Azure Key Vault secret was accidentally deleted. Soft Delete is enabled with 90 days retention. What happens?

• A) The secret is permanently lost
• B) The secret is recoverable only if Purge Protection is enabled
• C) The secret is in a “soft-deleted” state and can be restored for 90 days ✓
• D) The secret is automatically restored after 24 hours

Question 12: In the Zero Trust model, which principle corresponds to “minimize the blast radius by assuming an attack may occur”?

• A) Verify explicitly
• B) Least privilege
• C) Assume Breach ✓
• D) Defense in depth

General Summary – Azure Security Synthesis Table

Advanced Section – Review Questions and Glossary

Review Questions – Azure Security

Question 1 What is the difference between Microsoft Defender for Cloud (Free) and Microsoft Defender CSPM (paid)?

• A) The Free version does not monitor VMs; CSPM monitors them
• B) The Free version provides Secure Score and basic recommendations; CSPM adds Attack Path Analysis, DSPM, and advanced multi-cloud connectors
• C) CSPM is for Azure only; the Free version is multi-cloud
• D) There is no functional difference

Answer: B — The Free version offers Secure Score and basic security recommendations. Defender CSPM (paid) adds attack path analysis, data security posture management (DSPM), and advanced AWS/GCP connectors.

Question 2 Your SOC team needs to correlate security alerts from multiple Azure services, detect threats, and automate responses. Which Azure service is designed for this use case?

• A) Microsoft Defender for Cloud
• B) Azure Policy
• C) Microsoft Sentinel
• D) Azure Key Vault

Answer: C — Microsoft Sentinel is the Azure cloud-native SIEM + SOAR. It ingests logs from multiple sources, correlates alerts, detects threats with ML, and can automate responses via Logic Apps playbooks.

Question 3 You need to store a database connection secret used by an Azure Function. What is the best practice?

• A) Hardcode the secret in the Function code
• B) Put the secret in an unencrypted environment variable
• C) Store the secret in Azure Key Vault, access via Managed Identity
• D) Put the secret in a configuration file in Azure Blob Storage

Answer: C — The best practice is to store secrets in Azure Key Vault and use a Managed Identity to access it with no hardcoded credentials. This follows the Zero Trust principle and eliminates manual secret rotation.

Question 4 Which Azure Key Vault feature allows encrypting Azure SQL Database data with a key that only your organization controls, and whose revocation makes the database immediately inaccessible?

• A) Transparent Data Encryption (TDE) with Microsoft-managed key
• B) TDE with Customer-Managed Key (CMK) via Azure Key Vault
• C) Always Encrypted
• D) Dynamic Data Masking

Answer: B — TDE with CMK (BYOK - Bring Your Own Key) allows your organization to fully control the encryption key in Key Vault. If you revoke access to the key, the SQL database becomes immediately inaccessible.

Question 5 An attacker launches a volumetric DDoS attack on your Azure public web application. What is the minimal native DDoS protection provided for free by Azure?

• A) No protection — you must buy DDoS Standard
• B) Azure DDoS Protection Basic — protection for shared Azure infrastructure
• C) Azure Firewall DDoS mode
• D) Network Security Groups with anti-DDoS rules

Answer: B — Azure DDoS Protection Basic is included free for all Azure customers. It protects Azure’s shared infrastructure against common volumetric attacks. For dedicated protection with financial SLA and advanced telemetry, DDoS Standard (paid per VNet) is available.

Question 6 In the Zero Trust model, what is the difference from the traditional perimeter security model?

• A) Zero Trust doesn’t use firewalls; the traditional model does
• B) In the traditional model, internal resources are implicitly trusted; Zero Trust never trusts by default and explicitly verifies each access regardless of location
• C) Zero Trust is exclusively for cloud; the traditional model for on-premises
• D) There is no conceptual difference

Answer: B — The traditional perimeter model trusts everything “behind the firewall” (intranet = trusted). Zero Trust assumes compromise is possible everywhere: “Never trust, always verify” — every access is authenticated, authorized, and audited.

Question 7 You need to ensure that TLS certificates for your Azure web applications are automatically renewed before expiration. Which Azure service manages the certificate lifecycle?

• A) Azure Policy
• B) Microsoft Defender for Cloud
• C) Azure Key Vault (with Let’s Encrypt or DigiCert integration)
• D) Azure App Service (without Key Vault)

Answer: C — Azure Key Vault supports the full certificate lifecycle: issuance, secure storage, automatic renewal (via integration with Let’s Encrypt, DigiCert, GlobalSign), and expiration notification.

Glossary – Azure Security

Search Terms

azure · security · fundamentals · core · infrastructure · microsoft · deep · dive · encryption · policy · compliance · defender · questions · trust · zero · access · architecture · ddos · identity · managed · model · regulatory · vault · analytics