AZ-500: Azure Security Engineer Associate Study Guide
The AZ-500: Azure Security Engineer Associate exam validates your ability to implement, manage, and monitor security across Azure identity, platform, operations, and data/applications. It is aimed at security engineers who manage identity and access, secure networks and compute, run security operations with Defender for Cloud and Microsoft Sentinel, and protect data, keys, and applications. Expect 40-60 scenario-based questions in 120 minutes, with a scaled passing score of 700.
Domain 1: Manage Identity and Access
- Always exclude at least one break-glass (emergency access) cloud-only account with a long, complex password from every Conditional Access policy to avoid locking yourself out of the tenant.
- Microsoft Entra ID Protection has an MFA registration policy that prompts unregistered users to enroll and enforces a configurable grace period (commonly 14 days) before registration becomes mandatory at sign-in.
- Conditional Access supports authentication strength (a named requirement); use phishing-resistant strength (FIDO2, Windows Hello for Business, certificate-based) for high-risk or untrusted-location access and standard MFA for trusted locations.
- Privileged Identity Management (PIM) provides just-in-time, time-bound role activation with options to require approval, require justification, require MFA on activation, and it writes dedicated audit logs for every activation.
- System-assigned managed identities are tied to a single resource's lifecycle and are deleted automatically when the resource is deleted; user-assigned managed identities are standalone and can be shared across multiple resources.
- Use managed identities instead of stored credentials: grant an App Service's system-assigned identity Get permission on Key Vault secrets via an access policy or RBAC role like Key Vault Secrets User.
- Workload identity federation lets pipelines (e.g., Azure DevOps or GitHub Actions) authenticate to Entra ID via OIDC with no stored secret or certificate; pair it with Azure RBAC role assignments at the target scope.
- Self-Service Password Reset (SSPR) can require two authentication methods to reset and supports a re-confirmation period that forces users to periodically revalidate their registered contact info.
- Microsoft Entra Password Protection blocks weak and banned passwords (global plus custom banned lists) in the cloud and, with the on-premises agent, in Active Directory.
- B2B guest governance uses external collaboration settings (restrict invitations to specific domains) plus cross-tenant access settings, which can require MFA from guests and trust MFA/compliance claims from the home tenant.
- Microsoft Entra Access Reviews periodically recertify group membership, app access, and privileged role assignments, and can auto-remove access when a reviewer denies or fails to respond.
- Deploy new Conditional Access policies in Report-only mode first, then evaluate impact using the sign-in logs and the Conditional Access insights workbook before enforcing.
- App registration for web apps requires a redirect URI and uses delegated Microsoft Graph permissions for user-context calls; application permissions are for daemon/app-only access and require admin consent.
- In Microsoft Entra Verified ID, the Verifier is the party that requests and validates a presented verifiable credential, the Issuer creates it, and the Holder stores it in their wallet.
Domain 2: Implement Platform Protection
- Application Security Groups (ASGs) let you write NSG rules by application role (web/app/db tier) instead of IP addresses; ASGs are referenced as the source and/or destination in NSG rules.
- NSG rules are evaluated by priority (lowest number wins, 100-4096 for custom rules); the default AllowVNetInBound rule permits all intra-VNet traffic, so you must add higher-priority deny rules to restrict it.
- Azure DDoS Network Protection is the paid, always-on tier with adaptive tuning per protected public IP and access to the DDoS Rapid Response (DRR) team; DDoS IP Protection is per-IP and Basic is free/platform-level.
- Azure Firewall Premium adds TLS inspection, IDPS (intrusion detection and prevention), URL filtering, and web category filtering; Standard provides FQDN filtering and threat intelligence-based filtering only.
- Firewall Premium TLS inspection requires uploading an intermediate CA certificate to the firewall policy and distributing the corresponding root CA to the trusted root store of inspected clients.
- In hub-and-spoke, route spoke outbound traffic through Azure Firewall using User-Defined Routes (UDRs) with next hop = the firewall's private IP, and enable 'Allow forwarded traffic' on spoke peerings.
- Azure Firewall Manager with a secured virtual hub uses routing intent/policies to send inter-hub, branch, and internet traffic through the firewall in Virtual WAN topologies.
- Private endpoints give an Azure PaaS resource a private IP in your VNet; to make name resolution work you must link a private DNS zone such as privatelink.database.windows.net (SQL) or privatelink.vaultcore.azure.net (Key Vault).
- Disable 'Public network access' on PaaS resources (Azure SQL, Key Vault, Storage) when using private endpoints to block all internet-based connectivity.
- Service endpoints keep traffic to a PaaS service on the Azure backbone from a specific subnet; combine a VNet service endpoint (e.g., Microsoft.Sql) with a VNet rule on the target resource to allow only that subnet.
- Azure WAF runs on Application Gateway (regional) or Azure Front Door (global); enable the OWASP/Core managed rule set for SQLi and XSS, add custom geo-match rules to block countries, and rate-limit rules to throttle endpoints.
- Use Azure Bastion for browser-based RDP/SSH to VMs that have no public IP; just-in-time (JIT) VM access in Defender for Cloud opens management ports only on request, for a limited time, from approved source IPs.
- Azure Policy enforces platform guardrails such as restricting allowed container image registries, requiring specific regions, and auditing or denying noncompliant resource configurations.
- Defender for Containers protects AKS clusters and registries (runtime threat detection, image vulnerability scanning); restrict cluster pulls to approved registries with Azure Policy for AKS (Gatekeeper/OPA).
Domain 3: Manage Security Operations
- Microsoft Sentinel architecture: data connectors ingest logs, analytics rules (KQL) correlate and create incidents, and playbooks (Azure Logic Apps) automate response (SOAR).
- To reduce alert noise from a known benign account, modify the analytics rule's KQL query to exclude that account rather than disabling the rule entirely.
- Sentinel Fusion is a built-in, machine-learning analytics rule that correlates low-fidelity alerts across sources into high-confidence multistage attack incidents.
- Sentinel hunting uses saved KQL queries to proactively search Log Analytics data; Livestream monitors a query's results in real time during an active investigation.
- Import threat intelligence via the Threat Intelligence data connector (TAXII or the Threat Intelligence Platforms API), then enable the built-in TI Map analytics rules to match indicators against your logs.
- Collect Windows security events with the Azure Monitor Agent (AMA) and the Windows Security Events connector, choosing a collection tier (All, Common, Minimal, or custom) to control event volume.
- Defender for Cloud Secure Score reflects how well your environment follows security controls; prioritize remediation by each recommendation's potential Secure Score increase (impact).
- The Defender for Cloud Regulatory Compliance dashboard maps your posture to standards such as the CIS Microsoft Azure Foundations Benchmark, NIST, and PCI DSS that you add to the policy initiative.
- Many Defender for Cloud recommendations include a Fix (one-click remediation) and can be auto-remediated at scale via Azure Policy with the DeployIfNotExists effect, e.g., to deploy diagnostic settings.
- Configure high-severity alert email notifications in Defender for Cloud's environment settings, and use workflow automation to trigger a Logic App when matching alerts fire.
- Sentinel automation rules orchestrate incident handling (assign, tag, change severity, run playbooks) centrally, while playbooks are the Logic Apps that perform the actual automated actions.
- Defender for Servers (with the Defender for Endpoint integration) provides EDR, vulnerability assessment, and JIT/adaptive controls for VMs; vulnerability findings (CVEs and affected machines) appear in recommendations.
- Defender for IoT can run agentless and monitor network traffic to detect anomalous behavior on OT/IoT devices without installing agents on the devices.
- Use Azure Policy DeployIfNotExists to automatically configure diagnostic settings so resource logs are routed to a central Log Analytics workspace for monitoring and Sentinel ingestion.
Domain 4: Secure Data and Applications
- Always Encrypted encrypts sensitive columns on the client before data reaches Azure SQL, so DBAs and the server never see plaintext; store the column master key in Azure Key Vault, with the column encryption key in the database.
- Transparent Data Encryption (TDE) encrypts data at rest (data files, logs, backups) and is enabled by default on Azure SQL; switch to a customer-managed key (BYOK) in Key Vault for control over rotation and revocation.
- Rotating the TDE protector to a new Key Vault key version re-wraps the Database Encryption Key (DEK) and is an instantaneous, zero-downtime operation; only the DEK wrapping changes, not the data.
- Dynamic Data Masking obscures sensitive values (e.g., credit card numbers) for nonprivileged users at query time, while authorized users (added to the unmasked list) still see full data; it does not encrypt data at rest.
- Azure Key Vault Managed HSM provides single-tenant, FIPS 140-2 Level 3 validated hardware where keys never leave the HSM boundary; the Premium vault tier uses shared, multi-tenant HSMs.
- Key Vault access can be authorized either by the legacy access policy model or by Azure RBAC; RBAC (roles like Key Vault Secrets User, Crypto User) is the recommended, more granular model and you choose one model per vault.
- Protect Key Vault with soft delete (recover deleted objects within the retention period) and purge protection (block permanent deletion until retention elapses), both of which should be enabled for production.
- Restrict Key Vault network access with the firewall, VNet/service endpoint rules, and the 'Allow trusted Microsoft services to bypass the firewall' option; for full isolation use a private endpoint and disable public access.
- Reference a Key Vault secret by its versionless URI (no version GUID) so the application always retrieves the current version after rotation, instead of pinning to a specific version.
- Use a service-level (or user-delegation) SAS scoped to specific containers, permissions (e.g., read), and a short expiry to grant time-limited storage access without sharing account keys.
- Harden storage accounts by requiring secure transfer (HTTPS only), disabling shared key authorization to force Microsoft Entra ID auth, disabling public blob access, and using customer-managed keys for encryption.
- For Azure SQL data protection, enable SQL Auditing (who accessed/changed data), Advanced Threat Protection (anomalous activity alerts), and the SQL Vulnerability Assessment (misconfiguration scanning).
- Protect APIs in API Management with a validate-jwt inbound policy that checks the token issuer, audience, and signing keys against the Entra ID OpenID Connect metadata (OIDC discovery) endpoint.
- Microsoft Purview Data Map scans and classifies sensitive data across Azure Storage and other sources, and Defender for Storage adds sensitive-data context and threat detection to storage security alerts.
AZ-500 exam tips
- Read each scenario for the deciding constraint (no stored secrets, no public access, zero downtime, FIPS 140-2 Level 3, untrusted location) and pick the option that satisfies that exact requirement.
- On multiple-response 'select all that apply' items, evaluate each option independently against the requirements; partial-credit-style questions punish both missing a correct option and adding a wrong one.
- Default to the most identity-secure native option: managed identity over connection strings, RBAC over access policies, private endpoint over service endpoint when full isolation is required.
- Watch for distractors that are real services but solve the wrong layer (e.g., NSG vs. Azure Firewall vs. WAF, or Defender for Cloud vs. Sentinel) and match the tool to the threat and scope.
- Memorize where features live: PIM/Conditional Access/Access Reviews in Entra ID, JIT/Secure Score/Regulatory Compliance in Defender for Cloud, analytics rules/hunting/playbooks in Sentinel.
Study guide FAQ
How is the AZ-500 exam structured and scored?
You get about 40-60 questions in 120 minutes across four domains, including multiple choice, multiple response, drag-and-drop, and occasionally case studies. The score is scaled from 1 to 1000 and you need 700 or higher to pass; the four domains are weighted roughly evenly, so do not neglect any area.
What is the difference between Microsoft Defender for Cloud and Microsoft Sentinel on the exam?
Defender for Cloud is a cloud security posture management and workload protection tool: it scores your security posture, gives recommendations, runs JIT VM access, and provides Defender plans for servers, storage, containers, and SQL. Sentinel is the cloud-native SIEM/SOAR that ingests logs via connectors, correlates them with analytics rules (including Fusion ML), supports hunting, and automates response with playbooks and automation rules.
When should I use a private endpoint versus a service endpoint?
Use a private endpoint when you need full isolation: it assigns the PaaS resource a private IP in your VNet, lets you disable public network access entirely, and requires a linked private DNS zone (e.g., privatelink.database.windows.net). Use a service endpoint when it is enough to keep traffic on the Azure backbone and restrict the resource's firewall to a specific subnet; the resource still has a public endpoint, just locked down by VNet rules.
How do I pick the right key/secret protection answer (Key Vault tiers, TDE, Always Encrypted)?
Match the requirement: choose Always Encrypted when even DBAs must not see plaintext (keys stay client-side), TDE for transparent at-rest encryption (BYOK for key control with zero-downtime rotation), and Managed HSM when FIPS 140-2 Level 3 and single-tenant HSM isolation are required. For Key Vault hardening, expect soft delete + purge protection, RBAC over access policies, versionless secret URIs, and private endpoints with public access disabled.