AZ-500 is retired, so an October 2026 study plan should be framed as legacy Azure security skills development rather than exam scheduling. The final blueprint still offers a coherent sequence: identity first, network security second, workload and data protection third, and Defender for Cloud/Sentinel last. The retired AZ-500 weights were 15–20%, 20–25%, 20–25%, and 30–35% respectively.
If your goal is current certification, use Microsoft’s active credential paths. If your goal is to preserve or deepen Azure security competence, the final AZ-500 structure remains a practical checklist for hands-on study.
Phase one: establish Entra and Azure RBAC fundamentals
Create a small hierarchy of subscriptions/resource groups and practice built-in role assignments at different scopes. Compare Entra directory roles with Azure RBAC and create one least-privilege custom-role scenario on paper.
Use the identity and access domain as the foundation because every later security control depends on trusted administration.
Phase two: add MFA, Conditional Access, and PIM
In a sandbox, design Conditional Access for ordinary users and privileged users, and define an emergency-access path. Review MFA and risk-related policy concepts, then use PIM or a tabletop to make a powerful Azure role eligible rather than permanent.
A Conditional Access exercise is strongest when you can explain the sign-in condition separately from the Azure resource permissions granted afterward.
Phase three: learn managed identity and application access
Give a test workload a managed identity and grant it access to a narrow resource such as a Key Vault secret or storage object. Compare that with an application registration or service principal using broader permissions.
The study objective is to avoid embedded credentials and reduce privilege for non-human identities.
Phase four: build the network-security path
Create or diagram VNets, subnets, NSGs, UDRs, Azure Firewall, DDoS Protection, WAF, Bastion, and a private endpoint. Trace one inbound and one outbound flow through every enforcement point.
An Azure Firewall lab should include return routing and policy evidence so the firewall is not treated as a box that magically secures every path.
Phase five: practice private service access
Build a private endpoint or detailed tabletop for a PaaS service, then verify DNS resolution and routing. Compare with a service endpoint and document how public access differs.
This is a high-value Azure security skill because many real-world incidents involve public exposure or private-endpoint DNS rather than encryption failure.
Phase six: harden compute and application workloads
Apply security baselines, patching, endpoint protection, managed identity, secure administrative access, and policy to a VM or App Service-style workload. Add container-security or Defender coverage conceptually where appropriate.
The goal is defense in depth at the workload, not enabling every control without checking compatibility.
Phase seven: secure storage, databases, and keys
Review storage authorization, network restrictions, encryption, SAS/access keys, database authentication, private endpoints, auditing, vulnerability assessment, and customer-managed-key patterns. Use Key Vault to centralize sensitive application material.
Then simulate key revocation or overly restrictive network policy so availability implications become clear.
Phase eight: make Defender for Cloud the largest study block
Review Secure Score, recommendations, security standards, regulatory-compliance views, workload-protection plans, vulnerability findings, attack paths, and alerts. Prioritize findings by exposure and business criticality rather than score alone.
A Defender for Cloud lab should end with remediation and verification, not simply opening a recommendation list.
Phase nine: add Sentinel and incident operations
Study data connectors, analytics rules, incidents, entity context, hunting, automation, and response. Use one Azure-focused incident and trace how Sentinel adds broader context from identity, network, and workload signals.
Keep automation proportional to confidence: enrichment can be fully automated more safely than shutting down a critical resource from one uncertain alert.
Finish by mapping legacy AZ-500 to current work
Build one final Azure security architecture with identity, network, compute, storage, policy, Defender for Cloud, and Sentinel. Label the notes with the August 31, 2026 retirement date and the final January 22 blueprint.
Keep one reference environment throughout the study sequence: a hub-and-spoke Azure network, several VMs and PaaS services, one storage account, one database, managed identities, and a central security subscription. Reusing one environment lets identity, network, data, posture, and incident-response controls reinforce each other.
During RBAC study, create one deliberately overprivileged assignment and then reduce it. Compare subscription scope with resource-group or resource scope and note what downstream resources inherit the role. This makes least privilege measurable instead of theoretical.
Add one custom-role tabletop. Start from a business requirement that needs only a few actions, compare built-in roles, and create a custom role only if the built-ins genuinely do not fit. Document who owns the role and how future platform changes would be reviewed.
During managed-identity study, give a test VM or App Service a system-assigned identity, then grant narrowly scoped access to Key Vault or storage. Verify the application can authenticate without a stored secret. This is one of the clearest Azure security patterns to practice hands-on.
During network study, deliberately create one blocked path and one unintentionally open path. Use NSG flow evidence, effective routes, firewall logs, or connection tests to distinguish route failure from policy failure. Security troubleshooting should be evidence-first.
Add an administrative-access exercise using Bastion or a just-in-time pattern. Compare the attack surface with a VM exposing RDP/SSH to the internet. Then document who can request or use the administrative path and how activity is logged.
Add a WAF versus Firewall comparison using a web application. Send a benign HTTP request, a simulated malicious web pattern, and a non-HTTP network flow conceptually. Identify which control sees which traffic and where TLS terminates. This prevents “firewall” products from collapsing into one mental category.
During private-endpoint study, capture DNS before and after enabling private access. Trace the name to the private IP, inspect routing, and confirm public access is handled according to policy. Most Private Link incidents become much easier once DNS is treated as a first-class dependency.
During workload study, apply Azure Policy or a policy initiative to a small scope and inspect noncompliance. Compare preventive enforcement with Defender for Cloud recommendations. This shows the difference between governance policy and security posture analysis.
Add a secure-storage exercise where one user has RBAC access, another has a SAS token, and a third is blocked by network restrictions. Compare authentication, authorization, time limits, and exposure. Storage security becomes more intuitive when the access paths are contrasted directly.
For databases, review Entra authentication, firewall/private endpoint, auditing, encryption, and Defender recommendations. Create a test account with too much privilege and reduce it. The objective is to apply the same least-privilege reasoning used in Azure RBAC to data platforms.
During Key Vault study, rotate a test secret or certificate and observe application impact. Define a recovery procedure before disabling a key. Security controls should improve confidentiality without making application availability dependent on undocumented manual steps.
During Defender for Cloud study, take one recommendation and trace it through owner, remediation, verification, and score/posture change. Then take one workload alert and compare the response. A recommendation and an alert should not lead to the same operational workflow.
Add a regulatory-compliance tabletop. Select a security standard, inspect which Azure controls map to it, and identify which requirements still need organizational processes or evidence outside Azure. This prevents posture dashboards from being mistaken for complete legal compliance.
During Sentinel study, ingest or use demo data from several sources and create one investigation timeline. Identify the initiating event, affected identity, resource, network indicator, and containment action. The goal is correlation, not writing the most complex query.
Add one automation playbook concept with a low-risk action such as enrichment or owner notification and one high-risk action such as disabling access. Decide which can run automatically and which should require analyst confirmation. This makes SOAR governance concrete.
End with a full architecture review: can every privileged identity be justified, every public endpoint be explained, every sensitive secret/key be protected, every critical resource be monitored, and every high-value incident reach an owner? Those questions preserve the best of AZ-500 even after the exam retirement.
Add one “identity-to-data” incident at the end: a risky administrator signs in, changes a network rule, accesses a storage account, and triggers a Defender/Sentinel alert. Trace which log or control proves each step. This integrates the blueprint and reveals whether your study remains too product-specific.
Add one exception-management exercise. A legacy workload cannot immediately meet a policy or private-access requirement. Define compensating controls, monitoring, owner, approval, and a deadline rather than disabling the security standard tenant-wide. Real security engineering includes governed transitions.
Finish by comparing the final AZ-500 topics with the active Microsoft role you actually perform. Carry forward the underlying controls—Entra, Firewall, Key Vault, Defender, Sentinel, Policy, Private Link—while discarding obsolete exam-specific scheduling and percentage assumptions.
Add one policy-as-code or Azure Policy review where a security requirement such as disallowing public exposure is expressed consistently across a resource group. Then compare preventive denial with audit-only policy and Defender recommendations. This reinforces the difference between governance enforcement and security posture detection.
Add one key-recovery tabletop for customer-managed encryption. Define who can administer the key, how rotation occurs, how accidental deletion is protected, and how an application would recover if key access were lost. This turns cryptography into an operational discipline rather than a checkbox.
Keep the final review scenario-based: explain why an administrator who can sign in may still be denied by RBAC, why a private endpoint can fail through DNS, why an encrypted database can still be overexposed through identity, and why a Defender recommendation is not automatically an incident. These contrasts preserve the architecture logic behind the retired blueprint.
The AZ-500 study material remains technically useful, but it should now feed current Microsoft security learning or job runbooks rather than an obsolete exam calendar.