AZ-500, Microsoft Azure Security Technologies, retired August 31, 2026. The former Azure Security Engineer Associate exam is therefore historical reference material, not a test new candidates should attempt to book. Its subject matter remains relevant to administrators who secure Microsoft Entra identities, Azure networks, workloads and cloud security operations. The important distinction is between an exam's availability and the continued usefulness of its technical practices.

Microsoft's final January 22, 2026 skill outline grouped the exam around secure identity and access, networking, compute/storage/databases, and Defender for Cloud with Sentinel. Microsoft's contemporary SC-500 Cloud and AI Security Engineer Associate track expands some of that work to cloud and AI workloads; it should be evaluated from its own official blueprint rather than described as an identical renumbering. SC-500 is an active, separately scoped credential rather than a new name that makes AZ-500's retired examination schedulable.

Secure human identities and workload access

Security begins by separating authentication from authorization. Microsoft Entra ID establishes who an identity is and under what sign-in conditions it may gain access. Azure role-based access control determines the operations permitted at resource scopes. An administrator who can create a virtual machine might not be authorized to read sensitive records inside its database. Mixing those layers produces either accidental overprivilege or troubleshooting that targets the wrong policy.

For privileged roles, use narrow assignments, review access periodically and require elevation where risk warrants it. Microsoft Entra Privileged Identity Management provides time-bounded activation and approval patterns, but configuration alone is not evidence that the workflow is effective. Review audit logs and simulate what happens when an emergency administrator needs access during an outage. Privileged access with Entra PIM is a natural supporting concept because AZ-500 expected engineers to manage elevated rights rather than merely define them on paper.

Conditional Access can apply risk, device and authentication conditions to sign-ins, but it must be tested for service accounts, break-glass identities and legacy applications that do not meet modern controls. Examine the difference between a rule that requires multifactor authentication and a phishing-resistant method appropriate to especially sensitive administrators. A conditional-access policy that blocks the organization's emergency path can worsen a live incident. Conditional Access design in real organizations gives context to this operational trade-off.

Workloads require a different model. A service principal or managed identity acts on behalf of an application, and granting it broad subscription control because a developer needs one storage operation is a serious design error. Where Azure managed identities apply, prefer scoped rights and avoid unnecessary secret distribution. The managed identity pattern for Azure workloads becomes especially useful when replacing credentials embedded in deployment scripts.

Defend Azure networks as a series of trust boundaries

An Azure virtual network is not inherently a secure boundary just because it has a private address space. Resource exposure depends on routing, subnet placement, network security groups, firewalls, DNS, public endpoints, private endpoints and application-level identities. Start from a communication matrix: which source must contact which destination, using which protocol, and why? That matrix can be implemented and tested more reliably than an accumulating collection of ad hoc allow rules.

NSGs filter permitted flows at subnet or interface scope. Application security groups can make some rules easier to maintain for changing VM populations. User-defined routes steer traffic, which matters when centralizing inspection through a firewall or virtual appliance; they do not themselves inspect application payloads. A routing decision that bypasses the intended firewall is a design failure even when every rule on the firewall is correct.

Private Link and private endpoints are relevant when a platform service should be reachable privately. They require correct DNS resolution as well as endpoint creation. A private endpoint pointing to the right resource is insufficient if clients continue resolving its public address or if on-premises resolvers cannot reach the necessary private DNS records. The relationship between Azure private endpoints and private DNS is therefore both a networking and a security concern.

Layer controls sensibly. Network segmentation reduces the set of routes that can carry malicious traffic; identity authorization determines whether a permitted connection is trusted to perform a specific action. A web application firewall protects against selected HTTP attack patterns but is not a substitute for application validation or secrets management. The core aim of network segmentation as a security control is containment, not the unrealistic promise that any single boundary eliminates compromise.

Secure compute, secrets, databases and storage

Compute hardening begins with a supported image, patch ownership, management-plane permissions and workload-specific operating controls. A VM protected by strict firewall rules may still be compromised through outdated software, exposed remote-management credentials or excessive extension permissions. Containers add image provenance, registry permissions and runtime configuration to the threat model; host and cluster controls must be considered alongside application dependencies.

Azure Key Vault provides mechanisms to manage secrets, keys and certificates. Protect the vault itself, restrict identity access, plan rotation and observe audit events. A key stored centrally is not safe if a compromised application identity can export or misuse it without detection. Differentiate a secret used to connect to a database from a cryptographic key used by a storage encryption process: their storage, lifecycle and recovery requirements are not interchangeable.

Storage protection must address both control-plane and data-plane access. A user might have permission to configure a storage account but not read blob contents; a shared access signature may grant scoped data access even without a broad account-level role. Azure Storage authorization with SAS and Entra ID is relevant to the design choice between temporary delegated access and identity-based access. Minimize public exposure and verify that network restrictions do not undermine essential recovery workflows.

For databases, protect network paths, administrator access, encryption and sensitive queries. Encryption at rest cannot prevent a properly authenticated but overprivileged account from downloading the entire dataset. Logging should make high-impact access and security-configuration changes visible while respecting data-minimization requirements. Use targeted threat modeling to determine which identity, resource or dependency would give an attacker the largest unintended reach.

Build a cloud security posture that produces decisions

Security posture management is not the same as collecting an ever-growing score of recommendations. Microsoft Defender for Cloud can surface risks in Azure resources and workloads, but engineers still must distinguish an exposed attack path from a lower-impact configuration difference. Effective prioritization combines reachability, data sensitivity, business importance and remediation feasibility. The Defender for Cloud posture-management model helps frame those decisions.

Policy initiatives and compliance standards can make expectations consistent across subscriptions, but controls need exceptions with reasons and expiry dates. A policy that blocks all public endpoints without accounting for public-facing application architecture may be unworkable. A policy that only audits violations needs a response owner. Document both the security intent and how enforcement behaves when engineers deploy infrastructure through CI/CD.

Inventory is another prerequisite. Know which accounts, hosts, containers, subscriptions and data stores exist before claiming comprehensive protection. Apply asset ownership and tagging where they improve operations, but do not treat tags as isolation mechanisms. Review workload identity assignments and external service connections because they are often less visible than traditional administrator accounts.

A useful exercise is to start with a plausible compromised identity and draw every resource it can access. Reduce unnecessary role assignments and add alerts for exceptional administrative activity. This is more informative than assuming the absence of a particular security finding means the environment is safe.

Detect and investigate incidents with useful context

Microsoft Sentinel can correlate telemetry and support investigations, but reliable detection starts from the available signals and expected behavior. Identity logs, network flows, cloud activity and application traces tell different parts of a story. Missing retention, clock synchronization or resource identifiers can prevent investigators from reconstructing an event. Centralized collection should define which data is essential and which creates cost or privacy burdens without improving a decision.

An analytic rule should distinguish an event from a security incident. Repeated failed logins may be benign; a sudden privilege elevation followed by a sensitive resource change may require immediate review. Evaluate detections with realistic examples and tune noisy logic rather than permanently disabling it. The Microsoft Sentinel detection strategy is relevant when deciding whether to use analytics rules, threat intelligence and enrichment together.

Investigators need sufficient permissions to view evidence without automatically gaining broad modification rights. Incident response should preserve records, document containment actions and define when to involve legal, privacy or business leadership. Automating suspension of identities or network isolation can be useful, but false positives have material availability consequences. Create an approval and rollback path proportional to the action's impact.

Recovery closes the loop. After containment and restoration, correct the underlying overprivilege, missed patch, exposed endpoint or detection gap. If only the symptom is removed, the same attacker path may remain usable. Security incident response from detection to recovery describes the operational connection between finding, acting and improving controls.

Use legacy AZ-500 material in the current certification landscape

The retired AZ-500 objectives remain a useful map for engineers studying Azure identity, network security, information protection and posture management. They are not proof that a current exam tests identical services in the same proportions. For new certification planning, Microsoft's SC-500 certification should be researched separately because its current remit explicitly includes AI workload protection and cross-cloud/hybrid considerations. Microsoft's published transition announcement establishes a relationship between the credentials, but the practical roles and content must still be compared.

An engineer with an older AZ-500 book can repurpose its network diagrams and security-control explanations, while checking every command and product feature against current Azure documentation. Avoid interpreting old screenshots, permissions names or exam percentages as current authority. Similarly, a retired certification on a résumé describes a credential earned at the time; it does not mean that candidates can still schedule the retired exam.

For a practical study laboratory, create a small application with one user identity, one managed identity, a private service endpoint and recorded security events. Deliberately grant an excessive role, demonstrate the resulting attack path and then reduce access. Test what happens when private DNS is misconfigured, when a compromised workload requests a secret, and when a Sentinel alert needs to identify the responsible deployment. This turns the historic objectives into demonstrable security engineering skills without misrepresenting exam availability.

Keep any call to action current: the AZ-500 page should explain the history and point readers toward provider-maintained contemporary credentials, not encourage new exam bookings. At publication time, verify SC-500 eligibility, title and curriculum directly with Microsoft; an absent approved internal destination must never be replaced by a guessed site URL.