Microsoft AZ-500 — Azure Security Engineer

The AWS Certified Security – Specialty page on this site is written for a team that lives in AWS. This page is the same exam-shaped question asked of a team standardized on Azure instead: exam AZ-500: Microsoft Azure Security Technologies, which earns the credential Microsoft Certified: Azure Security Engineer Associate. Below: what it actually tests, a direct service-by-service map from AWS terms to their Azure equivalents so your existing security vocabulary transfers instead of starting from zero, the four skills-measured domains with real Azure config for each, and a straight answer on who should sit it.

What the AZ-500 actually is, and who it's for

☺ Like you're 10: It's a scored, timed exam full of scenarios and case studies about locking down an Azure environment — not a live cluster you get handed and told to fix.

AZ-500 sits at Microsoft's Associate tier, not "Specialty" despite how often that word gets used loosely around it in casual conversation — Microsoft's own specialty-level exams are a separate, smaller tier (things like the Cybersecurity Architect Expert sit above it). It targets Azure security engineers: people who implement and manage identity, platform, data, and application security controls across an Azure tenant, and who monitor and remediate what those controls catch. Microsoft's stated recommended background is prior experience with Azure administration, Azure development, and DevOps processes, plus a working grasp of security fundamentals — the CIA triad, defense in depth, least privilege — going in. There is no formally enforced prerequisite exam, but candidates who arrive without any Azure administration experience (the territory of AZ-104) tend to spend exam time relearning Azure basics instead of demonstrating security judgment.

The Azure-native counterpart to AWS Security Specialty — a straight service map

☺ Like you're 10: Same jobs, different brand names — here's the dictionary that translates one cloud's security vocabulary into the other's.

If your team already reasons in AWS terms, the fastest way into AZ-500 is not to relearn security concepts from scratch — it's to relearn where Azure keeps the same lever. This table is the direct counterpart to whatever mapping you'd build studying the AWS exam; the concepts on the secrets management, cloud security posture, and detection engineering pages elsewhere on this site apply to both columns equally.

Format, cost, and exam-day logistics

☺ Like you're 10: A timer, a screen full of scenarios, a pass mark out of 1000 — and, unlike most certs on this site, a badge that renews itself for free every year instead of quietly expiring.

↗ Microsoft's official AZ-500 exam page

The four domains, weighted

☺ Like you're 10: Four topics, none of them tiny — unlike the CKA's one giant 30% slice, AZ-500 spreads its weight fairly evenly across all four.

Microsoft publishes these as ranges, not single exact numbers the way the CNCF's curricula do for the CKA and CKS — a detail worth internalizing before you study, because it means "Identity is worth 27%" is a claim the exam itself never actually makes. The ranges below are the shape most recently and consistently published for AZ-500's skills-measured outline; treat the midpoints used for the bar widths as a study-planning aid, not a scored fact.

Regroup those same four domains by which security-lifecycle question they answer, and a shape falls out that will look familiar to anyone who's used the NIST Cybersecurity Framework's core functions: one domain is almost entirely about who gets in, two domains are almost entirely about what they can reach once they're in, and one domain is entirely about noticing when something goes wrong anyway.

Domain by domain: what's actually tested, and where to study it here

☺ Like you're 10: Here's the real Azure Portal and CLI work behind each of those four percentages, and the exact page here that teaches the underlying concept.

Manage identity and access — 25–30%

The largest domain, and it's entirely Microsoft Entra ID plus Azure RBAC. Published competencies cluster around: securing Entra ID users, groups, and external identities (B2B guest access); configuring Entra ID Identity Protection to score sign-in and user risk; configuring Conditional Access policies that grant or block access based on device compliance, location, and that risk score; implementing Privileged Identity Management (PIM) so high-privilege roles are activated just-in-time instead of standing permanently; and securing application identities — app registrations, service principals, and managed identities — so workloads authenticate without a hardcoded secret anywhere.

// A Conditional Access policy (Microsoft Graph conditionalAccessPolicies schema):
// any sign-in to a privileged directory role, from outside a trusted named location,
// must satisfy MFA before it's granted.
{
  "displayName": "Require MFA for admin roles from untrusted locations",
  "state": "enabled",
  "conditions": {
    "users": { "includeRoles": ["62e90394-69f5-4237-9190-012177145e10"] },
    "applications": { "includeApplications": ["All"] },
    "locations": { "includeLocations": ["All"], "excludeLocations": ["AllTrusted"] }
  },
  "grantControls": { "operator": "OR", "builtInControls": ["mfa"] }
}

# Azure RBAC — least privilege at a specific scope, not a blanket subscription-wide role
az role assignment create \
  --assignee 4b2f1c9a-... \
  --role "Reader" \
  --scope /subscriptions/<sub-id>/resourceGroups/rg-app

# a managed identity replaces a stored client secret entirely — the platform issues
# and rotates the credential; the app code never sees it
az vm identity assign --resource-group rg-app --name vm-api

Study here: Workload Identity & Pipeline IAM covers the "no static credential" principle behind managed identities directly — it's the same SPIFFE-adjacent instinct applied to Azure's own identity primitive. Cloud security posture covers the structured, line-by-line IAM review discipline that a Conditional Access and PIM audit is really asking for. Secrets management covers why a hardcoded credential is the failure mode all of this exists to eliminate in the first place.

Secure networking — 20–25%

Everything here is about controlling what can reach a resource over the network before identity ever enters the picture. Published competencies: planning and implementing Network Security Groups (NSGs) and Application Security Groups; securing public endpoints with Azure Firewall and a Web Application Firewall (WAF) on Application Gateway or Front Door; configuring Azure DDoS Protection; and — the single highest-leverage habit in this domain — replacing public exposure of a PaaS service with Private Link/Private Endpoints so traffic never touches the public internet at all.

# deny RDP from the internet outright — the single most common Azure misconfiguration finding
az network nsg rule create \
  --resource-group rg-hub --nsg-name nsg-app \
  --name deny-rdp-inbound --priority 100 --direction Inbound --access Deny \
  --protocol Tcp --source-address-prefixes Internet --destination-port-ranges 3389

# an Azure Firewall network rule — explicit allow, default deny behind it
az network firewall network-rule create \
  --resource-group rg-hub --firewall-name fw-hub --collection-name allow-dns \
  --name allow-dns-egress --protocols UDP --source-addresses 10.0.0.0/16 \
  --destination-addresses 168.63.129.16 --destination-ports 53 --action Allow --priority 200

# pull a storage account off the public internet entirely
az storage account update --name stgapp01 --resource-group rg-app --default-action Deny
az network private-endpoint create --name pe-stgapp01 --resource-group rg-app \
  --vnet-name vnet-app --subnet snet-data \
  --private-connection-resource-id $(az storage account show --name stgapp01 --query id -o tsv) \
  --group-id blob --connection-name pe-conn-stgapp01

Study here: Zero Trust for Pipelines covers the "never trust the network perimeter alone" principle that Private Link and default-deny NSGs are the concrete Azure implementation of. CNAPP & the Unified Cloud Security Stack covers how a modern posture tool like Defender for Cloud actually surfaces an over-permissive NSG or a publicly reachable storage account as a finding rather than something you'd only catch by reading rules manually.

Secure compute, storage, and databases — 20–25%

The workload layer: what's actually installed, stored, and queried once identity and network have both said yes. Published competencies: securing VMs (disk encryption, Just-in-Time VM access, endpoint protection), securing containers (AKS via Azure Policy/Gatekeeper and Microsoft Defender for Containers, ACR image scanning), managing Key Vault — keys, secrets, and certificates, including the RBAC-versus-access-policy permission model — and securing storage accounts and databases (SAS token scoping, encryption at rest, Transparent Data Encryption, Dynamic Data Masking).

# Key Vault has two permission models — legacy vault access policies, and Azure RBAC
# on the vault resource itself. Microsoft now recommends RBAC; know both for the exam.
az keyvault update --name kv-prod --enable-rbac-authorization true
az role assignment create --assignee <principal-id> \
  --role "Key Vault Secrets User" \
  --scope $(az keyvault show --name kv-prod --query id -o tsv)

# TDE is on by default for new Azure SQL databases with a service-managed key;
# rotating to a customer-managed key means Azure SQL's own encryption depends on Key Vault
az sql db tde set --resource-group rg-data --server sql-prod --name appdb --status Enabled
az sql server key create --resource-group rg-data --server sql-prod \
  --kid https://kv-prod.vault.azure.net/keys/tde-key/<version>

Study here: Secrets management and Cryptography & Key Management together are this domain's Key Vault and encryption-at-rest core. Kubernetes Security Deep Dive covers the cluster-hardening half that AKS-specific competencies map onto directly. Container & supply-chain security covers the image-scanning discipline ACR's own scanning integration is enforcing.

Manage security operations — 15–20%

The smallest domain and the one that only matters once the other three have already let something through. Published competencies: configuring and evaluating Microsoft Defender for Cloud (Secure Score, regulatory compliance dashboard, per-resource-type Defender plans); building and tuning Microsoft Sentinel analytics rules and workbooks; investigating incidents and hunting through Sentinel with Kusto Query Language (KQL); and configuring Azure Monitor and Log Analytics diagnostic settings so the signal actually exists to investigate in the first place.

// A Sentinel analytics rule scaffold — flag any account with more than 10
// failed sign-ins (invalid username/password, ResultType 50126) in a 15-minute window
SigninLogs
| where ResultType == "50126"
| summarize FailedAttempts = count() by UserPrincipalName, bin(TimeGenerated, 15m)
| where FailedAttempts > 10

Study here: Detection Engineering & Security Observability is this domain's technical core — the false-positive-tuning discipline it teaches for any SIEM applies to a Sentinel analytics rule exactly as written. Compliance & governance covers what Defender for Cloud's regulatory compliance dashboard is actually assembling evidence toward. IaC security & policy as code covers Azure Policy's deny/audit/deployIfNotExists effects, which is how a Secure Score recommendation becomes something the platform enforces automatically instead of a dashboard nobody reads.

Who should take it, and where it sits among the other certs here

☺ Like you're 10: The right test for someone whose cloud is Azure — the wrong one for someone who just wants a general security credential that works anywhere.

Take it if your organization's workloads genuinely live in Azure and you're the person (or want to be the person) configuring Entra ID Conditional Access, reviewing Key Vault access models, and triaging Defender for Cloud recommendations day to day. It's also a reasonable hiring signal specifically for Azure-shop roles, the same way the AWS Security Specialty page describes for AWS shops.

Skip it, or deprioritize it, if any of these fit. Your organization runs on AWS or GCP — the vocabulary in the mapping table above transfers, but the exam itself does not; sit AWS Certified Security – Specialty or Google Cloud's Professional Cloud Security Engineer instead. You're new to Azure entirely — AZ-500 assumes AZ-104-level administration fluency going in; arriving without it means spending exam time relearning what a resource group is instead of demonstrating security judgment. You want a cloud-agnostic credential — CISSP or the CDE, both covered elsewhere on this site, test security management and DevSecOps practice independent of any one cloud vendor.

Within this course's own certification ladder, treat AZ-500 as sitting beside the AWS and GCP cloud-security credentials rather than above or below them — three parallel, vendor-specific proofs of the same underlying competence, not a progression from one to the next. If your team runs multi-cloud, there's real value in having someone who's sat more than one of the three; the AWS-to-Azure table above is the fastest bridge between any two of them. Full side-by-side comparisons of every certification on this site live on the certifications hub.