Microsoft AZ-500 used to be the examination associated with Microsoft Certified: Azure Security Engineer Associate. It was an important assessment of identity controls, network defenses, data protection, security posture, and Azure workload security. It is no longer a current examination: Microsoft retired AZ-500 and the associated certification on August 31, 2026. A candidate reading an older AZ-500 course description should therefore distinguish between learning from historical material and enrolling in an examination that can still be taken.
For learners seeking a current Microsoft credential in this area, the relevant successor is Microsoft Certified: Cloud and AI Security Engineer Associate, earned through the SC-500 examination. That program covers many of the operational security foundations associated with AZ-500 but broadens its scope to hybrid environments, security for AI workloads, and a more integrated cloud-security role. Existing AZ-500 learning materials can still explain useful Azure controls, but they should not be sold or understood as a current certification pathway.
What AZ-500 assessed before retirement
AZ-500 focused on deploying and managing security controls for Microsoft Azure. Its main technical themes included securing identity and access, protecting platforms and networks, securing data and applications, and managing security operations. Candidates needed practical familiarity with Azure administration: creating resources, assigning permissions, interpreting policy, configuring networking, and responding to operational risks. Merely recognizing the names of security products was insufficient.
The security principles remain relevant in production. An administrator still needs to understand why a privileged identity should not have standing administrative access, how a private endpoint affects the exposure of a service, and when a security-policy exception weakens the intended boundary. What has changed is the credential and the current exam blueprint, not the value of those underlying concepts.
SC-500 is the current credential to evaluate
Microsoft introduced SC-500 as the assessment for the Cloud and AI Security Engineer Associate certification. The new profile centers on implementing end-to-end security controls spanning Azure, hybrid environments, and AI-enabled systems. Microsoft identifies four broad exam areas: identity, access and governance; storage, databases and networking; compute security; and management and monitoring of security posture.
Candidates should work from the current SC-500 study guide rather than assuming that an AZ-500 textbook maps directly to the new examination. Some familiar services remain prominent, including Microsoft Entra ID, Azure Key Vault, Azure Policy, Defender for Cloud, Azure networking, and workload-protection technologies. SC-500 also requires attention to AI security and how identities, data access, applications, and monitoring behave when intelligent services or agents are part of the environment.
A precise study plan should compare the official SC-500 skills outline with actual experience. An engineer experienced in virtual machines and firewalls but unfamiliar with AI service controls needs a different plan from someone who works daily with Microsoft Defender and Entra permissions but rarely handles storage or networking.
Identity protection begins with defining authority
Cloud security failures often start with identity decisions rather than an obvious exploit. A role assignment may grant broader privileges than a deployment requires. An application registration may carry enduring permissions no one has reviewed. An emergency administrator account may lack sufficient protection or monitoring. A security engineer must identify where authority originates, what a principal can do, and how that access is governed over time.
Entra role-based permissions, Azure role-based access control, privileged identity management, conditional access, managed identities, and workload identities have distinct purposes. They should not be treated as interchangeable labels for authorization. Access review is especially important when automation accounts, service principals, and AI agents perform actions without an interactive human in the loop. The question is not only whether authentication succeeds, but what harmful action a compromised identity could take afterward.
A useful exercise is to map an application from its identity through its role assignments to the resources it accesses. Identify any credential that can be replaced with a managed identity, distinguish control-plane access from data-plane operations, and test whether permissions can be narrowed without interrupting required work.
Networking and storage require layered decisions
Azure networking is not secured by choosing one product labeled a firewall. A design may combine network security groups, private endpoints, routing controls, application gateways, web application firewalls, DNS configuration, and service-specific access restrictions. A private network path is valuable only when resource policies and identity permissions also support the intended protection.
For data services, assess whether public endpoints are necessary, how access is authenticated, which encryption options are suitable, what audit information is captured, and how recovery is protected. Azure Storage and Azure SQL differ in the controls they expose. Security testing should follow the service’s documented behavior rather than a generalized checklist reused for every database or object store.
Configuration validation matters as much as initial design. An engineer should be able to explain why a connection is permitted, which policy was evaluated, and where a rejected request is logged. Documenting the expected traffic and permission path before deployment makes unexpected exposure easier to diagnose.
Compute protection extends beyond virtual machines
Traditional Azure security programs often emphasized virtual machine configuration, network boundaries, and vulnerability remediation. SC-500 also reaches application platforms, containers, serverless compute, and AI-related deployment infrastructure. Each runtime carries a different set of responsibilities. Security controls that apply to a conventional server may not protect a managed container service or a hosted AI endpoint in the same way.
For virtual machines, assess disk protection, secure-boot capability, remote administration, patching, and workload detection. For managed compute, evaluate identity attachment, runtime configuration, supply-chain exposure, image handling, and network access. For applications, inspect authentication and authorization at the service boundary rather than assuming infrastructure security protects every API operation.
An effective lab deliberately tests both the control and a failure condition. Deploy a resource that should be unreachable publicly; attempt a connection from outside the trusted path; then trace the result using the available diagnostic tools. A configuration that looks correct in the portal but has never been exercised is not sufficient evidence of resilience.
AI security introduces new assets and permissions
AI workloads can expose sensitive information through retrieval systems, prompts, agent permissions, connected tools, or poorly governed data sources. Traditional cloud controls still matter: authentication, scoped authorization, encryption, segmentation, monitoring, and incident response remain foundational. They must now be applied to systems that can summarize retrieved content or invoke downstream services on a user’s behalf.
Security engineers should identify who can configure a model endpoint, which identities can access underlying data, what external services an agent may call, and how output or tool-use activity is audited. Prompt filtering and content policies do not replace identity enforcement. An agent that can use an overprivileged connector may cause harm even when the user’s natural-language request appears benign.
Testing should include least-privilege access to retrieval sources and tools, logging of sensitive operations, handling of malicious or untrusted input, and safe behavior when a dependent system is unavailable. These are practical capabilities, not isolated definitions to memorize for a multiple-choice exam.
Defender for Cloud and monitoring are operational disciplines
Security posture management identifies risks, recommends controls, and provides a view of coverage, but its value depends on how teams prioritize and respond to findings. A large backlog of recommendations is not proof that the environment is becoming safer. Engineers need to distinguish material exposure from low-risk noise, assign remediation owners, and validate that changes actually close the problem.
Defender for Cloud, security monitoring tools, activity logs, resource logs, and incident workflows provide different views of the same environment. A useful investigation combines those signals with asset criticality and expected behavior. For example, a suspicious role assignment followed by unusual storage access should be interpreted as a connected sequence rather than two unrelated alerts.
Practice should emphasize traceability: determine what happened, why the control allowed it, what evidence supports the conclusion, and which remediation can prevent recurrence without breaking legitimate operations.
How to use an old AZ-500 course responsibly
Historical AZ-500 material is still useful when it teaches a control that remains part of modern Azure environments. A module explaining Azure RBAC, Key Vault access models, or network isolation may be an effective refresher, provided the commands, user interface, permissions, and service behavior are checked against current documentation. A course that teaches obsolete configuration steps as current or promises eligibility for a retired exam requires correction.
Organize material into three groups: still-valid foundational concepts; service behavior requiring a current documentation check; and retired examination logistics that should no longer guide a purchase. Replace the last group with Microsoft’s present SC-500 examination information. The separation prevents historical exam names from leaking into current planning while preserving worthwhile engineering knowledge.
Selecting the next step
Someone already holding Azure Security Engineer Associate can still describe the skill earned during its active period, but should verify how retirement affects the credential’s current status and any linked program requirements. Someone seeking a new Microsoft security engineering certification should evaluate SC-500 and its official preparation resources. An employer designing a training path should specify current skills and job tasks rather than mandating completion of a retired exam code.
The transition is a reminder that a certification is a time-bound assessment of evolving work. Microsoft AZ-500 remains a useful historical signpost for Azure security, while SC-500 provides the relevant contemporary exam context. The strongest preparation emphasizes operating real controls, understanding failure modes, and using the current official blueprint before booking a test.
