AZ-500 retired on August 31, 2026, so the current value of its blueprint is as a map of Azure security-engineering skills rather than an active exam-registration plan. The final AZ-500 structure placed 15–20% on identity and access, 20–25% on networking, 20–25% on compute/storage/databases, and 30–35% on Defender for Cloud and Microsoft Sentinel. Those areas still form a useful way to understand how Azure security controls connect.
The map works best when it follows an attack and defense path: identity establishes who or what can act, network controls limit where traffic can move, workload and data controls protect resources, and Defender/Sentinel provide posture, detection, investigation, and response. Treating those layers as one system is more useful than memorizing product names.
Identity establishes the trust boundary
Microsoft Entra identities, Azure RBAC, managed identities, application identities, Conditional Access, MFA, and PIM define who or what can access resources and under which conditions. A security design should distinguish authentication from authorization and interactive users from workloads.
An Azure identity and access model is the right starting point because weak privilege can bypass otherwise strong network or data controls.
RBAC and Conditional Access solve different questions
Azure RBAC determines what an identity can do to Azure resources at a scope such as management group, subscription, resource group, or resource. Conditional Access influences whether and how a user can authenticate or access a cloud resource based on context.
A Conditional Access policy can require MFA or block risky access, while RBAC still decides whether the authenticated identity can modify a Key Vault or virtual network.
PIM reduces standing administrative exposure
Privileged Identity Management makes selected roles eligible or time-bound rather than permanently active. Approval, justification, MFA, activation windows, and auditing can reduce how long powerful permissions are exposed.
The map should place PIM between identity governance and administrative operations, because privilege is not merely assigned once and forgotten.
Network segmentation controls movement
VNets, subnets, NSGs, user-defined routes, private endpoints, service endpoints, Bastion, DDoS Protection, Azure Firewall, WAF, and related controls create several enforcement layers. A packet can be routable and still be blocked by policy, or it can be allowed by an NSG and later rejected at an application-aware firewall.
The skill is understanding the traffic path and the purpose of each control.
Centralized and distributed filtering work together
NSGs provide distributed filtering near subnets and interfaces, while Azure Firewall can centralize policy and NAT for broader traffic flows. WAF adds HTTP-aware protection at application-delivery points.
An Azure Firewall design should therefore be mapped alongside NSGs and WAF rather than treated as a universal replacement for them.
Private access reduces public exposure
Private Link/private endpoints bring supported services onto private IP paths, while service endpoints extend VNet identity to supported services through a different model. DNS and routing are especially important with private endpoints because clients must resolve the service to the correct private address.
Security design should make public exposure an explicit decision rather than a default.
Workload security protects compute and applications
VMs, App Service, containers, and other workloads require hardening, patching, endpoint protection, managed identity, encryption, network controls, and workload-specific Defender capabilities. Azure Policy can enforce or audit configuration standards at scale.
The strongest architecture applies controls appropriate to the workload rather than forcing one VM-centric template onto every Azure service.
Key management connects applications with data protection
Secrets, certificates, and encryption keys should be protected as privileged resources. Applications can use managed identity to retrieve material from Key Vault without embedding credentials in source or configuration.
A Key Vault design must also consider permissions, rotation, backup/recovery, and availability; a protected key that the application cannot access becomes an outage.
Defender for Cloud connects posture and workload protection
Defender for Cloud evaluates configuration against security recommendations and standards, surfaces attack paths or exposure context, and provides workload-protection plans for supported resource types. Posture findings can exist before an active attack.
A Defender for Cloud view should therefore feed prioritized remediation, while threat alerts feed investigation and containment.
Sentinel completes the security-operations loop
Microsoft Sentinel provides SIEM/SOAR capabilities around data connectors, analytics, incidents, hunting, automation, and response. It can combine Azure security signals with broader enterprise telemetry and coordinate actions beyond one workload.
Azure role design should include management-group and subscription context. A role assigned at a high scope can flow down to many resources, so a seemingly convenient assignment can create broad exposure. Security engineers need to understand inheritance and use narrower scopes when operationally feasible.
Custom roles should be introduced only when built-in roles cannot express the required permissions. Overly broad custom permissions can be harder to review and maintain than built-in roles, while overly narrow roles can create operational friction that encourages workarounds. Role design is therefore a governance decision as well as an identity decision.
Application identities should be shown beside managed identities. App registrations and service principals may be appropriate for software that needs its own identity, while managed identities reduce credential-management burden for supported Azure resources. Both require least-privilege access and lifecycle ownership.
Network security should also show management-plane versus data-plane access. Azure Bastion or just-in-time VM access reduces exposure of administrative protocols, while NSGs or Firewall govern ordinary traffic. Administrative reachability deserves its own protection path because compromised management access can bypass normal application controls.
DDoS Protection belongs at the availability edge. It helps mitigate volumetric and protocol attacks against public endpoints, while WAF addresses malicious web requests. The same public application can need both because an HTTP injection attempt and a traffic-flooding attack are different threats.
Firewall Manager should be placed above individual firewalls where centralized policy and secured-hub patterns are needed. Centralization improves consistency but also increases policy blast radius, so change review and staged validation remain important operational controls.
Private DNS should sit beside Private Link on the map. A private endpoint can exist correctly while clients still resolve the service to a public address. Security engineers therefore need to treat DNS as part of the private-access design rather than a separate infrastructure detail.
Azure Policy belongs on the governance branch. It can audit, deny, or deploy configuration patterns at scale, complementing Defender for Cloud recommendations. Policy describes or enforces desired state; Defender for Cloud adds posture analysis and security prioritization across the environment.
VM security should include Trusted Launch, disk encryption, endpoint protection, update management, restricted administration, and identity. The map should avoid reducing workload security to “install antivirus.” A compromised VM can expose credentials, data, or lateral-movement paths even when malware detection is enabled.
Container workloads create a different threat surface involving image provenance, registries, orchestrator permissions, secrets, runtime protection, and network policy. The retired blueprint grouped these under compute security, but the architectural lesson is that workload type determines the controls that matter most.
Storage authorization should distinguish Entra/RBAC, shared keys, SAS tokens, network restrictions, and private access. A storage account can be encrypted correctly and still be overexposed because an access key is shared broadly or public access is enabled unnecessarily.
Database security should show identity, firewall/private networking, encryption, auditing, vulnerability assessment, and data classification. A secure database is not just a database with TDE enabled; it is a service whose control plane, data path, and monitoring are all governed.
Defender for Cloud’s regulatory-compliance views should connect security posture to standards and evidence. They help teams assess resource configuration against selected frameworks, but legal compliance can still require process, documentation, privacy, and controls outside Azure.
Attack-path analysis should sit between posture and remediation. A medium-severity weakness can become more urgent when it connects an exposed entry point to privileged identity or critical data. Risk-aware prioritization is stronger than sorting recommendations only by isolated severity.
Sentinel automation should be shown as a controlled response layer. Playbooks can enrich incidents, notify owners, or contain assets, but highly disruptive actions should require confidence and appropriate approval. SOAR is valuable when it reduces repetitive work without creating uncontrolled automated outages.
Security telemetry should include identity sign-in logs, Azure activity logs, network logs, Defender alerts, application logs, and Sentinel data connectors. Each source answers different questions. A good map shows which evidence proves administrative change, network flow, threat behavior, or application impact.
Use the map in incident order as well as architecture order. When suspicious access occurs, identify the identity, confirm privilege, inspect network path, check workload exposure, review Defender findings, and correlate events in Sentinel. This incident-centric view makes the same blueprint useful for both design and operations.
The retired blueprint should also be labeled with its date because Azure products evolve quickly. Skills such as managed identity, Private Link, Defender for Cloud, and Sentinel remain current technologies, but specific exam weighting and product details should not be treated as evergreen certification guidance.
One final way to use the retired map is to assign ownership at every layer. Identity teams own privilege governance, network teams own routing and inspection, workload teams own hardening, data teams own database/storage configuration, and security operations owns detection and response. Clear ownership prevents security findings from becoming nobody’s responsibility.
The skills map should also show that every security control needs evidence. RBAC and PIM generate identity/audit records, NSGs and firewalls produce network logs, Defender produces posture and threat findings, and Sentinel correlates events. A control that cannot be monitored or reviewed is harder to trust during an incident.
The final AZ-500 skills map is identity → network → workload/data → posture → detection/response. Although the AZ-500 blueprint is now retired, that relationship remains a useful architecture model for Azure security work.