Microsoft AZ-500 Azure Security Engineer Readiness Matrix After Retirement: Diagnose Transferable Azure Security Skill Gaps

 

Microsoft retired AZ-500: Microsoft Azure Security Technologies on August 31, 2026. It can no longer be scheduled, so this readiness matrix is not a current booking checklist. It uses the final AZ-500 skills blueprint as a structured way to diagnose transferable Azure security engineering capability: identity and access, networking, compute/storage/database protection, and security operations with Microsoft Defender for Cloud and Microsoft Sentinel.

The final published blueprint, dated January 22, 2026, grouped the retired exam into four areas: secure identity and access at 15-20%, secure networking at 20-25%, secure compute, storage, and databases at 20-25%, and secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel at 30-35%. Those percentages are historical exam weights, not a current certification target. They remain useful only as a record of the relative breadth Microsoft expected from an Azure security engineer at the end of the exam’s life.

Use this matrix to answer a practical question: if someone asked you to secure a real Azure environment today, which of these capabilities could you explain, configure, validate, and troubleshoot without relying on memorized exam language?

Use a four-level evidence scale

Score each skill by evidence rather than confidence.

Level 0 – unfamiliar. You cannot explain the purpose of the control or identify when it belongs in an Azure security design.

Level 1 – conceptual. You can define the service or feature and recognize common use cases, but you need step-by-step guidance to configure it and cannot reliably diagnose mistakes.

Level 2 – applied. You can configure the capability in a safe lab or real environment, explain the security effect, compare it with nearby alternatives, and validate that it behaves as intended.

Level 3 – operationally ready. You can handle a new scenario, select the control for a reason, implement it with appropriate least-privilege and monitoring choices, recognize common failure modes, and explain how the control fits into broader defense-in-depth.

The retired exam itself is no longer the target, so Level 3 should be interpreted as practical transferability rather than “exam ready.” Your goal is to identify which legacy AZ-500 skills still form a useful Azure security foundation.

Matrix area 1: Azure role assignments and least privilege

Start with Azure RBAC. You should be able to explain the difference between assigning broad permissions at a subscription and narrowly scoped permissions at a resource group or resource. You should understand built-in roles, custom roles, scope inheritance, and why convenience assignments can create excessive privilege.

Level 2 evidence: given a small scenario, you can choose an appropriate built-in role and scope, assign it, verify effective access, and remove the assignment cleanly.

Level 3 evidence: you can recognize when a built-in role is too broad, design a constrained custom role where justified, explain management-plane versus data-plane implications where relevant, and validate that a user or workload can perform the required action but not unrelated privileged actions.

A strong self-test is to secure a two-team environment in which one team manages network resources and another manages application resources. Avoid solving the problem with Owner or Contributor everywhere.

Matrix area 2: Privileged Identity Management

The final AZ-500 identity domain included Microsoft Entra Privileged Identity Management for Azure resources. PIM changes how privileged access is granted by making elevation controlled, time-bound, and auditable rather than permanently active.

Level 1 knowledge recognizes eligible versus active access. Level 2 means you can configure an eligible assignment in a lab and explain activation requirements. Level 3 means you can reason about approval, MFA, justification, activation duration, access reviews, and emergency-access considerations without turning PIM into a checkbox.

Ask what problem PIM is solving. It does not make a highly privileged role harmless. It reduces standing privilege and adds governance around when access becomes active.

Matrix area 3: MFA and Conditional Access for Azure resources

Multi-factor authentication and Conditional Access are frequently discussed together, but your readiness should go beyond saying “enable MFA.” Conditional Access evaluates signals and applies policy decisions under defined conditions.

Level 2 evidence: you can describe and configure a policy that targets the intended users or workload, uses appropriate conditions, and requires a control such as MFA without accidentally locking out necessary administrative access.

Level 3 evidence: you can reason about exclusions, break-glass accounts, report-only evaluation, location/device/risk signals where applicable, policy interaction, and the difference between identity protection and application authorization.

A useful scenario is administrative portal access from unmanaged devices. Decide what should be blocked, what should require stronger authentication, and how you would stage the policy safely.

Matrix area 4: enterprise applications and OAuth permissions

The final blueprint included enterprise applications, OAuth permission grants, app registrations, permission scopes, and consent. This is an area where security engineers often need to distinguish identity objects and permission models rather than memorize portal labels.

Level 2 evidence: you can explain the relationship among an app registration, service principal/enterprise application, requested permissions, and consent. You can inspect what an application is allowed to access and identify unnecessarily broad permissions.

Level 3 evidence: you can analyze a scenario involving delegated versus application permissions, recognize high-risk consent, reduce scopes, and connect app access to monitoring and review.

The key security question is always: what identity is acting, what resource is being accessed, under what permission, and who authorized that permission?

Matrix area 5: service principals and managed identities

Applications need identities too. A common weak pattern is embedding long-lived credentials in code or configuration because it is easy to understand. Managed identities are designed to reduce credential-handling burden for supported Azure resources.

Level 2 evidence: you can explain system-assigned versus user-assigned managed identity at a conceptual and practical level, grant the identity only the required role, and validate access to a target resource.

Level 3 evidence: you can choose between managed identity and another service-principal pattern for a reason, rotate or remove unnecessary credentials, diagnose access failures, and avoid giving the workload excessive rights simply because authentication succeeded.

The security objective is not merely “make the app connect.” It is “make the app connect using a controlled identity with minimum necessary privilege.”

Matrix area 6: network security groups and application security groups

Network security groups are fundamental traffic controls. Application security groups help organize network-interface membership so NSG rules can express application roles more cleanly.

Level 2 evidence: you can create rules based on source, destination, protocol, and port, understand priority processing, and verify effective rules. Level 3 means you can diagnose why traffic is blocked or allowed, recognize overly broad rules, and use grouping to reduce brittle IP-based policy where appropriate.

A useful lab is a simple web/app/data pattern. Permit only the flows required between tiers, then deliberately break a rule and trace the effective security decision.

Matrix area 7: Virtual Network Manager and centralized network policy

The final blueprint included Azure Virtual Network Manager. Readiness here means understanding why centralized connectivity and security administration can be valuable across multiple virtual networks and subscriptions.

Level 2 evidence: you can explain the difference between manually maintaining many network configurations and applying centrally managed intent. Level 3 means you can reason about scope, deployment, verification, and the operational risk of a centralized policy that is too broad.

The important concept is governance at scale. A centralized control plane can reduce drift, but it can also amplify mistakes. Security engineering therefore includes staged deployment and validation.

Matrix area 8: routing, peering, VPN, Virtual WAN, and ExpressRoute protection

Secure networking is not only about blocking ports. Route design determines where traffic goes and which controls it traverses. The final blueprint included user-defined routes, peering, VPN, Virtual WAN, and ExpressRoute encryption topics.

Level 2 evidence: you can explain how a route affects packet paths, distinguish common private-connectivity options, and identify where traffic inspection or encryption requirements apply.

Level 3 evidence: you can reason through asymmetric routing, forced tunneling, transitive-connectivity expectations, gateway placement, and how a security appliance or firewall fits into the path.

Use diagrams. Draw source, destination, route table, next hop, gateway, and inspection point. If you cannot explain the actual packet path, the security control is probably not fully understood.

Matrix area 9: Network Watcher and network diagnostics

A security engineer should be able to validate network behavior, not merely configure controls. Network Watcher capabilities help investigate connectivity and network state.

Level 2 evidence: you can choose a diagnostic approach when a connection fails and distinguish “blocked by policy” from “wrong route” or “name resolution” at a basic level. Level 3 means you build a repeatable troubleshooting sequence and preserve evidence before changing controls.

A common mistake is opening a broad firewall rule to see whether a problem disappears. That can prove something, but it also creates risk. Prefer diagnostics that identify the failing layer precisely.

Matrix area 10: Private Endpoints and Private Link

Private connectivity to Azure services is a major design pattern. A Private Endpoint gives a supported service a private IP presence in a virtual network through Private Link.

Level 2 evidence: you can explain why private access can reduce exposure, configure a basic private endpoint, and understand the role of DNS. Level 3 evidence includes diagnosing private DNS issues, deciding what public network access should remain, and validating that clients resolve and reach the intended private address.

Do not treat “private endpoint created” as proof that public exposure is removed. Security depends on the service configuration, DNS, routing, and access policy together.

Matrix area 11: TLS, Azure Firewall, Application Gateway, Front Door, WAF, and DDoS

These controls protect different layers and traffic patterns. A common readiness gap is recognizing the names but not the boundary between them.

Build a comparison matrix. Azure Firewall provides centralized network security and traffic filtering capabilities. Application Gateway operates as a web traffic load balancer and can integrate a web application firewall. Front Door provides global application delivery capabilities and can use WAF for edge protection. DDoS protections address volumetric and protocol-level denial-of-service concerns. TLS protects data in transit when configured correctly.

Level 3 evidence: given an internet-facing web application, you can explain which controls address routing, web threats, encryption, global ingress, network filtering, and DDoS rather than proposing one product as the answer to every threat.

Matrix area 12: secure administrative access with Bastion and JIT

The final blueprint included Azure Bastion and just-in-time VM access. Both reduce exposure of administrative paths but do so differently.

Level 2 evidence: you can explain how Bastion provides managed remote connectivity without directly exposing VM management ports to the public internet and how JIT reduces the time a management port is open under controlled conditions.

Level 3 means you can select an approach based on architecture, operational requirements, and threat model, and verify that broader inbound rules have not undermined the intended control.

Matrix area 13: AKS security and container protection

Kubernetes security spans identity, network, secrets, image provenance, runtime behavior, and monitoring. The retired exam sampled only part of that space, but the transferability is high.

Level 2 evidence: you can identify basic cluster security controls, manage access deliberately, and recognize why container registry and workload identity choices matter. Level 3 means you can connect cluster configuration to Defender coverage, monitoring, vulnerability findings, and least-privilege workload access.

Do not let Kubernetes vocabulary hide basic security questions: who can deploy, what images are trusted, what network paths are allowed, what secrets exist, and how suspicious activity is detected?

Matrix area 14: Azure Container Registry security

Container registries are supply-chain assets. Security includes authentication, authorization, network access, image governance, and vulnerability awareness.

Level 2 evidence: you can restrict who can push and pull, avoid shared broad credentials, and understand private access options. Level 3 means you can integrate registry security into deployment policy and investigate how a vulnerable or untrusted image could enter the environment.

Matrix area 15: disk and storage encryption

The final blueprint included disk encryption, storage protection, customer-managed keys, bring-your-own-key patterns, and double encryption. Avoid memorizing feature names without threat-model context.

Level 2 evidence: you can explain encryption at rest, identify who controls keys, configure a supported key-backed protection in a lab, and verify the result. Level 3 means you can reason about key lifecycle, permissions, availability, rotation, separation of duties, and what encryption does not protect.

Encryption does not compensate for an identity with excessive data permissions. Storage security combines encryption, authorization, network controls, logging, and data-protection settings.

Matrix area 16: database identity and data protection

The final blueprint included Microsoft Entra authentication for databases, auditing, dynamic data masking, Transparent Data Encryption, and Always Encrypted.

Build comparison knowledge. Authentication controls who can connect. Auditing records relevant activity. Dynamic data masking changes how sensitive values are exposed to some users but is not a cryptographic boundary. TDE protects data files at rest. Always Encrypted is designed for stronger protection of selected sensitive values with separation from the database engine under the appropriate model.

Level 3 evidence: given a requirement, you can identify which layer it addresses and avoid claiming that one control substitutes for the others.

Matrix area 17: Azure Policy and security governance

Azure Policy lets organizations evaluate and enforce resource configuration rules at scale. Level 2 evidence means you can assign a policy or initiative in a safe scope, understand compliance results, and distinguish audit behavior from enforcement/remediation behavior.

Level 3 means you can design rollout carefully, use exemptions deliberately, investigate noncompliance, and avoid breaking workloads with an untested deny policy.

Security governance succeeds when policy communicates intent, detects drift, and creates accountable remediation rather than simply producing a dashboard full of red indicators.

Matrix area 18: Key Vault and secret/key governance

Key Vault concepts intersect identity, cryptography, application design, and operations. Level 2 evidence: you can store and retrieve secrets or keys using controlled identities and permissions. Level 3: you can reason about access models, network restrictions, rotation, logging, backup/recovery considerations, and separation of duties.

A self-test is to take an application that currently stores a secret in configuration and redesign it so the application authenticates appropriately and retrieves only the secret it needs.

Matrix area 19: Defender for Cloud posture management

The final AZ-500 blueprint placed substantial emphasis on Defender for Cloud and Sentinel. Defender for Cloud posture capabilities include secure score, recommendations, inventory, regulatory compliance views, and broader cloud-security posture management.

Level 2 evidence: you can interpret recommendations and trace them to affected resources. Level 3 means you can prioritize findings based on exposure and business impact, understand exemptions, connect recommendations to policy/governance, and avoid treating secure score as the security program itself.

A score is a signal, not a substitute for threat modeling or incident response.

Matrix area 20: Defender workload protection, vulnerability management, and DevOps security

Workload protection covers detection and protection capabilities across supported resource types. The final blueprint also included vulnerability management and DevOps security.

Level 2 evidence: you can enable and interpret relevant protection in a lab, investigate an alert or vulnerability finding, and understand the affected asset. Level 3 means you can connect findings to remediation ownership, risk, deployment pipelines, and repeatable operational response.

Avoid a “turn everything on and trust the dashboard” mindset. Security engineering includes validating coverage, understanding data sources, and confirming that alerts reach people who can act.

Matrix area 21: Microsoft Sentinel data connectors and analytics

Sentinel depends on data. Level 2 evidence means you can explain how connectors bring relevant security data into the environment and how analytics rules identify patterns or conditions worth investigating.

Level 3 evidence includes choosing useful data sources, recognizing ingestion/noise trade-offs, tuning detections, understanding entity context, and tracing an alert back to raw evidence.

A detection that fires constantly without useful signal is not automatically strong security. Quality matters as much as quantity.

Matrix area 22: Sentinel automation and incident workflow

Automation can enrich, notify, or respond to security events. Level 2 evidence means you can describe a simple automated action tied to a security workflow. Level 3 means you can decide which actions are safe to automate, which require analyst confirmation, and how to avoid creating a response loop that damages availability.

This is where accountability and operational safety become concrete. Automation should reduce repetitive work without hiding decisions that require human judgment.

Turn the matrix into a heat map

Create a table with the 22 areas above and columns for conceptual knowledge, hands-on configuration, validation, troubleshooting, and operational reasoning. Score each 0-3.

Do not average the numbers immediately. Look for patterns. You may be strong in identity but weak in network path analysis. You may know Defender dashboards but lack Sentinel detection experience. You may understand encryption conceptually but have never handled key permissions or rotation.

Those patterns are more useful than a single “readiness percentage.” Because AZ-500 is retired, there is no reason to optimize for an old passing threshold. Optimize for practical gaps that matter to the Azure security work you want to perform.

Use legacy practice only as a historical diagnostic

If you use AZ-500 practice questions, treat them as legacy diagnostic material. AZ-500 cannot be scheduled. The value of an old question is whether it exposes a transferable concept you still need: RBAC scope, network segmentation, storage protection, Defender posture, Sentinel detection, and so on.

For every question, add a practical follow-up. If the item tests NSGs, build and validate a rule. If it tests managed identity, configure a small workload. If it tests Sentinel, trace how data reaches the analytic rule. Do not memorize an answer associated with a retired exam.

The Azure security practical preparation guide can turn low-scoring matrix rows into hands-on exercises.

A six-session remediation sequence

Session one: identity and privilege. Practice RBAC, PIM concepts, Conditional Access, managed identities, and app permissions.

Session two: network enforcement. Work through NSGs, routes, private endpoints, DNS, firewall/WAF boundaries, and diagnostic tools.

Session three: compute and data. Review Bastion/JIT, container security, disk/storage encryption, Key Vault, and database protection.

Session four: posture and policy. Use Azure Policy and Defender for Cloud findings to identify configuration gaps and remediation priorities.

Session five: detection and response. Work with Sentinel connectors, analytics, incidents, and safe automation.

Session six: integrate. Analyze a complete architecture and identify identity, network, data, posture, detection, and response controls together.

The sequence is intentionally capability-focused. It does not pretend that completing it earns a retired certification.

Final transferability gate

You have a strong transferable AZ-500 foundation if you can do more than recognize control names. You can map identities to least-privilege access, reduce standing privilege, protect application identities, design network paths and segmentation, secure private access, protect compute and data, manage keys and secrets, enforce policy, interpret Defender posture, ingest security telemetry, build useful detections, and reason about response automation.

More importantly, you can explain why each control exists and what failure it prevents. You can validate whether the control actually works. You can distinguish preventive, detective, and response layers. And you can avoid solving every problem with the broadest role, widest firewall rule, or most powerful security product.

AZ-500 itself is now historical. The security engineering habits represented in its final blueprint remain valuable only when they are converted from exam memories into current, testable Azure skills. Use this matrix to identify that conversion work honestly.

Scenario diagnostic 1: secure a subscription used by three operations teams

Assume one subscription contains shared networking, application resource groups, and a security operations workspace. A network team needs to manage network resources, an application team needs to deploy application components, and a security team needs visibility plus selected response permissions.

A weak design grants Contributor at subscription scope to all three teams. It works quickly, but it erases separation of duties and expands the blast radius of compromised credentials.

Use the matrix to decompose the problem. RBAC should align permissions with job function and scope. PIM can reduce standing privilege for high-impact administrative roles. Conditional Access can strengthen the conditions under which privileged users authenticate. Activity and security logs should support accountability. If custom roles are proposed, verify that built-in roles truly cannot meet the requirement before creating another role that must be maintained.

Level 3 evidence is not a diagram alone. Configure a reduced version in a lab, sign in with test identities, verify the allowed actions, confirm denied actions, and document the path an operator would use when temporary elevation is required.

Scenario diagnostic 2: private application access to a storage-backed service

An internal application must use a supported Azure service without relying on public network exposure. The application has a managed identity and runs in a virtual network. The security team wants private connectivity, controlled name resolution, and least-privilege data access.

This scenario crosses several matrix rows. The managed identity addresses workload authentication. RBAC or the service’s supported authorization model defines what the workload can do. Private Endpoint/Private Link addresses network reachability. Private DNS ensures the service name resolves to the intended private path. Storage or service encryption still protects data at rest, while logging and policy provide governance.

A common mistake is to stop after creating the private endpoint. A Level 3 review checks whether public network access remains enabled, whether DNS resolves correctly from the consuming network, whether the workload identity has excessive data permissions, and whether a route or firewall configuration prevents the intended connection.

This scenario illustrates why mature security readiness is compositional. No single feature makes the application “secure.”

Scenario diagnostic 3: an internet-facing application with layered controls

An application is available globally and must protect web traffic, backend networks, administrative access, and sensitive data. Build the control map before naming products.

At the edge, global routing and web application firewall capability may be relevant. At the application ingress layer, Application Gateway and WAF may fit depending on the architecture. Network-layer filtering can involve Azure Firewall and NSGs. DDoS protection addresses a different threat class. TLS protects transport. Private endpoints can reduce public exposure for backend services. Bastion or other controlled management paths reduce direct administrative-port exposure. Key Vault and managed identity can reduce secret sprawl. Defender and Sentinel provide posture and detection layers.

The readiness test is whether you can explain boundaries. WAF is not a replacement for RBAC. DDoS protection is not a replacement for application-layer filtering. Encryption at rest is not a replacement for access control. Defender findings are not a replacement for fixing the configuration.

If you can describe the layered purpose of each control and verify at least a representative subset in a lab, your knowledge is moving beyond exam-era memorization.

Scenario diagnostic 4: Sentinel receives too many low-value alerts

A security team connects several data sources to Microsoft Sentinel and enables many analytics rules. The result is a large number of repetitive incidents that analysts close quickly without investigation.

A Level 1 response says “add automation.” A stronger response asks whether the detection logic is useful, whether the right data is being ingested, whether thresholds or exclusions are appropriate, whether entities are enriched, and whether incidents represent real investigation units.

Automation should come after signal quality is understood. It may enrich incidents, notify responders, or perform a safe containment step, but automating a noisy detection can amplify the problem. Level 3 readiness means you can trace a detection from source data to rule logic to incident, tune it with evidence, and decide which response steps can be automated safely.

This scenario also tests accountability. Someone must own rule quality, exceptions, automation permissions, and post-incident improvement.

Scenario diagnostic 5: protect a database containing sensitive customer data

A database holds confidential customer records. The organization wants identity-based access, protection at rest, reduced exposure of sensitive fields, audit evidence, and strong protection for selected high-value columns.

Break the requirements apart. Microsoft Entra authentication addresses identity. Authorization still defines what authenticated identities may do. TDE addresses database files at rest. Dynamic data masking can limit presentation of sensitive values in appropriate cases but should not be described as encryption. Auditing records relevant events. Always Encrypted can provide stronger protection for selected columns under the applicable architecture. Network controls and private connectivity may reduce exposure paths.

A Level 3 candidate can explain why choosing one of these does not satisfy all the others. That is the recurring pattern across the matrix: security requirements are layered, and readiness depends on understanding each layer’s job.

How to prioritize gaps without an active exam deadline

Because AZ-500 is retired, you are free from the artificial pressure to repair every topic equally for a test date. Prioritize by your actual role and the risk of the environments you manage.

If you administer identities and subscriptions, RBAC, PIM, Conditional Access, managed identities, app permissions, and policy may deserve immediate attention. If you operate platform networking, path analysis, private endpoints, DNS, firewall/WAF boundaries, and diagnostic tooling may come first. If you work in security operations, Defender posture, vulnerability findings, Sentinel data connectors, analytics, incidents, and automation may be the most transferable areas.

Then schedule integration reviews so specialization does not create blind spots. An identity specialist still needs enough network knowledge to understand private access. A SOC analyst still needs enough Azure architecture knowledge to interpret what an alert means. A platform engineer still needs enough detection knowledge to ensure security telemetry exists.

Use the old blueprint as a map of neighboring skills, not as a reason to study obsolete exam trivia.