SC-500 Exam Guide and Six-Week Study Plan

Microsoft’s SC-500 exam is a security engineering assessment rather than a vocabulary test. Its full title, Implementing End-to-End Security Controls for Cloud and AI Workloads, describes the work: connect identity controls, network paths, data protection, compute security and monitoring so an Azure or hybrid environment remains defensible. An answer that secures one component but leaves another exposed may not satisfy the scenario.

SC-500 is associated with the Microsoft Certified: Cloud and AI Security Engineer Associate credential. It is the current pathway after AZ-500 retired on August 31, 2026, but it is not merely AZ-500 with a new name. The older Azure security skills remain relevant; the current exam explicitly includes protecting AI services, Copilot and agents, along with cloud posture and operations. Candidates should arrive with hands-on Azure and hybrid administration experience, strong Microsoft Entra familiarity and working knowledge of Microsoft 365.

This six-week plan is an editorial example, not a Microsoft-prescribed schedule or a passing guarantee. It starts with controls you can inspect in a permitted test subscription, uses realistic evidence-driven exercises and leaves room for a candidate to revisit weaker skills. Do not attempt security changes in production simply to rehearse an exam objective: use a sandbox, test tenant or approved lab, establish a rollback path and understand resource charges.

Read the official domains as one connected security system

Microsoft’s current SC-500 study guide, updated May 13, 2026, lists four domains. The percentages are ranges for assessed skills, not a promise about the number of questions in each domain. There is no separate fifth AI security domain: AI security is assessed within Secure compute. Ignoring traditional VM, container and application controls because AI is topical would therefore be a serious preparation error.

Notice that storage, databases and networking carry the largest individual weight band. A candidate can know Entra Conditional Access extremely well and still struggle if they cannot distinguish storage data-plane permission from a network firewall, a private endpoint from a service endpoint or a local NSG from a Virtual Network Manager security admin rule. The existing storage and database controls and private networking decisions offer useful conceptual foundations.

Some objective bullets name products that are relatively new or still have rollout and licensing distinctions. Study the security principle and consult the current product documentation when you build the lab. Do not assume a preview-only Foundry portal capability is available by default in every tenant, or that a newly announced AI-agent feature automatically has the same permissions as an ordinary employee account.

Prepare the environment and an evidence log

Choose a subscription and identity you are authorized to use, ideally isolated from production. Understand which resources are free, which bill per hour and which have tenant-wide security effects. For SC-500, safe experimentation often means reading configuration and evaluating a planned policy before enabling enforcement. If a practice step could block users, cut off network access or change live auditing, arrange an explicit approval and rollback plan first.

Keep a simple lab record with six columns: requirement, existing configuration, candidate control, expected result, test evidence and rollback. This habit matters more than taking dozens of portal screenshots without context. A configuration that looks right can still be defeated by another permission, network route or service setting. The evidence column should establish what your change actually enforced.

For access and governance labs, use test users, test groups and scoped resource groups. For data labs, use synthetic storage blobs and sample database records. For AI workloads, use harmless model prompts and dummy documents without personal information. For Sentinel, use sanctioned test logs rather than manufacturing realistic production incidents. Keep any credentials out of screenshots, code examples and shared notes.

You do not need a large environment. A single controlled identity example, one storage account, an illustrative network path, a sample application or VM configuration and a small log flow can teach most of the relevant decisions. Where a service is unavailable because of cost, licensing or regional support, use the official configuration documentation and explain the intended control boundary rather than claiming you tested it.

Week one: Entra identity, PIM and Key Vault

Begin with who or what is requesting access. Compare a human user, a service principal, a managed identity and an AI-agent identity. Authentication confirms an identity, whereas authorization determines what that identity may do. Conditional Access can govern sign-in or token issuance based on context, while Azure RBAC and application permissions determine the permitted actions after an identity is established. They solve related but different problems.

Use a test PIM assignment to compare eligible and active privilege. A user may be eligible for a role without holding it continuously; activation can involve approval, MFA, justification and time limits. Write down what event grants authority and what removes it. Review how emergency access is protected without making the organization dependent on an unavailable administrator. The privileged access scenarios provide the reasoning behind these configurations.

Move to Key Vault and a sample application. Decide whether the application can authenticate through managed identity instead of storing a password. Then inspect the permission model, private or restricted network access, rotation and deletion protection. Test the thought experiment of an exposed credential: the correct response involves revocation or rotation, logs, dependent applications and remediation of the original leak. Merely putting a secret in Key Vault does not solve a compromised identity.

Finish by comparing Azure RBAC, Microsoft Entra roles and Azure Policy. An Azure Policy definition can govern resource configuration and deny or remediate certain deployments; it is not a substitute for permission assignments. A resource lock can protect against certain destructive actions but is not a full data-protection strategy. For week-one readiness, explain which control you would use for an overprivileged user, a misconfigured storage account and a leaked certificate—and why the same product is not the answer in all three cases.

Week two: storage and Azure SQL protection

Storage security starts with two independent questions: who has data access, and from which network path can that access occur? Prefer Microsoft Entra authorization and appropriately scoped storage data-plane roles when supported. A shared account key is highly privileged and less granular; a public network path can still be dangerous even when credentials are strong. Compare private endpoints, an explicitly restricted public endpoint and trusted service exceptions, then write down which dependencies each choice could break.

Create a fictional storage scenario where a web app needs to read one container while a deployment system needs to write another. Explain why assigning Owner at subscription scope is excessive and why an NSG rule alone is not authorization to a storage blob. Consider whether Shared Key authorization can be disabled without breaking legacy clients. If a change is proposed, identify the client dependencies and a way to verify behavior before enforcement.

For Azure SQL Database, distinguish platform access from database-level permissions and auditing. Encryption at rest does not prove that application users can read only authorized rows. Auditing records security-relevant activity but does not stop a query by itself; Defender for Databases provides threat detection signals rather than replacing access rules. Document which control mitigates exposure, detects suspicious behavior and supports an investigation.

Study the path between an application and an Azure SQL logical server. If the requirement says access must not traverse the public internet, evaluate a private endpoint and associated DNS behavior, as well as any service access restrictions. Verify application connectivity after changes. The important exam skill is combining identity, network policy, encryption, audit and detection without treating any one of them as a complete solution.

Week three: network controls and troubleshooting

Network scenarios demand a packet-flow model. Draw the source, destination, port and relevant network boundaries before choosing an Azure control. NSGs filter traffic at subnet or network-interface scope. Application security groups help express rules around workload groups. Azure Virtual Network Manager can deploy security admin rules across targeted network groups at a broader governance scope. Those central rules are evaluated before NSG rules and have different actions.

In particular, a Virtual Network Manager Allow security admin rule can pass traffic onward for NSG evaluation; Always Allow and Deny terminate evaluation for matching traffic. An app-team NSG cannot reverse a central Deny decision. The precise distinction matters because a scenario may ask why locally opening a port still leaves the application unreachable. Check exceptions for specialized subnets and managed networks rather than assuming every service is affected identically.

Add a PaaS access scenario. A private endpoint represents a particular resource through a private IP within a virtual network; it does not, by itself, establish that all identities should have data access. Private Link services, Azure Firewall, Virtual WAN security, site-to-site VPN and Microsoft Entra Private Access address different routes and trust boundaries. Select the narrowest control that satisfies the requirement and preserves necessary service flows.

When a request fails, investigate with the right diagnostic evidence. Is DNS resolving the intended private address? Is a central security admin rule stopping traffic before the NSG? Is the firewall evaluating the correct destination? Are PaaS network settings blocking public traffic, or is the application identity unauthorized? Azure Network Watcher effective-rule diagnostics can explain a network enforcement decision, but a 403 from the resource may indicate an authorization problem after the route succeeded.

Week four: secure VMs, containers and application services

Server controls include disk encryption, trusted launch, secure boot, vTPM, Azure Bastion, just-in-time access and Defender for Servers. Build a simple comparison of which layer each protects. Bastion reduces exposure associated with direct management access; JIT limits the window in which certain management ports are open; disk encryption protects stored data; Defender adds posture, vulnerability or runtime signals. None is a replacement for disciplined identity and patch management.

Review Azure Arc for hybrid and non-Azure servers and clarify how coverage and security policies extend to those machines. Defender for Servers may combine installed detection components with agentless scanning. A scan result is not the same as an incident or a guarantee that the server is patched. Practice taking a high-risk recommendation and identifying the owner, safe fix, exception criteria and evidence required to close it.

For AKS and containers, separate the control plane, workload identity, node security, images in Azure Container Registry and runtime networking. A registry vulnerability finding requires different remediation from an API endpoint exposed without authentication. Azure Functions, Logic Apps and App Service also need deliberate identity, secrets, ingress and egress controls. API Management can enforce security policy at an API boundary, while Web Application Firewall addresses web traffic risks at its configured entry point.

Conclude by tracing a request to a containerized application: client access, WAF/API boundary, service identity, network and data store. Which layer would detect a suspicious request? Which controls could block it? What happens if a deployment introduces a risky container image? This sequence forces the same cross-layer reasoning the exam expects.

Week five: security for AI workloads

AI security lives inside SC-500’s Secure compute domain. Start by examining an authorized document assistant or Copilot scenario. The most dangerous failure may not be an obviously malicious prompt—it may be a useful assistant accurately retrieving a document that was shared far too broadly. Microsoft Purview Data Security Posture Management can help surface oversharing and exposure risks; SharePoint permissions and labels need to be corrected at their source rather than depending on the assistant to keep a secret.

Next, distinguish agent identities from users and ordinary app registrations. Microsoft Entra Agent ID introduces agent-specific concepts and governance. Conditional Access and authorization must be targeted to the correct subject and supported resource; an agent using a raw API key will not magically be protected by a policy that only evaluates an Entra token. When a scenario names blast-radius analysis, ask which resources the agent can reach and what Defender XDR evidence shows.

On the model/API side, consider a Foundry deployment fronted by an Azure API Management AI gateway. Rate limits, quotas, policy checks and telemetry may apply at the gateway, while agent instructions and model guardrails address different risks. Defender for AI-related workloads and Defender for Cloud’s Data and AI security dashboard contribute detection and posture evidence. A gateway token limit does not prevent data oversharing; prompt instructions do not replace data authorization.

Your week-five practice artifact should be a small risk table: data exposure, agent permission, tool misuse, model output and monitoring. Assign a control to each, then specify the test or log showing it worked. Version- and licensing-sensitive features must be checked against current Microsoft documentation rather than assumed generally available in every tenant.

Week six: Defender posture, Sentinel and exam readiness

Defender for Cloud helps engineers prioritize risk across assets. CSPM recommendations, security standards, vulnerability findings and attack paths give different kinds of evidence. A secure-score increase is not automatically equivalent to reducing the most consequential attack path. Practice choosing a remediation based on a reachable asset, exposed secret, affected data and business criticality, rather than selecting the easiest low-severity recommendation.

For hybrid and multicloud, inspect how Defender for Cloud connects AWS accounts, GCP projects and Azure or Arc-managed resources. Coverage depends on connector configuration, plan selection, identity and permissions; a connected account is not proof that every workload is protected. Microsoft Defender External Attack Surface Management can reveal internet-exposed assets that internal inventories miss, creating a separate investigation starting point.

Then build a Sentinel data-flow diagram: a source emits events, a connector or data collection mechanism routes them, a workspace stores appropriately scoped data, an analytic or investigation uses the records, and automation acts under its own permissions. Understand Windows Security Event collection through data collection rules, Windows Event Forwarding, Syslog or CEF inputs, custom tables and retention. Automation rules determine triggering/orchestration; a Logic Apps playbook executes configured actions with a bounded identity.

Security Copilot is the assistance layer in this domain, not a replacement for Sentinel and Defender. Explain which workspace and plugins are configured, who has permission to invoke an extension, what data it can see and why an analyst must verify consequential actions. The Security Copilot operations discussion gives a foundation for separating AI assistance from source-of-truth security tools.

Finish the week by reviewing several combined scenarios. An overprivileged identity reads a sensitive storage account over a public endpoint and triggers an alert. Which permission and network controls could have prevented access? Which Defender and Sentinel signals would show the attempt? If an automated playbook makes a change, how is its permission bounded? The strongest answers identify the failing layer and the smallest effective remedy.

How to judge readiness without memorizing a service catalog

Microsoft currently lists a 120-minute assessment and a passing score of 700. Do not treat an unofficial question count or someone else’s time-management rule as part of the binding specification. Check exam details, languages, accommodations and latest assessed skills shortly before scheduling. Microsoft’s exam sandbox can help you become familiar with the interface, but it cannot validate that you know how to secure a real workload.

When practice results are weak, classify the reason rather than merely repeating questions. Was the mistake about selecting a security control, understanding its enforcement boundary, choosing a diagnostic tool, or confusing evidence with action? Revisit the smallest relevant lab and explain the correction in plain language. Readiness looks like coherent security decisions across identity, data, networking, compute and operations—not being able to recite a hundred product names.