Azure Security Engineer AZ-500

Entra ID has three commercial tiers (Free, P1, P2) and the exam tests which security feature lives in which tier — get this wrong on a design question and you propose a control the customer can't afford.

• Free tier: basic directory, SSO to thousands of SaaS apps, security defaults (mandatory MFA for admins via the simple toggle). No Conditional Access, no PIM, no Identity Protection.
• P1 (Entra ID Premium P1): Conditional Access, group-based licensing, self-service password reset (SSPR), MFA Server, dynamic groups, application proxy. The minimum for most enterprise scenarios.
• P2: P1 + Privileged Identity Management (PIM), Identity Protection (sign-in risk + user risk policies), access reviews. Required for any "just in time admin" or "risk-based MFA" design.
• Per-user vs per-feature licensing: P1/P2 licenses must be assigned to users who BENEFIT from the feature, not just those who configure it. CA policies require P1 on all targeted users; PIM requires P2 on all eligible users.
• Microsoft 365 vs Entra ID bundles: Microsoft 365 E3 includes Entra ID P1; E5 includes P2. Many customers already have Entra ID P2 through M365 E5 without realising it.

A customer wants Conditional Access + PIM + Identity Protection. The exam question gives Entra ID Free as the starting state. Right answer: upgrade to Entra ID Premium P2, assigned to every user covered by these features. Just P1 would not unlock PIM or Identity Protection. M365 E5 also satisfies the requirement implicitly.

Hybrid identity is the bridge from on-prem Active Directory to Entra ID. Three modes (PHS / PTA / Federation) have distinct security postures. AZ-500 tests both the choice and the hardening pattern around Entra Connect.

• PHS (Password Hash Sync): hashes synced to Entra ID, auth happens in Azure. Simplest, default, supports leaked-credential detection. Works even if on-prem is offline.
• PTA (Pass-Through Auth): agents on-prem validate passwords against AD. Requires multiple agents for HA. Use when compliance forbids password hashes leaving on-prem.
• Federation (ADFS): Entra delegates auth to on-prem ADFS or SAML IdP. Most complex, most fragile, most operationally expensive. Only when smart cards / third-party MFA / specific claims are non-negotiable.
• Seamless SSO: Kerberos-based no-prompt SSO for domain-joined laptops. Add to PHS or PTA. Federation has SSO inherent.
• Entra Connect security: the AAD Connect server is a Tier 0 admin asset — compromising it compromises every synced identity. Treat like a domain controller. Isolate, harden, audit.
• Sync filters: never sync everything. Filter out service accounts, disabled accounts, IT-staff break-glass accounts. Service accounts especially — they often have weak passwords that ride the sync into Entra ID.

An auditor flags an unsynced break-glass admin account in Entra ID with a 30-character password and PIM-only Owner role. Correct design: this account stays cloud-only by design — it's the emergency-access account if hybrid sync breaks. Two cloud-only break-glass accounts, exempt from CA, exempt from MFA, with very long passphrases and 30-day rotation. The rest of the directory syncs from on-prem via PHS with Seamless SSO.

Non-human identities (service principals + managed identities) outnumber human accounts in any mature Azure tenant. AZ-500 tests how to design, scope, and audit them — getting these wrong is the most common root cause in cloud breach reports.

• Service principal: an Entra ID identity for an app or automation. Has a client secret or certificate. The CI/CD pipeline default. Secret rotation is your job.
• Managed identity: service principal whose secret is managed by Azure. System-assigned (1:1 with a resource) or user-assigned (standalone, shareable). No secret to rotate, no secret to leak.
• Federated identity credentials: let an external workload (GitHub Actions, AWS, Kubernetes via OIDC) trade its identity for Entra tokens — no Azure secret stored externally. The modern preferred CI/CD pattern.
• Service principal hygiene: regularly review unused SPs, secrets approaching expiry, secrets older than 1 year, secrets with broad scopes. Microsoft Defender for Cloud flags risky SPs.
• Administrative Units (AUs): sub-divide the tenant for scoped admin. A helpdesk admin assigned User Administrator on an AU can reset passwords ONLY for users in that AU. Avoids "all-or-nothing" admin grants.
• Workload Identity Federation: the formal name for the federated identity credentials pattern. Works for Functions / Container Apps / Logic Apps cross-cloud too.

An audit finds 200 service principals in the tenant, half unused for 12+ months, several with very long-lived secrets. Remediation: enable Entra ID app management reviews, automate stale-SP cleanup via a Logic App, migrate active SPs to managed identities where possible (every Azure-hosted workload), and for the few remaining external CI/CD pipelines, switch to Workload Identity Federation (GitHub Actions OIDC → Entra). End state: zero stored secrets, fewer service principals, audit-trail clean.

Conditional Access (CA) is the policy engine that decides "given these signals, does this sign-in succeed and under what conditions". It's the most-tested AZ-500 control by far — every other security feature relies on CA being designed correctly.

• Assignments (who/where/what): users + groups (with exclusions for break-glass), cloud apps (specific apps or all), conditions (sign-in risk, user risk, device platform, locations, client apps, device filters).
• Access controls — Grant: block access, require MFA, require compliant device, require Hybrid Entra-joined device, require approved client app, require app protection policy, require ToS acceptance. Multiple controls combine with AND (default) or OR.
• Access controls — Session: sign-in frequency, persistent browser session, app-enforced restrictions, Defender for Cloud Apps controls (Conditional Access App Control with reverse proxy).
• Named locations: trusted IP ranges + Entra-detected countries. Pair with "block from countries we don't operate in" for cheap external-attack mitigation.
• Report-only mode: evaluate policy without enforcement — see what WOULD be blocked, fix exceptions, then enable. Always use report-only mode for any new policy that targets > 50 users.
• Combined exclusions: always exclude break-glass accounts (Lesson 1.2), the Entra Connect sync account, and emergency-access roles. Without these exclusions, you can lock yourself out of the tenant.

Design: "external admin sign-ins must use MFA + a compliant device". Policy: assignments = role-includes "Global Administrator / User Administrator / Privileged Role Administrator", conditions = locations exclude trusted networks (so internal admins skip the prompt), exclusions = break-glass accounts. Grant: require MFA + require compliant device, AND. Deploy in report-only mode for 7 days, review sign-in logs for exceptions (e.g., the build server's admin SP), add exclusions, then flip to On.

PIM turns standing privileged access into just-in-time elevation with approval and audit. AZ-500 expects you to design PIM for both Entra ID directory roles AND Azure RBAC roles — they're configured separately.

• Eligible vs Active: eligible users can ACTIVATE the role for a configured duration with MFA + justification + (optional) approval. Active assignments work like classic role grants. Make 90%+ of admin assignments eligible.
• Activation requirements: max duration (1 hour default), MFA on activation, justification (free text), ticket number reference, approval (1+ approvers from a configured list).
• Access reviews: recurring reviews where reviewers attest a user still needs a role. Auto-removes non-responders or denied users. Configure quarterly for high-privilege Entra ID roles, semi-annually for Azure RBAC at subscription scope.
• PIM for Groups: apply PIM to ANY Entra ID group — not just role-assignable groups. The group's permissions (license, app access, RBAC) become just-in-time.
• Alerts: built-in alerts for "too many admins activated at once", "role activated unusually", "admin activation outside business hours". Tune to your tenant's normal pattern.
• PIM for Azure RBAC: separately enable per subscription / RG / resource. The directory-role and Azure-role PIM systems are distinct — being eligible for Owner at the management group doesn't grant directory roles and vice versa.

A regulated environment removes standing Global Administrator: convert every existing GA to PIM Eligible, set activation max 4 hours with MFA + approval (2 approvers) + ticket number required, configure quarterly access review with the manager-of as reviewer and auto-remove on no-response. Same for subscription-scoped Owner roles via PIM for Azure resources. Build-process service principal stays as a constrained role-assignable group with PIM enabled so even its own role can JIT-elevate.

Identity Protection adds Microsoft-curated risk signals (impossible travel, anonymous IP, leaked credentials, unfamiliar sign-in properties) and lets you trigger CA controls based on them. Requires Entra ID P2.

• Sign-in risk: Microsoft's confidence that THIS sign-in is compromised. Levels: low / medium / high. Signals: unfamiliar location, anonymous IP, atypical travel, malware-linked IP. Real-time evaluation.
• User risk: Microsoft's confidence that THIS user account is compromised over time. Driven by leaked credentials, suspicious activity history. Persists across sessions.
• Risk policies (legacy vs CA-based): legacy risk policies live in Identity Protection itself; modern best practice is CA policies that consume risk as a CONDITION and apply grant controls. CA-based is more flexible.
• Sign-in risk policies: if sign-in risk > medium → require MFA. If risk = high → require password change. Common pattern.
• User risk policies: if user risk > medium → block sign-in until password reset + MFA. Forces compromise remediation.
• Risky users dashboard: shows all users with elevated risk + remediation status. Investigation pane links sign-ins, detected risk events, and resolution actions.

A bank wants: (1) require MFA whenever sign-in risk is medium or high, (2) block users with high user-risk until reset. CA policies: policy A — assignments = all users (except break-glass), conditions = sign-in risk includes Medium + High, grant = require MFA. Policy B — assignments = all users (except break-glass), conditions = user risk = High, grant = block access (forces helpdesk-led reset). Pair with an automated Logic App that emails the user + manager on user-risk = High.

Azure Firewall is the managed L3-L7 firewall for VNet traffic. Two SKUs: Standard for basic filtering, Premium when you need IDPS or TLS inspection. AZ-500 asks both "which SKU fits this requirement" and "how should this rule be structured".

• Standard SKU: L3-L7 filtering, FQDN tags, network rules, application rules, NAT rules. Threat intelligence-based deny in alert or deny mode. No TLS inspection, no IDPS.
• Premium SKU: Standard + TLS inspection (cert decryption), IDPS (signature + rule engine), URL filtering, web categories. Needed for any "inspect payload" requirement.
• Firewall Policy: a separate resource that holds rules. Policies inherit hierarchically — parent policy at the org / hub, child policies at workload firewalls. Use to standardise global rules while delegating workload-specific exceptions.
• Rule collections: NAT (highest priority, DNAT inbound), Network (L3-L4), Application (L7 FQDN + tags). Processed in priority order within each collection type.
• FQDN tags vs Service tags: service tags (NSG-style) for known Microsoft IP ranges. FQDN tags (firewall-specific) for known FQDN endpoints like WindowsUpdate, AzureKubernetesService, OfficeApplications.
• Forced tunneling: point Azure Firewall's egress through an on-prem appliance via a 0.0.0.0/0 UDR on its subnet. Used when corporate policy requires all egress to be inspected on-prem.

A regulated workload needs L7 inspection of egress to public APIs with TLS decryption and content filtering. Choice: Azure Firewall Premium with Firewall Policy at the hub VNet. Enable TLS inspection (requires a CMK-protected intermediate cert from the org's PKI), IDPS in deny mode, URL filtering with allowed categories. Application rules for permitted FQDNs; everything else implicit deny. Parent policy at the org tier; workload policies inherit and add allow-list exceptions.

NSGs filter packets at the subnet / NIC boundary. ASGs make rules intent-based. Private endpoints take PaaS services off the public internet. The trio is what most "secure this VNet" exam questions actually test.

• NSG rule priority + direction: lowest priority wins per direction. Default rules at 65000-65500 are immutable (allow intra-VNet, allow LB probes, deny all else inbound; allow VNet→Internet outbound, deny otherwise).
• Service tags: Microsoft-maintained IP groups (Internet, AzureLoadBalancer, Storage.EastUS, etc.). Use instead of hard-coded CIDRs — they auto-update as services scale.
• Application Security Groups (ASG): tag VMs/NICs with an ASG name and reference the ASG as source/destination in NSG rules. "Allow web-tier to talk to data-tier" is one rule, not a CIDR list that breaks on scale-out.
• NSG attachment: at NIC, at subnet, or both. When both apply, traffic must be allowed at BOTH layers. Subnet-level is the scale-out pattern.
• Service Endpoints (legacy): route subnet → PaaS over the Microsoft backbone, but the PaaS keeps its public endpoint. Older approach.
• Private Endpoints (modern): PaaS gets a private IP in your subnet, pairs with a Private DNS zone. Disable the PaaS public endpoint entirely. The AZ-500 default for any PaaS-to-VNet integration.

A 3-tier app: tag VMs with ASGs asg-web / asg-app / asg-db. NSG (subnet-level): priority 100 inbound — allow Internet → asg-web on 443; priority 110 inbound — allow asg-web → asg-app on 8080; priority 120 inbound — allow asg-app → asg-db on 1433; priority 4096 inbound — deny all else. SQL Server data plane via Private Endpoint in asg-db's subnet, public endpoint disabled. Private DNS zone linked to the VNet.

Three more secure-networking controls that round out perimeter design: DDoS Protection for volumetric attacks, Bastion for SSH/RDP without exposed VMs, WAF for L7 application-layer attacks.

• DDoS Protection Basic: free, always-on for every Azure IP. Protects the Azure platform but doesn't give you tenant-specific tuning or attack metrics.
• DDoS Protection Standard (Network / IP): protects your public IPs with custom tuning, attack-time metrics, cost-protection guarantee (Azure refunds scale-out costs incurred during an attack), DDoS Rapid Response support. Per-VNet (Network plan) or per-IP (IP plan). Pricey — only justify for production with internet exposure.
• Azure Bastion: PaaS jump-host that brokers RDP/SSH over the browser. No public IP on the target VM, no inbound RDP/SSH NSG rule needed. SKU tiers: Basic, Standard (shareable links, IP-based connection), Premium (session recording).
• Just-In-Time VM access (Defender for Cloud): alternative to Bastion — opens RDP/SSH NSG rule for a configured window on request, auto-closes. Use when you need direct VM IP access AND can't or don't want to deploy Bastion.
• Web Application Firewall (WAF): two homes — on Application Gateway (regional, in-VNet) or on Front Door (global edge). Both run the OWASP Core Rule Set. Front Door WAF runs at Microsoft edge POPs — closer to attackers, blocks earlier.
• WAF modes: Detection (logs only) and Prevention (blocks). Always start in Detection to find false positives, then promote. Custom rules for rate limiting per source IP.

A SaaS startup deploys to Azure with global users. Design: Azure Front Door Premium in front with WAF in Prevention mode + custom 100 req/min rate-limit per IP. The two regional App Service backends sit behind App Gateway (no WAF on the inner gateway). DDoS Protection Standard (IP plan) on the Front Door public IPs (cost-justified by the customer-facing exposure). Admin access via Azure Bastion Standard in the hub VNet — no public RDP/SSH anywhere.

Key Vault holds the secrets, keys, and certificates that the rest of your security architecture depends on. Losing Key Vault means losing access to encrypted data. AZ-500 tests recoverability features (soft-delete, purge protection), tier choice (Standard vs Premium HSM), and the two access models (RBAC vs access policies).

• Standard vs Premium: Standard uses software-protected keys. Premium adds HSM-backed keys (FIPS 140-2 Level 2 hardware). Required for some compliance regimes (PCI, FedRAMP High). HSM-backed keys are slightly slower for operations but the difference is rarely material.
• Soft-delete: deleted keys/secrets stay recoverable for 7-90 days. Default on, can't be disabled on new vaults. Critical for ransomware recovery.
• Purge protection: blocks PERMANENT delete during the soft-delete window — even an Owner can't bypass. Required when storing CMKs for Storage / SQL because losing a CMK before its dependent data is migrated = permanent data loss.
• Access policy model (legacy): per-vault list of principal → permission set (keys/secrets/certs read/write/etc.). Awkward at scale, no centralised audit, doesn't integrate with PIM.
• RBAC model (modern): standard Azure RBAC roles applied at the vault scope (or below — secret/key/cert level). Inherits like all RBAC, audits via Activity Log, supports PIM. Switch new vaults to RBAC by default; migrate old vaults when feasible.
• Backup and BYOK: Premium vaults support customer-supplied HSM keys (BYOK) via the secure key-transfer ceremony. Backups are encrypted exports tied to the source region — restore only into the same region's HSM.

A regulated workload needs HSM-backed CMK for SQL TDE and Storage SSE. Design: Key Vault Premium with soft-delete enabled (90 days) + purge protection ON. Switch to RBAC access model. SQL Server and Storage Account both have system-assigned managed identities; grant each the Key Vault Crypto Service Encryption User role at the vault scope. Operations team has Key Vault Reader only — secret CRUD requires PIM elevation to Key Vault Secrets Officer.

Three overlapping disk-encryption stories on Azure: Storage Service Encryption (SSE — automatic), Customer-Managed Keys for SSE, and Azure Disk Encryption (ADE — BitLocker/DM-Crypt inside the VM). The exam asks both about distinctions and about combinations.

• Storage Service Encryption (SSE): ON by default for every managed disk, blob, file share. Microsoft-managed key by default. Encryption at rest is free, automatic, transparent.
• Customer-Managed Keys (CMK): replace the platform key with one in YOUR Key Vault. Required when compliance demands key custody. Disk encryption sets pair a CMK with the disks that use it; rotating the key rotates encryption for all linked disks.
• Azure Disk Encryption (ADE): BitLocker (Windows) or DM-Crypt (Linux) INSIDE the guest OS. Key stored in Key Vault, unlocked at boot. Targets specific compliance regimes that mandate OS-level encryption.
• ADE vs SSE+CMK: they compose. SSE encrypts the underlying physical storage; ADE encrypts at the OS layer too. Both at once = double-encrypted. ADE is rarely needed if SSE+CMK satisfies the requirement.
• Double Encryption at Rest: for ultra-regulated workloads, enable double encryption — two separate encryption layers (platform key + CMK) on the same disk. Pricier and slower; only justify when compliance demands.
• Confidential VMs / Confidential Disk Encryption: newer pattern using AMD SEV-SNP or Intel TDX for memory + disk encryption with hardware attestation. Bleeding-edge but appears on newer AZ-500 questions.

A regulated workload needs encryption keys held by the org, but no requirement for guest-OS encryption. Choice: SSE with Customer-Managed Keys. Create a Key Vault Premium with HSM-backed key, set up a disk encryption set pointing at that key. Apply the disk encryption set to the VM's OS and data disks at provision time. The key rotates quarterly via Azure Automation. ADE would add operational overhead with no compliance benefit here.

Securing storage accounts has four layers: identity-based access (RBAC + managed identities), key-based access (Shared Key + SAS), network controls (firewall + private endpoints), and immutability for compliance.

• Shared Key vs SAS: the two access keys per account grant full control — never embed in clients. SAS tokens are time-bounded, scope-limited URL signatures. Three types: account SAS, service SAS, user-delegation SAS (signed by Entra ID token, the modern preferred form).
• RBAC on data plane: roles like Storage Blob Data Reader, Storage Blob Data Contributor. SEPARATE from management-plane roles (Storage Account Contributor can manage the account but NOT read blobs). Always assign data-plane roles to managed identities for application access.
• Storage firewall: set Public access to "Selected networks", allow specific IP CIDRs + subnet rules (subnet must have Storage service endpoint enabled). Trusted Microsoft Services exception lets Azure Monitor / Backup still reach the account.
• Private endpoint: the modern preferred way. Storage gets a private IP in your subnet, pair with Private DNS zone privatelink.blob.core.windows.net. Disable public endpoint entirely.
• Immutability (WORM): time-based retention policy (blocks writes/deletes until timer expires) or legal hold (blocks until removed). Apply at container level. Required for SEC 17a-4 / FINRA compliance. When locked, even owners can't bypass.
• Disable Shared Key access: a top-level setting per storage account that disables Shared Key entirely — only Entra ID-based access works. Pair with managed identities to eliminate the entire key-leak vector.

A regulated workload stores customer data with 7-year retention. Design: Storage Account with Shared Key access disabled (Entra ID-only). Applications use system-assigned managed identities with Storage Blob Data Contributor role. Private endpoint in the app subnet; public network access disabled. Time-based immutability policy (7 years, locked) on the data container. External auditors get scoped user-delegation SAS tokens with 1-hour expiry, revocable by signing the identity out.

Azure SQL has three overlapping data-protection features that the exam routinely contrasts: TDE encrypts at rest, Dynamic Data Masking obscures at query, Always Encrypted protects against the DB admin themselves.

• Transparent Data Encryption (TDE): encrypts the DB files at rest. ON by default for new Azure SQL DBs. Platform-managed key or CMK from Key Vault — CMK gives you key custody (BYOK).
• Dynamic Data Masking (DDM): obscures sensitive columns at query time for users without UNMASK permission. The data IS still in the DB; DDM only changes what users SEE. Not a real encryption control — use for "developers can query prod, with PII redacted".
• Always Encrypted: client-side encryption — the column is encrypted in the app before it ever reaches SQL. SQL Server never sees the plaintext or the key. Protects against compromised DB admins or compromised SQL servers. Two modes: deterministic (allows equality queries) and randomised (most secure, no querying on the column).
• Always Encrypted with Secure Enclaves: newer — enclave (Intel SGX or VBS) on the SQL host can run pattern-matching, range queries, and joins on encrypted data. Removes the deterministic-mode limitation.
• SQL Auditing: enables event logging to Storage / Log Analytics / Event Hub. Always enable for production. Audit-action groups: BATCH_COMPLETED_GROUP (all queries), SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP, FAILED_DATABASE_AUTHENTICATION_GROUP.
• Microsoft Defender for SQL: adds Advanced Threat Protection (anomalous-query alerts), Vulnerability Assessment (weekly scan against best-practice rules). Required for SQL workloads protecting regulated data.

A bank stores credit card numbers in an Azure SQL DB. Design: TDE enabled with CMK (key custody). Always Encrypted (randomised) on the card-number column — the DB admin CAN see encrypted blobs but never plaintext. Application code uses the Always Encrypted client driver with the cert from Key Vault. Non-sensitive PII columns (name, email) use Dynamic Data Masking so devs running queries against prod replicas see masked values. Defender for SQL turned on, audit to Log Analytics, alerts route to the SOC.

Securing AKS is multiple layers: the control plane (Entra ID RBAC for kubectl), the workload identities (Workload Identity / pod-managed identity), the network (Network Policies + private cluster), and the image supply chain (ACR + Defender for Containers scanning).

• Entra ID integration for kubectl: AKS uses Entra ID for cluster authentication; Kubernetes RBAC maps Entra users/groups to in-cluster roles via ClusterRoleBindings. Disable the local --admin kubeconfig in production.
• Workload Identity (modern): federated credentials between AKS service accounts and Entra ID — pods authenticate as managed identities without storing secrets. Replaces the legacy AAD Pod Identity (deprecated).
• Azure CNI vs Kubenet: CNI gives each pod a VNet IP, supports Network Policies and Calico. Kubenet uses NAT and is simpler but limited. AZ-500 expects CNI for any non-trivial cluster.
• Network Policies: Kubernetes-native pod-to-pod traffic rules — like NSGs but for pods. Azure Network Policy or Calico. Required for "deny by default" between pods.
• Private cluster: AKS API server has private IP only (no public endpoint). Combined with VNet integration + Azure Bastion for kubectl access. Required for high-security AKS.
• Image scanning: ACR + Microsoft Defender for Containers scans on push, on registry catalog, and at runtime. CIS Kubernetes Benchmark compliance + runtime threat detection.

A regulated AKS cluster running customer workloads: private cluster with API on a private IP in the spoke VNet. Entra ID-integrated RBAC, local admin disabled, kubectl access only via PIM-elevated Azure Kubernetes Service RBAC Cluster Admin role. Each app's pods use Workload Identity mapped to Azure managed identities for Key Vault / Storage access. Network Policies deny all cross-namespace traffic by default; ingress allowed only from the platform's NGINX namespace. Images pulled from a Premium ACR with Defender for Containers scanning + admission control (block deploys with high CVEs).

VMs are the most-attacked Azure workload. AZ-500 tests JIT access (close down standing RDP/SSH), Defender for Servers (runtime detection + vulnerability scanning), and adaptive controls (machine-learned allow-list of binaries).

• Just-In-Time (JIT) VM access: opens an NSG rule for RDP/SSH for a configured window when an admin requests, then auto-closes. Requires Defender for Cloud + Defender for Servers Plan 2.
• Bastion vs JIT: Bastion brokers RDP/SSH without any inbound NSG rule. JIT briefly opens an NSG rule for direct VM IP access. Bastion is more secure; JIT is simpler and works for legacy workflows that need direct IP.
• Defender for Servers Plan 1 vs Plan 2: Plan 1 = MDE integration only. Plan 2 = MDE + JIT + adaptive application controls + adaptive network hardening + Qualys vulnerability scanning + file integrity monitoring.
• Microsoft Defender for Endpoint (MDE) integration: Plan 1/2 auto-deploys MDE to Windows + Linux VMs via the Defender for Cloud agent. Alerts flow into Defender for Cloud Security Alerts + Sentinel if connected.
• Adaptive application controls: Defender learns which binaries normally run on a VM group, then alerts (or blocks in audit mode) on unknown binaries. Anti-LotL technique. Plan 2 only.
• File integrity monitoring (FIM): watches specified files / registry paths for changes and alerts. Useful for known-good config files; tunes false-positive ratio carefully.
• Update management: Azure Update Manager (replacing legacy Automation Update Management) — assess + deploy OS patches across Azure + Arc-enabled servers, dynamic groups, maintenance windows.

A 50-VM workload needs RDP/SSH on demand, runtime threat detection, and OS patching governance. Enable Defender for Servers Plan 2 on the subscription. JIT VM access via Defender for Cloud — admins request 1-hour windows; rules auto-close. MDE deploys via Defender — alerts feed Sentinel. Adaptive application controls in Audit mode for 2 weeks, then promote to Enforce. Azure Update Manager with monthly maintenance windows; critical patches force-applied at-restart with a 7-day grace.

Defender for Cloud is two products bundled: CSPM (Cloud Security Posture Management — Secure Score, recommendations, compliance) and CWPP (Cloud Workload Protection Platform — the Defender for X plans). CSPM is free; CWPP is per-workload paid.

• Secure Score: 0-100% rolling score per subscription, computed from coverage of "security controls" — bundles of related recommendations. Each recommendation is weighted; some are mandatory (denied subscription if not addressed for certain compliance standards).
• Free CSPM (Foundational): Secure Score, recommendations, security alerts from connected sources, regulatory compliance views (CIS, ISO 27001, etc.). On by default for every subscription.
• Defender CSPM (paid): attack-path analysis (graphs of how a compromised resource could reach high-value targets), agentless scanning, governance assignments, container posture deep dive. Worth it for production at scale.
• Recommendations: categorised by Compute / Identity / Storage / etc., each with severity, status, affected resources. Some support quick fix; others link to remediation guides. The Secure Score moves as you remediate.
• Exemptions: mark a recommendation as N/A or Risk-Accepted with justification + expiry. Audit trail kept. Use sparingly — exemptions accumulate technical debt.
• Multi-cloud: Defender for Cloud can connect AWS accounts and GCP projects, applying the same CSPM model. Useful for unified posture in multi-cloud orgs.

A new subscription starts at Secure Score 45%. Investigation: 12 high-severity recommendations cluster around "data + storage" and "identity". Highest-impact fixes: enable Defender for Storage, enable storage account firewalls, switch Key Vaults to RBAC + purge protection. Each fix lifts the score 5-8 points. After remediation: 78%. Outstanding items get exemptions with 90-day expiry and ticket numbers for tracking.

The "Defender for X" plans add workload-specific protection on top of CSPM. AZ-500 tests which plan provides which feature — get the plan wrong and you propose a control the customer can't enable.

• Defender for Servers: Plan 1 (MDE integration only) or Plan 2 (MDE + JIT + adaptive controls + Qualys VA + FIM + 500 MB Log Analytics ingest). Pick Plan 2 for production.
• Defender for Storage: on-blob malware scanning (V2), sensitive-data discovery (V2), anomalous-access threat detection. Per-storage-account or per-subscription pricing.
• Defender for SQL: Advanced Threat Protection (anomalous-query alerts), Vulnerability Assessment (weekly scan), works for Azure SQL DB / SQL on IaaS / on-prem SQL via Arc.
• Defender for Containers: AKS posture (CIS Kubernetes Benchmark), image scanning in ACR, runtime threat detection (process anomalies in pods), Azure Policy admission control.
• Defender for App Service: runtime threat detection for App Service workloads (anomalous traffic, command injection, dangling DNS).
• Defender for Key Vault / Resource Manager / DNS: anomalous-access detection for the management plane and DNS query patterns.
• Subscription enablement: plans are enabled per-subscription per-workload. Use Azure Policy to enforce enablement across subscriptions — saves having to manually toggle on every new sub.

A regulated production subscription enables: Defender for Servers Plan 2 (JIT + MDE for VMs), Defender for Storage (malware scanning on customer uploads), Defender for SQL (ATP + VA on the customer DB), Defender for Containers (CIS scanning + runtime detection for AKS), Defender for Key Vault (catches abnormal vault access). Total: ~$30/server/month + per-workload fees — easily justified for regulated workloads. Azure Policy initiative Enable Defender for X plans enforces enablement on any future production subscriptions.

The last Defender pillar is the workflow side — tracking compliance posture against standards, routing alerts, automating remediation. AZ-500 cares about which compliance framework lives in Defender, how alerts flow, and where automation hooks in.

• Built-in regulatory standards: Azure Security Benchmark (default), CIS Microsoft Azure Foundations Benchmark, NIST SP 800-53, ISO 27001, PCI DSS, SOC 2, HIPAA HITRUST, FedRAMP. View per-subscription, drill down to controls and the specific recommendations that satisfy them.
• Custom standards: bundle Azure Policy initiatives into a custom compliance standard — useful for internal control frameworks.
• Security alerts: Defender generates alerts (e.g., "anomalous storage access detected") that appear in the Security Alerts view, complete with severity, kill-chain phase (MITRE ATT&CK), affected resource, and remediation steps.
• Workflow automation: Logic App-based playbooks triggered by alert or recommendation. Common patterns: tag the affected resource, post to Teams, create a ServiceNow ticket, auto-isolate a VM via NSG.
• Continuous export: stream alerts + recommendations to Event Hub / Log Analytics / Storage for ingestion into SIEM (Sentinel) or third-party.
• Defender for Cloud → Sentinel integration: a one-click data connector forwards Defender alerts as Sentinel incidents. SOC works the incident in Sentinel; Defender remains the source of truth for posture.

A regulated org tracks PCI DSS compliance per subscription. Enable the PCI DSS 3.2.1 regulatory standard in Defender for Cloud — the compliance view maps every PCI control to the Defender / Policy recommendations that satisfy it. Failing controls get tracked tickets. Workflow automation: a Logic App playbook triggers on any High-severity alert, creates a Sentinel incident, posts to the SOC Teams channel, and tags the affected resource InvestigationStatus=Active. Continuous export streams everything to Sentinel's Log Analytics workspace for long-term retention + KQL hunting.

Sentinel is a layer on top of Log Analytics — workspace design and data-connector selection determine both cost and coverage. The exam tests workspace topology choices and which connector to use for which signal.

• Workspace topology: one Sentinel workspace per security boundary (single tenant, region, or compliance scope). Multi-tenant MSSP scenarios use Azure Lighthouse to query across customer workspaces. Resist "one global workspace" — egress and quota issues.
• Data connectors: turnkey integrations. Microsoft signals (Entra ID, Defender for Cloud, Defender XDR, M365) come free; third-party (Palo Alto, AWS, Cisco, Cloudflare) via CEF / Syslog / REST APIs. Cost is ingestion + retention, not the connector itself.
• Ingestion cost: ~$2.50/GB ingested (varies by region, commitment tier). Sentinel adds ~$2/GB on top of Log Analytics ingest. Largest ingest sources: NSG flow logs, Defender for Endpoint device events, on-prem firewall syslog. Sample / drop low-value logs.
• Retention tiers: Analytics tier (queryable, default 90d, expensive), Basic tier (cheaper, limited query), Archive (long-term cold, restore-to-query). Mix tiers to meet compliance retention without breaking the budget.
• Auxiliary logs (newer): table type for cheap-to-ingest, occasionally-queried logs (verbose application logs, low-priority audit trails). Pair with summary rules to lift signal into Analytics tier.
• Watchlists: CSV-uploaded reference data (executive accounts, known-malicious IPs, allowlists) joinable in KQL via _GetWatchlist(). Great for enrichment.

A regulated enterprise designs Sentinel: one workspace per region (eastus2, westeurope) for data residency, all under one Microsoft Sentinel solution. Data connectors: Entra ID sign-ins, Defender XDR, Azure Activity, on-prem firewall via CEF (Logstash forwarder). NSG flow logs sampled at 10% to control ingest cost. Watchlist for ~500 executive accounts joined to sign-in alerts for VIP-prioritisation. Long-term retention: 90d Analytics + 2y Archive for compliance.

Detections turn raw logs into incidents the SOC works. AZ-500 tests rule types (scheduled, NRT, anomaly, ML), the alert-to-incident pipeline, and basic KQL for writing custom detections.

• Scheduled rules: KQL query that runs on a frequency (5 min - 14 days), evaluates a threshold, creates alerts. The most common detection type. Tune frequency vs detection latency vs query cost.
• Near-Real-Time (NRT) rules: sub-minute detection, KQL with strict limits (single table, no joins beyond watchlists). Use for high-fidelity quick alerts (e.g., disabled-user sign-in).
• Microsoft Security rules: turn-key analytics curated by Microsoft for specific data sources (sign-in alerts, defender alerts). Enable many in one click; tune later.
• Anomaly + ML rules: Microsoft-trained anomaly detections (impossible travel, unusual data download). Tunable thresholds but no rule logic to write. Mostly Defender for Cloud / Identity Protection derived.
• Alert grouping: aggregate related alerts into one incident. Group by entity (same user / IP / host), by time window, or by alert template. Reduces SOC noise massively.
• KQL essentials for detections: where + summarize count() by + where count_ > threshold is the basic pattern. Use extend to enrich; join kind=inner for correlation; materialize() for repeated sub-queries.

Detection: "any user with > 10 failed sign-ins from distinct IPs in 5 minutes". KQL: SigninLogs | where ResultType != 0 | summarize FailedSignIns = count(), DistinctIPs = dcount(IPAddress) by UserPrincipalName, bin(TimeGenerated, 5m) | where FailedSignIns > 10 and DistinctIPs > 5. Wrap in a scheduled rule with 5-minute frequency, alert severity Medium, group alerts by UserPrincipalName for a single incident per affected user. Pair with a NRT rule for "any sign-in from a known bad IP in the watchlist" — fires within seconds.

Detection without response is a dashboard, not security ops. Sentinel's SOAR layer (automation rules + playbooks) closes the loop; threat hunting puts analysts ahead of detections.

• Automation rules: Sentinel-native triggers on alert creation / incident creation / incident update. Lightweight actions: change severity, assign owner, add tag, run a playbook.
• Playbooks: Logic Apps that execute richer workflows. Built-in connectors for Entra ID (disable user), MDE (isolate device), Microsoft Teams (post incident), Defender for Cloud, ServiceNow, ITSM tools.
• Common playbook patterns: on critical incident → post to SOC Teams channel; on disabled-user sign-in alert → automatically disable account in Entra ID; on malware detected → trigger MDE host isolation.
• Threat hunting: proactive KQL queries against historical data — looking for behaviours BEFORE detections fire. Saved hunts + bookmarks track interesting findings without raising alerts.
• Entity Behavior Analytics (UEBA): Microsoft-managed baselines per user/host/IP — surfaces "this account is doing something unusual for it". Entity pages aggregate all signals around one entity.
• Workbooks: parameterised KQL dashboards. Both built-in (per data connector) and custom. Use to track SOC KPIs (incidents/day, MTTR, top affected entities) for the security leadership.

A SOC responds to compromised-account incidents within 5 minutes. Design: automation rule on incidents tagged "Compromised Account" → run playbook: (a) call Microsoft Graph to disable the user in Entra ID, (b) revoke all refresh tokens, (c) post the incident summary to the #soc-alerts Teams channel, (d) create a ServiceNow ticket assigned to the analyst on call. Threat hunters use saved hunting queries like "users newly added to privileged groups in the last 24h" to spot post-compromise persistence ahead of formal detection.