AZ-500 is no longer a live Microsoft certification exam. Microsoft retired Exam AZ-500: Microsoft Azure Security Technologies on August 31, 2026 at 11:59 PM Central Standard Time. Because the assigned topic is AZ-500, the useful October 2026 treatment is to document the final blueprint accurately and make the retired status explicit rather than present it as a current registration option.
The final AZ-500 study guide measured skills as of January 22, 2026. Its final weights were Secure identity and access 15–20%, Secure networking 20–25%, Secure compute, storage, and databases 20–25%, and Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel 30–35%. While active, the exam required a score of 700 or greater to pass.
Secure identity and access was 15–20%
The final domain covered Azure built-in and custom role assignments, Microsoft Entra roles, Privileged Identity Management for Azure resources, MFA, Conditional Access for Azure resources, managed identities, application access, and related identity controls.
An Azure identity and access foundation remains operationally useful because cloud-resource security begins with who or what can perform privileged actions.
Least privilege and PIM were central identity patterns
Azure RBAC should grant only the permissions needed at the appropriate scope. PIM can make high-impact roles eligible or time-limited instead of permanently active. Conditional Access and MFA add stronger access requirements around privileged or risky sessions.
A Conditional Access design is distinct from RBAC: RBAC decides what an identity can do to a resource, while Conditional Access influences whether and how the identity can sign in.
Secure networking was 20–25%
The final scope included NSGs, Azure Firewall, Firewall Manager, Application Gateway/Web Application Firewall, Front Door-related protection, Private Link/private endpoints, service endpoints, DDoS Protection, Bastion, network segmentation, routing/security policy, and secure administrative access.
A centralized firewall and distributed NSG design solve different layers of network control and often appear together.
Private access reduced unnecessary public exposure
Private endpoints and Private Link let supported services be reached through private IP paths, while service endpoints extend VNet identity to supported services through a different model. DNS and routing are critical dependencies for private endpoints.
AZ-500 candidates were expected to understand not only which feature exists but how network security architecture changes the service exposure.
Compute, storage, and database security was 20–25%
This domain included VM security, App Service and container-related security, Azure Policy, disk/storage encryption, Key Vault, Storage security, SQL/database controls, managed identities, backup/recovery-related protection, and advanced security controls for workloads.
A Key Vault model remains important because secrets, keys, and certificates should be governed as privileged resources rather than embedded in application code.
Data protection combined encryption, access, and posture
Encryption at rest or in transit protects confidentiality, but key permissions and access controls determine who can use the data. Storage accounts and databases also rely on network boundaries, identity, logging, and Defender recommendations.
Security engineering requires the control set to work together rather than relying on encryption as a single universal safeguard.
Defender for Cloud and Sentinel dominated at 30–35%
The final largest domain covered security posture management, Microsoft Cloud Security Benchmark alignment, Defender plans/workload protection, recommendations, threat protection, vulnerability management, regulatory compliance, security alerts, and Microsoft Sentinel integration.
A Defender for Cloud perspective connects posture findings with workload protection, while Sentinel provides SIEM/SOAR capabilities for central detection, investigation, and response.
Posture management was not the same as incident response
A misconfigured resource or weak control can appear as a posture recommendation before an attacker exploits it. An alert or incident represents observed suspicious behavior. The security engineer should remediate both, but the priority and response workflow differ.
That distinction remains valuable even though the AZ-500 exam itself is retired.
Hybrid and multicloud context mattered in the final role
Microsoft described the Azure security engineer as implementing, managing, and monitoring security across Azure, hybrid, and multicloud infrastructure, collaborating with architects, administrators, developers, and security operations. The role included regulatory compliance controls across identity, network, compute, storage, data, applications, backup/recovery, and DevOps security.
The final blueprint therefore represented an end-to-end infrastructure security role rather than a collection of Azure portal features.
Use AZ-500 material as legacy skills context, not an exam calendar
The AZ-500 security content still maps to real Azure security work, and many topics continue to matter in newer Microsoft security credentials or job roles. But as of October 2026, new candidates should verify Microsoft’s active certification paths rather than attempting to schedule AZ-500.
The retirement date is the most important current fact. Any resource that still tells readers to schedule AZ-500 after August 31, 2026 is stale. Microsoft continues to host the final study guide for historical reference, which is useful for skills review but should not be mistaken for an active registration path.
The final identity domain also covered custom roles and role scope because built-in roles do not fit every organization. A security engineer should understand management group, subscription, resource group, or resource scope and avoid creating broad custom permissions when a narrower built-in role already exists.
Managed identities were important because Azure workloads frequently need access to Key Vault, storage, databases, or APIs. Managed identity reduces the need to store credentials with the application. The principle remains current across Azure even though the certification code has retired.
Application access in Entra also matters for service principals, app registrations, consent, and permissions. Security engineers need to distinguish human role assignment from application identity and review whether an application has more access than its workload requires.
Network-security design should start with segmentation. VNets and subnets create routing boundaries; NSGs add distributed filtering; Azure Firewall can centralize policy; WAF protects web-layer traffic; DDoS Protection addresses availability attacks; Bastion reduces exposed management ports. Each solves a different layer of the attack surface.
Firewall Manager can centralize policy across Azure Firewall or secured-hub patterns, reducing inconsistent per-firewall configuration. Centralization improves governance but also increases the blast radius of a bad policy, so staged changes and validation remain important.
Application Gateway and WAF should be understood as regional application-delivery/security controls, while Azure Front Door can apply global edge routing and WAF in other architectures. AZ-500 tested enough architecture to choose the appropriate protective layer, not only toggle security features.
Private Link and service endpoints are a useful contrast. Private endpoints give supported services a private-IP presence in a VNet, while service endpoints extend VNet identity to selected services without the same private-endpoint model. DNS is especially important for Private Link because clients must resolve the service to the private address.
Compute-security objectives included hardening virtual machines, App Service, containers, and related workloads. Security engineers should use platform controls, patching, endpoint protection, managed identities, encryption, network boundaries, and Defender plans appropriate to the workload rather than applying one VM-centric template everywhere.
Azure Policy belongs at the governance layer where organizations can audit or enforce resource configuration. Policy can deny risky deployments, deploy settings, or report noncompliance, while Defender for Cloud can assess broader posture and prioritize security recommendations.
Disk and storage encryption should be connected to key management. Customer-managed keys can increase organizational control, but they also create operational dependencies on key availability, permissions, rotation, and recovery. Losing access to a key can become an availability incident.
Storage security includes authentication, authorization, network access, SAS behavior, encryption, logging, and Defender protection. Public access or overly broad shared keys can undermine strong encryption because authorized decryption is still possible through a weak access path.
Database security similarly combines Entra authentication, firewall/private access, encryption, auditing, vulnerability assessment, data classification, and Defender capabilities. The engineer should protect both the database control plane and the data path used by applications.
Defender for Cloud’s Microsoft Cloud Security Benchmark alignment gives teams a structured view of controls across identity, network, data, logging, posture, and other security areas. The benchmark is guidance and assessment; actual risk prioritization still depends on business-critical assets and environment context.
Defender for Servers and other workload-protection plans can provide vulnerability assessment, endpoint/security integration, file integrity or other capabilities depending on service and plan. AZ-500 expected candidates to understand that enabling a plan creates both protection capabilities and operational requirements.
Regulatory compliance dashboards in Defender for Cloud help map resource posture to standards. They support evidence and remediation planning but do not replace an organization’s legal interpretation, broader process controls, or auditor judgment.
Microsoft Sentinel added a central analytics and response layer. Connectors bring security data in, analytics rules create detections, incidents organize investigation, and automation can enrich or respond. A security engineer should know enough Sentinel to integrate Azure infrastructure security with operations.
Security-alert handling should start with scope and evidence. A Defender alert may affect an identity, VM, database, container, or storage resource. Containment actions should be proportional to confidence and business impact, with investigation preserving useful evidence for the security-operations team.
The final AZ-500 role description emphasized collaboration with architects, administrators, developers, and security operations. That is still a useful professional model: security engineers implement controls but rarely own every application, network, or incident process. Cross-team design and remediation are part of the job.
For anyone reusing old AZ-500 notes, label them clearly as “final 2026 blueprint—retired.” Then map useful topics such as Entra, Defender for Cloud, Sentinel, Key Vault, Private Link, Azure Firewall, and Policy into Microsoft’s currently active security learning paths or job requirements instead of assuming the old exam is still available.
Within the broader Microsoft certification ecosystem, the retirement changes the credential path while leaving the underlying identity, network, workload, posture, and security-operations skills operationally relevant.