SC-500 Microsoft Cloud and AI Security Engineer Study Guide

Independent AI-assisted resource — HUMAN REVIEW PENDING. The October 28, 2026 team refresh reconciles this complete guide and detailed objectives with current public exam, product and learning evidence. See the current group report and sources-and-objectives record. Source limits and unexecuted exercises remain explicit. This is not human review or live product validation. The official blueprint is authoritative.

Study guide at a glance

Start here

Report an issue with SC-500

Blueprint checked2026-10-28

Review stateReview required

Guide-only active reading1 hr 45 min–2 hr 15 min

Prerequisites: Practical Azure and hybrid administration across identity, compute, networking and storage; strong Microsoft Entra knowledge; Microsoft 365 familiarity; and hands-on security engineering with Key Vault, Azure Policy, Defender for Cloud, Sentinel, containers, application platforms, Microsoft Foundry, agents, AI gateways, and Security Copilot.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Lab 1: Privileged access and overprivilege review, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

• Manage identity, access, and governance20–25%
• Secure storage, databases, and networking25–30%
• Secure compute20–25%
• Manage and monitor security posture20–25%

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current baseline: The official study-guide page was last updated May 13, 2026; Microsoft publishes no separate skills-effective date on that page.
Exam state: Active and no longer labeled beta; the credential page lists no retirement date.
Transition: AZ-500 retired on August 31, 2026. SC-500 is its active successor and adds substantial AI, agent, Microsoft 365, and modern posture content; an AZ-500-only resource is not complete SC-500 preparation. Microsoft documented the transition in its May 2026 announcement.
Upcoming blueprint change: None announced on the official study guide as checked October 28, 2026. Current detailed objective text is unchanged.
Practice Assessment: Not currently available. Microsoft says one is usually published within eight weeks after an exam leaves beta and becomes generally available. VERIFY CURRENT on the credential page.
Official source: SC-500 study guide

The September deep-review report maps all 87 objectives. The blueprint is unchanged; the updates below distinguish current product support, release announcements, and original practice exercises.

How to use this guide

SC-500 is an implementation exam across a very wide control surface. It expects more than feature recognition: you should be able to choose a control, place it at the correct identity, management, network, data, compute, or runtime boundary, configure its dependencies, prove that it works, and explain what remains unprotected.

Use this operating chain for every topic:

business asset and threat
  -> subject, workload, data, and trust boundary
  -> preventive control and least-privilege scope
  -> configuration and licensing dependencies
  -> telemetry, detection, response, and recovery
  -> evidence, exception, owner, and revalidation date

Read Sections 1–4, work the three integrated scenarios, complete or tabletop all ten labs, and answer the 48 original answered checks. Use disposable tenants and subscriptions, synthetic data, budgets, and explicit teardown plans. Defender plans, Security Copilot, Microsoft 365 security features, private networking, firewalls, and AI services can create license or consumption charges. Never weaken or expose a production environment simply to reproduce an exercise.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

Exam profile and complete objective map

The credential is intermediate. Microsoft expects practical Azure and hybrid administration across compute, networking, and storage; strong Microsoft Entra familiarity; and Microsoft 365 administration familiarity. The current credential page lists 120 minutes, ten exam languages, and an exam sandbox, but no Practice Assessment. Confirm administrative details on the Cloud and AI Security Engineer Associate credential page.

Official domain	Weight	Engineering question
Manage identity, access, and governance	20–25%	Who can administer or use each resource, how is privilege constrained, where are secrets held, and how is policy enforced?
Secure storage, databases, and networking	25–30%	How are data-plane access, encryption, exposure, segmentation, inspection, and database evidence controlled?
Secure compute	20–25%	How are AI, server, VM, container, serverless, web, and API workloads protected from configuration through runtime?
Manage and monitor security posture	20–25%	How are cloud risks prioritized, telemetry collected, automation governed, and Security Copilot safely operated?

Published objective-to-guide map

Published objective area	Primary coverage	Practice evidence
PIM, Conditional Access, authentication methods, app identities, OAuth consent, and managed identities	Section 1	All scenarios; Labs 1–2
Key Vault deployment, access, networking, object lifecycle, CSPM secret scanning, and Defender for Key Vault	Section 1	Scenarios 1 and 3; Lab 2
Azure Policy, Defender standards/compliance/recommendations, locks, built-in/custom roles, overprivilege, Backup, and IaC controls	Section 1	Scenarios 1–2; Labs 1 and 3
Storage account security, firewall, Defender for Storage, and access policies	Section 2	Scenarios 1–2; Lab 4
Azure SQL platform security, auditing, and Defender for Databases	Section 2	Scenarios 1 and 3; Lab 4
NSG/ASG, Virtual Network Manager, Virtual WAN, VPN, Entra Private Access, Private Link, Azure Firewall, and Network Watcher	Section 2	All scenarios; Lab 5
SharePoint/Copilot data exposure, Copilot Studio protection, Entra Agent ID, AI Gateway, Defender for AI Services, Foundry guardrails, Data and AI dashboard, and Microsoft 365 agents	Section 3	Scenarios 1 and 3; Lab 6
Disk encryption, Bastion, JIT, Arc, Defender for Servers, vulnerability/EDR/agentless scanning, Trusted Launch, and Machine Configuration	Section 3	Scenario 2; Lab 7
Defender for Containers, AKS, ACR, ACI, Container Apps, Functions, Logic Apps, App Service, WAF, and APIM back-end policies	Section 3	Scenarios 1 and 3; Lab 8
Defender CSPM, compliance, workload plans, AWS/GCP, vulnerability management, and EASM	Section 4	All scenarios; Labs 3 and 7
Sentinel workspaces/roles/content/connectors, AMA/DCR/WEF/Syslog/CEF/custom tables, automation, retention, and Purview Audit	Section 4	Scenario 2; Labs 3 and 8
Security Copilot workspaces, roles, plugins, Microsoft agents, and Security Store agents	Section 4	All scenarios; Lab 8

1. Manage identity, access, and governance

Treat identity as the control plane

Begin by separating identities, scopes, and authorization systems:

Object or decision	Control plane	Typical control
Human administration of Entra	Microsoft Entra directory	Entra role, PIM, Conditional Access, strong authentication
Azure resource management	Azure Resource Manager	Azure RBAC at management group, subscription, resource group, or resource
Access to stored data	Service data plane	Storage data role, SQL permission, Key Vault data role, or application authorization
Application identity	Entra application/service principal	App registration, enterprise application, credential, consent, app assignment
Azure-hosted workload identity	Azure resource plus Entra	System- or user-assigned managed identity and scoped RBAC
AI agent identity	Entra Agent ID and its host	Agent identity lifecycle, permissions, Conditional Access, inventory, monitoring

Authentication establishes who or what the subject is. Authorization establishes what the subject may do. Conditional Access evaluates sign-in context; it does not replace resource authorization. PIM makes supported role or group access eligible, time-bound, approved, and auditable; it does not prove that the role itself is least privileged. Review Microsoft's current PIM overview and Conditional Access overview.

Use PIM for privileged Entra roles and Azure resource roles where licensing and support allow. Configure activation duration, justification, ticket information, approval for the highest-impact tasks, strong authentication, notification, and access review. Keep two tested cloud-only emergency accounts outside ordinary Conditional Access policies, tightly monitor them, and do not use them for routine work. PIM eligible assignment reduces standing access; it does not protect a permanently overpowered service principal or a secret already stolen from a pipeline.

Build Conditional Access in report-only mode, examine results, exclude emergency access identities deliberately, then stage enforcement. Model users and workload identities, target resources, network/device/risk conditions, grant controls, session controls, authentication strengths, and policy exclusions. Avoid one giant policy: a small composable set is easier to test and recover. Passwordless methods and phishing-resistant authentication are stronger than SMS or voice, but method availability, registration, recovery, and device dependencies must be designed together.

Related item: Microsoft Entra roles and Azure RBAC roles can both appear in one incident but answer different questions. Compromise of a Global Administrator can affect the directory; compromise of an Owner can affect Azure authorization. Map escalation paths between them instead of reviewing each role list in isolation.

Secure application and workload identities

An app registration is the definition of an application in its home tenant. A service principal is the tenant-local instance through which the application receives assignments and consent. An enterprise application is the administrative view of that service principal. Do not use the terms as interchangeable when troubleshooting consent, credentials, or assignments.

For each application:

1. Identify whether it is single-tenant or multitenant and who owns it.
2. Prefer delegated permissions when a signed-in user and user context are required; use application permissions only for justified unattended access.
3. Request the smallest API permission and resource scope. Separate ordinary user consent, verified-publisher policy, admin consent workflow, and tenant-wide admin grant.
4. Prefer a managed identity or federated credential over a client secret. If a certificate or secret is unavoidable, inventory the owner, store it in Key Vault, rotate before expiry, and alert on use or failure.
5. Require assignment where appropriate, review owners and consent grants, remove unused credentials and permissions, and monitor service-principal sign-ins.

Managed identities eliminate application-managed credentials, not authorization. A system-assigned identity shares the Azure resource lifecycle and is deleted with it. A user-assigned identity is independent and reusable, so its permissions may outlive or span workloads. Treat reuse as a blast-radius decision. The managed-identities overview documents lifecycle and supported-resource behavior.

OAuth consent is authorization to call an API, not a general declaration that an app is safe. Inventory delegated and application grants, app-role assignments, credential age, sign-in activity, publisher verification, and ownership. Removing a visible enterprise application without understanding its provisioning, federation, or automation dependency can cause an outage; pilot revocation and retain rollback evidence.

Related item: CI/CD should normally use workload identity federation so a pipeline obtains short-lived tokens from a trusted external identity rather than storing a long-lived Azure client secret. The trust still needs narrow subject, audience, environment, and Azure RBAC scope.

Secure Azure Key Vault as a boundary, not just a container

Choose vault ownership, region, recovery, tenant, network access, authorization model, logging, private DNS, and object lifecycle before inserting secrets. Enable soft delete and purge protection according to recovery requirements. Separate control-plane permission to configure the vault from data-plane permission to read keys, secrets, or certificates.

With Key Vault API version 2026-02-01 and later, RBAC is the default authorization model for newly created vaults; this does not automatically migrate existing access-policy vaults. Prefer Azure RBAC for new deployments because it provides a consistent role-assignment model, supports PIM, and separates key, secret, and certificate duties through built-in roles. Legacy vault access policies remain supported in some environments, but a principal with control-plane permission to change access policies may grant itself data-plane access. Do not mix authorization models casually. Microsoft's Key Vault RBAC guide explains recommended built-in roles and scope.

Network controls are independent of identity controls. Public endpoint access can be allowed, restricted to selected networks, or disabled in favor of private endpoints. A private endpoint requires correct VNet routing and private DNS resolution; merely creating it does not stop use of the public endpoint. Service endpoints and trusted-service exceptions have different trust semantics. Verify both allowed and denied paths using the same DNS resolver and network context that the workload uses. See Key Vault network security.

Do not treat publicNetworkAccess: Disabled as proof that every non-private-endpoint path is blocked. The vault resource schema and detailed network documentation retain the trusted-service exception. Review the bypass setting and supported service/scenario; Azure DevOps is not generally on that list. The network page’s broad “private endpoint only” wording must be read with this explicit exception. Network Security Perimeter enforcement has different exception behavior. Test the actual caller, DNS, route, and authorization together.

Manage each object as a lifecycle:

• Keys: choose software or HSM protection, permitted operations, rotation policy, version retention, backup/restore, and consumer rollover.
• Secrets: avoid them where federation or managed identity works; otherwise set expiry, rotate, test consumers, and prevent values from entering logs or deployment outputs.
• Certificates: understand issuer, policy, renewal, exportability, private-key handling, version activation, and downstream binding.

Defender CSPM secret scanning is a posture capability that discovers exposed or plaintext secrets in supported cloud resources and code paths. Defender for Key Vault is workload threat protection that alerts on suspicious access patterns and operations. Neither rotates a credential or fixes access automatically. Investigate exposure, revoke/rotate, remove the source, validate consumers, and hunt for misuse. Review the current Defender for Key Vault overview because plan features and alert logic can change.

Enforce governance without confusing policy, permission, and protection

Azure Policy evaluates resource state against definitions. An initiative groups policy definitions. Common effects include audit, deny, append, modify, and deployIfNotExists; effect support depends on the resource alias and evaluation mode. A deny protects future or updated state but does not repair existing noncompliance. modify and deployIfNotExists may require a managed identity, role assignments, remediation tasks, and careful handling of existing resources. Start with audit, inspect exemptions and false positives, remediate, then enforce. The Azure Policy effects reference is more reliable than memorizing portal labels.

Custom definitions should be versioned as code, tested against compliant and noncompliant fixtures, and deployed through controlled scopes. Record assignment parameters, enforcement mode, noncompliance messages, managed-identity roles, exemptions, expiry, owner, and rollback. Policy is not RBAC: it constrains resource configuration, while RBAC authorizes operations. A resource lock blocks supported delete or write operations even for otherwise authorized users, but it does not protect data-plane operations and can disrupt automation. Apply locks only after testing dependent deployments, backup, scale, and incident procedures.

Defender for Cloud turns standards and policies into recommendations, secure score, compliance views, attack paths, and remediation workflows. Regulatory compliance is evidence about assessed controls, not a legal certification and not proof that every control is effective. Validate scope, plan/licensing requirements, exemptions, responsibility, evidence freshness, and compensating controls. The current regulatory-compliance dashboard documentation describes how standards and assessment data are presented.

For roles, prefer built-ins and narrow scope. A custom Azure role defines management/data actions and assignable scopes; a custom Entra role contains supported directory permissions. They are not interchangeable. To find overprivilege, combine effective role assignments, PIM eligibility/activation, group nesting, service-principal grants, last activity, ownership, resource sensitivity, attack paths, and business need. Remove permissions incrementally with monitoring and rollback rather than assuming “unused” means “safe to delete.”

Azure Backup security should include vault authorization, soft delete, immutability where appropriate, multi-user authorization through Resource Guard, encryption, private connectivity where supported, alerting, and isolated recovery testing. Backup is not complete until restore is proven and privileged deletion paths are constrained. Microsoft's Azure Backup security overview describes current protective controls and their prerequisites.

Infrastructure as code should express secure defaults, identities, private access, diagnostics, policy assignments, Defender plans, locks, and role scopes—not only the workload. Pin or govern modules, scan templates, lint and test policy behavior, use federated deployment identity, require review for privilege/network changes, protect state, record deployment outputs without secrets, and detect drift. A successful template deployment proves API acceptance, not control effectiveness; add negative tests and runtime evidence.

Related item: An exemption is a governed risk decision, not a way to make a dashboard green. Give it an owner, justification, narrow scope, compensating control, expiry, and revalidation trigger.

2. Secure storage, databases, and networking

Secure storage from identity through recovery

Start with data classification and access pattern, then choose account type, redundancy, region, encryption, network exposure, authorization, retention, immutability, logging, threat protection, and recovery. Management-plane access to configure an account does not automatically grant Blob, Queue, Table, or File data access.

Prefer Microsoft Entra authorization and data-plane RBAC for supported workloads. Shared Key authorizes broadly and enables account-level SAS, so disable Shared Key when every dependency supports Entra. A service SAS scopes to one service; an account SAS can span services; a user-delegation SAS is signed using an Entra-derived user delegation key and is preferred for Blob scenarios. Limit service, resource type, permission, start/expiry, IP/protocol, and stored access policy where supported. Do not place SAS tokens in source, tickets, shell history, or durable logs.

A stored access policy applies to a service SAS, not an account SAS or user-delegation SAS. Choose a revocation strategy that matches the credential type. A resource lock does not prevent data-plane deletion through an otherwise authorized credential.

Storage firewall rules control the public endpoint. Selected VNets, IP rules, resource instance rules, and trusted-service exceptions are distinct decisions. Private endpoints give a private IP for a service subresource such as Blob or File; configure every required subresource and private DNS zone, validate on-premises resolution, and explicitly disable or constrain public access. A service endpoint keeps the PaaS public endpoint but conveys VNet identity; it is not Private Link.

Encryption at rest is enabled by default, but customer-managed keys add Key Vault/Managed HSM availability, identity, version, rotation, and recovery dependencies. Infrastructure encryption adds a second encryption layer for supported accounts. Object versioning, soft delete, point-in-time restore, immutable storage, and backup solve different failure modes. Design retention and legal hold without preventing legitimate lifecycle or recovery operations.

Defender for Storage can provide activity monitoring, malware scanning, and sensitive-data threat detection depending on the current plan and configuration. Scope and billing matter: event volume, malware-scanned data, exclusions, and plan settings should be baselined. It raises alerts; it does not replace least privilege, private access, or data recovery. Review Defender for Storage before implementation because plan components and pricing can change. VERIFY CURRENT: confirm supported account types, malware limits, exclusions, and cost before enabling at scale.

Related item: Storage access policies are not one universal object. Azure RBAC, SAS stored access policies, filesystem ACLs, immutability policies, network rules, and lifecycle policies govern different decisions; name the exact policy type in designs and incident notes.

Layer Azure SQL security and evidence

Choose the database service and deployment model first, then layer tenant/identity, server or instance, database, network, encryption, authorization, auditing, threat protection, vulnerability assessment, and recovery controls.

Prefer Microsoft Entra authentication and, where requirements allow, Entra-only authentication. Give applications managed identities and contained database permissions rather than shared SQL administrator credentials. Azure RBAC manages the Azure resource; SQL roles and permissions manage database access. A Contributor who can configure a logical server is not automatically a database reader, and a database owner does not automatically have Azure subscription control.

Constrain network access with firewall rules or private endpoints, private DNS, and public-network settings. Avoid broad “allow Azure services” exceptions without understanding their scope. Test administrative, application, failover, backup, monitoring, and incident paths before closing public access.

Use transparent data encryption for at-rest database files and backups; customer-managed TDE protectors add key lifecycle and availability responsibility. Always Encrypted protects selected columns from the database engine under supported client patterns. Dynamic data masking reduces casual display but is not an authorization boundary, and row-level security filters rows based on execution context. Choose based on the threat actor and required query behavior.

Azure SQL auditing records selected database events to configured destinations such as Storage, Log Analytics, or Event Hubs. Decide server- versus database-level policy, action groups, identity and destination access, retention, tamper resistance, alerting, query procedure, and failure monitoring. Auditing is evidence, not prevention. Defender for Databases is a family of workload plans across Azure database services; plan selection, vulnerability assessment, alert coverage, and onboarding differ by engine. Use the multicloud support matrix for the appropriate database plan and cloud. The older database introduction URL now describes open-source relational databases; it is not a universal Azure SQL support reference.

Related item: “Encrypted” is incomplete unless you state at rest, in transit, in use/client-side, or backup; Microsoft-managed or customer-managed key; identity that may unwrap it; and recovery if the key is unavailable.

Build segmentation and private access deliberately

NSGs are stateful layer-3/4 filters applied to subnet or network interface. Default rules remain after custom rules, lower priority numbers win, and return traffic for an allowed connection is statefully permitted. Application security groups group NICs for rule expression; they do not inspect application identity or content. Evaluate effective rules on the actual NIC and subnet because both layers, service tags, ASGs, priority, and platform behavior combine. Network Watcher NSG diagnostics can evaluate an intended flow and identify the applied rule.

Azure Virtual Network Manager security admin rules apply centrally across network groups and can establish organization-wide allow, always-allow, or deny behavior before NSGs. Use them for high-level guardrails, but understand precedence and blast radius. Connectivity configurations and security admin configurations solve different problems. Stage network-group membership and deployment by region, retain effective-configuration evidence, and test exception paths.

Virtual WAN centralizes branch, VPN, ExpressRoute, and VNet connectivity. A secured virtual hub integrates routing and Azure Firewall; intent/routing policies determine which traffic is inspected. The existence of a firewall in a hub does not prove symmetric routing through it. Validate route tables, propagation/association, next hop, SNAT, DNS, forced tunneling, and cross-region behavior.

For VPN, choose point-to-site versus site-to-site, route-based design, gateway SKU, active-active and zone requirements, BGP, authentication, certificate lifecycle, IKE/IPsec policy, and on-premises compatibility. Avoid weakening cryptography merely to make two devices connect. Monitor tunnels, learned routes, throughput, rekey behavior, and failover.

Microsoft Entra Private Access is an identity-centric Security Service Edge capability for access to supported private applications. It is not simply a VNet private endpoint and not a universal replacement for site-to-site networking. Model connector placement and health, application segments, user/group assignment, Conditional Access, DNS and port requirements, client deployment, and fail-open/fail-closed expectations. VERIFY CURRENT: licensing, protocols, connector behavior, and client capability are fast moving; use the Private Access documentation.

Private endpoints place consumer-side NICs with private IPs in a VNet to reach a supported PaaS resource through Private Link. A Private Link service publishes a provider-owned service behind a Standard Load Balancer for private consumption. In both cases, design DNS and approval lifecycle, disable or restrict unintended public access, and validate each subresource and region. The Private Link overview distinguishes service providers and consumers.

Azure Firewall is a stateful managed firewall. Network rules handle layer-3/4 traffic; application rules use supported FQDN/HTTP semantics; DNAT publishes inbound targets; threat intelligence and IDPS add detection or prevention depending on tier/configuration; TLS inspection introduces certificate and trust dependencies. Use Firewall Policy and policy hierarchy for governance, separate rule-collection groups by ownership, log decisions, and test name resolution and asymmetric routing. A WAF protects HTTP application behavior; an NSG segments flows; DDoS Protection addresses volumetric attacks; none replaces the others.

Related item: Troubleshoot in packet order: name resolution, route, source NAT, destination endpoint, NSG/security-admin rule, firewall/gateway, service firewall, identity, and application authorization. “The network is open” does not prove the identity or data plane will allow access.

3. Secure compute

Secure AI as a connected system

An AI workload is not just a model endpoint. Threat-model its identities, prompts, grounding data, memory, model and deployment, orchestration, tools, connectors, agent actions, output consumers, management plane, software supply chain, and telemetry. Controls at one layer do not silently protect another.

Use this model:

Layer	Questions and controls
Data and knowledge	Is SharePoint or another source overshared? Are labels, permissions, DLP, retention, and grounding scopes correct?
Identity	Which user, app, managed identity, or agent identity acts? Is consent and resource authorization least privilege?
Input/output safety	Which content filters, prompt-injection defenses, blocklists, output validation, and human approvals apply?
Tools/actions	Which API, connector, MCP tool, or computer-use action is allowlisted? What is the transaction limit and approval boundary?
Runtime/perimeter	Are endpoints private or governed through AI Gateway? Are quotas, authentication, routing, WAF/API policy, and isolation enforced?
Posture/detection	Are assets discovered, recommendations triaged, prompts protected where supported, and incidents correlated in Defender XDR?
Lifecycle	Are evaluation, red teaming, version promotion, rollback, ownership, inventory, and decommissioning repeatable?

SharePoint oversharing can make otherwise authorized content available to too broad a user population, which then expands what Microsoft 365 Copilot or an agent can ground on. Start with site/content permissions and sensitivity, external sharing, “everyone except external users” patterns, inactive sites, and high-value data. Microsoft Purview Data Security Posture Management for AI helps discover AI use, data risks, interactions, and policy opportunities; it does not replace the underlying permission cleanup or information-protection program. VERIFY CURRENT: DSPM for AI experiences, licensing, supported apps, and portal names evolve rapidly.

Real-time protection for Copilot Studio agents uses current Microsoft Defender capabilities to inspect supported agent activity, surface inventory and alerts, and support hunting. Coordinate Power Platform and security administration, configure the agent/app identifiers and protection settings, then test benign traffic and controlled policy violations. Do not assume every custom channel, tool, or external model is covered. The current official protection module is a useful implementation baseline.

Microsoft Entra Agent ID gives agents distinct directory identities and lifecycle. Apply Conditional Access only to supported agent scenarios and verify that the policy targets the intended agent identities, resources, and authentication flow. Inventory owner, host, purpose, credentials/federation, permissions, tools, data, user delegation, activity, and deletion state. Defender XDR blast-radius views can connect a risky agent identity to resources, permissions, users, and observed activity, but a graph is only as complete as onboarded telemetry. VERIFY CURRENT: Agent ID object models, supported Conditional Access conditions, portal workflow, and Defender correlation remain fast moving; consult agent identities.

For Conditional Access on agents, identify the token subject before choosing the target. Delegated/OBO access targets the user; application-only access targets the agent identity; an agent’s user account is another subject. A blueprint-targeted policy covers derived agent identities, not their agent user accounts. Current documentation says “all users” policies do not include agent user accounts, and API-key calls bypass the Entra token/Conditional Access pipeline. A token for one API is not a general pass to another audience.

Azure API Management AI Gateway applies gateway controls to model, agent, and tool traffic: authentication, routing, quotas/rate limits, token policies, content-safety policies, caching where safe, observability, and back-end credential isolation. Foundry integration and AI Gateway tiers have different availability and preview boundaries. A gateway does not replace back-end RBAC, model safety, data authorization, or secure tool design. Microsoft's current AI Gateway capabilities explicitly labels tier-dependent and preview features. VERIFY CURRENT: tier, region, policy, model-provider, MCP/A2A, and Foundry integration support before designing around it.

Defender for AI Services provides current runtime threat protection for supported Azure AI traffic and integrates alerts with Defender XDR. Confirm supported models, token modalities, cloud/region, pricing, required roles, and whether prompt evidence may be processed or shown to analysts. The AI threat-protection overview currently covers supported Azure OpenAI/Model Inference models and text tokens only; image and audio tokens are not scanned. It lists commercial Azure support, excluding Azure Government, 21Vianet, and connected AWS accounts. The 30-day trial is capped at 75 billion scanned tokens and can become billable before day 30 if that cap is reached. Recheck these boundaries before enabling a lab. Defender CSPM/AI posture identifies risky configuration and attack paths; threat protection detects activity. Both differ from Foundry guardrails.

Foundry guardrails evaluate prompts and responses through safety controls such as content filters and blocklists. Select thresholds using a risk assessment, evaluate allowed and disallowed cases, test multilingual/encoded/indirect prompt injection, measure false positives and false negatives, version the configuration, and keep application-side authorization and output validation. Guardrails cannot prove factuality, prevent an overprivileged tool from acting, or repair overshared grounding data. The current Defender/Foundry protection learning path covers posture, runtime protection, and guardrails together.

The Defender for Cloud Data and AI security dashboard combines discovery, protection coverage, recommendations, alerts, attack paths, sensitive-data context, and internet exposure for supported resources. Its completeness depends on enabled plans, extensions, providers, permissions, clouds, and scan coverage. Record the asset and subscription denominator before reporting a percentage. Review the dashboard documentation.

AI security posture documentation distinguishes cloud-resource discovery from agent-level coverage. Since July 1, 2026, discovery/posture for Foundry agents and third-party cloud agents requires Agent 365 licensing; Defender CSPM continues to discover Foundry accounts and projects. Do not report agent protection from the CSPM plan switch alone.

Microsoft 365 admin center agent management provides inventory and administrative controls for supported agents in the tenant. Correlate an agent record with its owner, publisher, users, licenses, knowledge, actions/connectors, Entra identity, environments, data policies, and Defender/Purview signals. VERIFY CURRENT: inventory coverage and controls are changing; validate what custom, shared, Copilot Studio, Foundry, and partner agents appear before claiming completeness.

Related item: Responsible AI and security overlap but are not identical. Quality evaluation, fairness, transparency, and human oversight do not replace identity, authorization, network controls, secrets management, abuse monitoring, incident response, or recovery.

Harden servers and virtual machines across clouds

Choose encryption based on threat and platform support. Server-side encryption protects managed-disk data at rest by default; customer-managed keys add Disk Encryption Set and Key Vault dependencies; encryption at host protects temporary disks and cache plus data flows to storage; confidential-disk encryption protects supported confidential VMs; Azure Disk Encryption (ADE) uses BitLocker or dm-crypt inside the guest. Microsoft has announced ADE retirement for September 15, 2028. Do not start a new long-lived design without evaluating supported alternatives and migration. VERIFY CURRENT: use the ADE retirement guidance and per-VM support matrix.

Azure Bastion provides RDP/SSH connectivity through the Azure portal or supported clients without public IPs on target VMs. It reduces direct exposure but still requires identity, RBAC, NSG, host hardening, session governance, and logging. Just-in-time VM access uses Defender for Servers to create time-limited inbound access based on policy; it should narrow source, port, protocol, and duration. Bastion and JIT solve related but different paths and can coexist.

Azure Arc projects non-Azure servers into Azure Resource Manager for inventory, policy, Machine Configuration, Defender, and management extensions. The Connected Machine agent and its identity become security-sensitive. Constrain onboarding credentials, allowed extensions, network endpoints, proxy, local agent permissions, and resource scope. Removing an Arc resource does not necessarily remediate the underlying server.

Defender for Servers plans combine features such as Defender for Endpoint integration, vulnerability assessment, file integrity monitoring, agentless scanning, and other protections depending on plan and current configuration. Plan 1 and Plan 2 are not interchangeable. Agentless scanning complements agent-based EDR and configuration collection; it is periodic and has cloud, disk, encryption, and support limitations. Agentless machine scanning uses disk snapshots and is available through Defender CSPM or Defender for Servers Plan 2. It does not establish continuous EDR health. Confirm plan/feature, cloud, disk, and encryption coverage separately. Microsoft Defender Vulnerability Management produces software and vulnerability findings; prioritize using exposure, exploitability, asset criticality, active threat, and compensating control—not CVSS alone. VERIFY CURRENT: plan packaging, agent provisioning, unified-agent behavior, scan coverage, and included quotas change; check Defender for Servers planning.

Trusted Launch security type enables supported secure boot and vTPM protections and supports boot integrity monitoring. Secure boot validates signed boot components; vTPM provides measured-boot and key-protection capabilities; integrity monitoring surfaces health signals. Confirm image, size, generation, disk, extension, and migration support before changing an existing VM. Azure Machine Configuration audits or applies guest-OS configuration through Azure Policy and extensions; it does not replace patching, EDR, local least privilege, or secure images.

Related item: Management-plane compliance and runtime security are complementary. A policy may prove that an extension is assigned, while EDR proves the sensor is healthy and observes activity. Build evidence for both desired configuration and operating effectiveness.

Secure containers, serverless, web apps, and APIs

For containers, protect registry, build, manifest, admission, identity, network, secrets, node, runtime, and telemetry. Defender for Containers combines posture and runtime capabilities across supported Kubernetes environments; onboarding method and feature support vary by Azure, Arc, AWS, and GCP. Validate sensor health and coverage rather than assuming the plan toggle protects every cluster.

For AKS:

• Use supported Entra integration, Azure RBAC or Kubernetes RBAC deliberately, and separate cluster administration from workload authorization.
• Prefer workload identity federation over pod-held secrets. Restrict the service account, federated subject, audience, and Azure role.
• Use private clusters or API server authorized IPs as required, network policies, controlled egress, and private endpoints for dependencies.
• Enforce pod security, approved registries/images, non-root execution, read-only filesystem where possible, resource limits, secret-store integration, and admission policy.
• Patch supported Kubernetes/node versions, use managed identities, separate system/user node pools, protect node metadata, and monitor audit/runtime signals.

Azure Container Registry should use Entra/RBAC, managed identities, private access, disabled admin user, scoped tokens only for justified external cases, image scanning, quarantine/signing or provenance controls where supported, retention, and controlled imports. A clean image scan is point-in-time evidence, not proof of secure source or runtime behavior.

Azure Container Instances is direct container compute with a smaller orchestration surface; Container Apps adds managed environments, revisions, ingress, scaling, service bindings, and workload profiles. In both, constrain image source, managed identity, secrets, network/ingress, egress, resource limits, logs, and revisions. Do not transplant AKS controls blindly—the authorization and networking models differ.

For Functions, distinguish function/host keys from user authentication and Azure management authorization. Use App Service authentication where appropriate, managed identity to dependencies, private endpoints and VNet integration correctly, access restrictions, TLS, Key Vault references, minimal CORS, deployment slots, and diagnostic settings. A function key is a shared secret, not user identity.

Logic Apps Consumption and Standard have different hosting, networking, identity, and storage dependencies. Secure trigger/callback URLs, connectors and connection resources, managed identities, integration accounts, run history, parameters, access control, and private access where supported. Prevent secrets or sensitive payloads from being exposed in run history; use secure inputs/outputs with awareness of operational tradeoffs.

For App Service, combine built-in authentication/authorization, managed identity, private endpoints for inbound private access, VNet integration for outbound access, access restrictions, TLS/certificates, Key Vault references, deployment slots, backups, diagnostics, and platform/runtime patch policy. VNet integration does not make inbound traffic private; private endpoint does not control outbound routing.

Azure Web Application Firewall on Application Gateway or Front Door protects supported HTTP/S traffic with managed and custom rules. Select prevention versus detection, rule-set version, exclusions, bot/rate controls where supported, TLS termination, origin restriction, logging, and tuning. Exclude the smallest request element rather than disabling a whole rule. WAF does not protect direct access to an exposed origin.

API Management policies can validate JWTs, restrict IPs, check headers, transform requests, rate-limit, cache, call services, and apply AI gateway controls. But a policy that validates the client token does not automatically authorize APIM to the back end. Use managed identity, mTLS, OAuth, or another justified backend method; remove embedded backend secrets; restrict direct backend access; protect the developer/admin plane; version and test policy fragments; and log without leaking tokens or payloads.

Related item: Inbound private access and outbound dependency access are separate flows. Draw client-to-service and service-to-dependency paths independently, with DNS, route, firewall, identity, and authorization for each hop.

4. Manage and monitor security posture

Turn Defender for Cloud findings into controlled remediation

Foundational CSPM provides core posture features such as recommendations and secure score; paid Defender CSPM adds advanced capabilities such as attack-path analysis, Cloud Security Explorer, governance, and data/AI posture features. Cloud workload protection plans detect and protect specific workload types. Turning on Defender CSPM does not turn on every workload plan, and a workload plan does not repair poor configuration.

Use a risk workflow:

1. Confirm asset inventory and coverage across subscription, management group, AWS, GCP, Arc, and DevOps sources.
2. Validate the recommendation or attack path and its prerequisites.
3. Add business criticality, sensitive-data context, exposure, exploitability, active alerts, and compensating controls.
4. Assign an owner and due date; remediate in a test scope; prove the control and workload still function.
5. Use a narrow, expiring exemption only when risk is accepted or a compensating control exists.
6. Preserve before/after evidence and watch for regression.

Secure score is a normalized posture signal, not a breach probability and not a target to maximize blindly. Fix high-impact, exposed paths before cheap low-risk points. Regulatory compliance maps assessed resources to standards; verify scope, shared responsibility, evidence, and assessor expectations. The Defender CSPM overview explains the current free and paid capability split.

Enable workload plans intentionally at management-group/subscription scope, understand component settings and billing, pilot exclusions, and monitor coverage. For AWS and GCP, model connector identity, least-privilege permissions, account/project discovery, region and service support, agentless and Arc-based components, data residency, and removal. A connector state of “healthy” does not prove every asset or feature is covered.

Microsoft Defender External Attack Surface Management discovers internet-visible assets from an outside-in perspective. It helps find unknown domains, hosts, certificates, services, and vulnerabilities; it does not prove ownership automatically. Seed discovery carefully, validate candidates, tag ownership, remove false positives, monitor change, and route confirmed exposure into remediation. The current EASM overview reflects its integration into Defender for Cloud.

Related item: Posture management asks “What could be attacked because of current state?” Workload protection asks “What suspicious activity is happening?” SIEM/XDR asks “How do signals correlate into an incident?” Maintain all three rather than treating one dashboard as the security program.

Engineer Microsoft Sentinel ingestion before analytics

Plan tenant, region, workspace, data ownership, retention, residency, daily volume, cost tier, access boundary, and incident integration before connecting sources. Use least-privilege Sentinel roles and resource-context access where appropriate. Content hub solutions package connectors, parsers, workbooks, analytics, hunting, and playbooks; install and version them deliberately, record dependencies, and review updates rather than assuming marketplace content is automatically trusted.

Use Azure resource diagnostic settings or policy-driven deployment for Azure logs. A diagnostic setting controls categories and destinations; it does not guarantee that the source emits meaningful events or that the destination parser is correct. Validate a known action from source through table, timestamp, transform, analytics rule, incident, and retention.

For Windows, Azure Monitor Agent (AMA) plus data collection rules (DCRs) selects and routes events. Windows Event Forwarding can consolidate events to a collector, which AMA then ingests. For Linux/network appliances, use supported AMA Syslog/CEF patterns and hardened forwarders. Size facilities/severities, queue/disk, TLS, redundancy, parsing, time synchronization, and failure alerts. Legacy Log Analytics/MMA agent examples are historical context, not a new design.

Custom logs require an ingestion path, DCR and transformation, custom table schema, normalized fields, timestamps, retention, access, and parser. Test malformed, missing, duplicate, delayed, and high-volume events. A table receiving rows does not prove useful detection.

Automation rules can triage, tag, assign, change status, and run playbooks. Playbooks are Logic Apps with identities, connectors, permissions, trigger authorization, network dependencies, run history, and cost. Use least privilege, idempotency, approval for destructive actions, retry/dead-letter behavior, secrets protection, and rollback. Monitor both rule execution and playbook failure.

Retention now spans Log Analytics and evolving Microsoft Sentinel data-store options. Decide interactive versus lower-cost/long-term data based on investigation latency, regulatory need, query capability, restore/search workflow, and deletion requirements. VERIFY CURRENT: Sentinel portal and data-lake experiences are changing. Microsoft has announced that Azure portal support ends after March 31, 2027; plan for the Defender portal using the Sentinel platform transition documentation.

Query Microsoft Purview Audit from the Defender XDR experience with the correct permissions, licensing, retention, workload coverage, and time normalization. Preserve query parameters and exports for an investigation. Absence of an event can mean the action did not occur, the workload did not emit it, the event aged out, the query was wrong, or access hid it—prove which.

Related item: Collection is a product decision and a detection dependency. Record why each event source exists, which use cases depend on it, expected daily volume, parser/schema owner, health signal, retention class, and removal test.

Worked ingestion path: direct Windows events versus WEF

For a disposable Windows source, install the appropriate Content Hub solution and open its connector. Confirm workspace and deployment permissions, select or create a DCR, associate the intended Azure VM or Arc-enabled machine, choose the event set or a tested XPath filter, and select the destination workspace. With Windows Security Events via AMA, trace a harmless known sign-in event into SecurityEvent and inspect its computer, event ID and timestamps. A DCR existing without the intended machine association does not prove collection.

For Windows Event Forwarding, first prove WEC is receiving the subscribed events locally, then configure AMA/DCR on the collector and verify WindowsEvent ingestion. Do not expect an unchanged analytics rule querying SecurityEvent to match records held only in WindowsEvent. Adapt its query or use an appropriate parser, then test a known source event through the detection. Common, Minimal, All and Custom sets differ; Minimal is not a full audit trail, and All here is not every Windows log. Preserve source event identity and compare source/ingested counts before evaluating detection coverage. Answer check: a healthy collector with no incident can be a table/query mismatch rather than event loss. VERIFY CURRENT: connector/portal support, table schemas and permissions. No collector or analytics rule was deployed in this review.

Operate Microsoft Security Copilot with the same rigor as other privileged tooling

Security Copilot can use organizational security data and plugins to help analysts investigate, summarize, script, and act. Configure workspace ownership, capacity, data location, retention/diagnostic expectations, sharing, and permitted workflows. Separate Security Copilot roles from permissions in the connected Microsoft products: a user cannot legitimately retrieve source data that their underlying product role does not allow merely because they can prompt Copilot.

The Security Copilot authorization documentation separates Copilot Owner/Contributor access from source-service permissions. Microsoft plugins use on-behalf-of access; a Contributor may still need Sentinel Reader on the intended workspace. New instances use recommended security roles for default access. Some existing instances retain Everyone; removing it is currently irreversible as an assignment choice. Review inherited access and role-assignable groups rather than assuming the platform role grants all security data. Custom plugin and agent credentials need their own review.

Plugins connect Copilot to Microsoft or third-party data and capabilities. For each plugin, document publisher, connection identity, permissions, data sent/returned, geography, logs, supported prompts, action capability, owner, approval, and revocation. Disable unused plugins. Treat pasted secrets, untrusted threat intelligence, incident content, retrieved documents, and tool output as potentially adversarial input.

Microsoft agents and Security Store agents may automate or specialize security tasks. Before enablement, validate publisher and version, data sources, permissions, triggers, action boundary, human approval, failure mode, cost/capacity, telemetry, rollback, and outcome measurement. Begin read-only in a bounded scope. An agent-generated conclusion is a lead that requires evidence, not an incident fact.

VERIFY CURRENT: Security Copilot workspace, capacity, licensing, role, plugin, agent, and Security Store behavior evolves frequently. Recheck the Security Copilot documentation and tenant-specific availability before relying on a UI path or entitlement.

Related item: Promptbooks and agent instructions are operational code. Version them, review data assumptions, test adversarial and ambiguous input, measure accuracy and cost, restrict action scope, and retain a human-owned recovery path.

Current release and onboarding boundaries

The Defender for Cloud release notes distinguish these changes from the unchanged exam objectives:

Date	Change	Learning and operations consequence
July 31, 2026	Legacy grouped recommendations removed; individual recommendations replace them	Check queries, reporting, and exemptions instead of expecting old grouped records.
August 6, 2026	AWS/GCP overprovisioned-identity assessments no longer include unused-action lists	Obtain permission-use evidence from the cloud provider; do not infer a permission is unused because a field disappeared.
August 21, 2026	Detailed CVE properties move to microsoft.security/cvedetails in Azure Resource Graph	Review query joins/schema before concluding vulnerability details are absent.
October 28, 2026 source recheck	The current release-note body no longer includes the earlier October 27 Foundational CSPM opt-in announcement	Unconfirmed — validation needed: recheck actual onboarding and current Microsoft guidance. An omitted announcement does not prove either rollout or cancellation.
October 20, 2026, public preview	Cloud security plan management in the Defender portal for Azure commercial environments	The notice describes Defender-owned configuration, Azure view-only configuration and DWU-based billing for migrated subscriptions; verify the actual migration state before changing plans.
October 5, 2026, GA notice	KSPM recommendations move from running-container scope to workload-controller scope	Reconcile changed recommendation populations and Secure Score impact before interpreting a count change as remediation.
November 1, 2026, announced	Defender for Servers billing classification and identification change	VERIFY CURRENT: distinguish Plan 1 desktop-device treatment from Plan 1/2 server-count identification; billing classification alone does not establish supported OS or licensing eligibility.
December 14, 2026, announced	The grouped vulnerability-assessment-solution recommendation is scheduled for removal	Use individual coverage recommendations and verify automation before the date.
August 16, 2027, announced	Classic Defender for SQL VA/ATP APIs retire	Inventory dependent scripts and plan migration; this does not mean SQL threat protection ends.

Sentinel data-lake onboarding also changes the operating boundary. The lake uses Microsoft-managed encryption keys; CMK workspaces are not accessible through lake experiences. Connected workspaces in the primary workspace’s region are onboarded together, with regional data-movement implications. Auxiliary tables move out of Advanced Hunting access into lake exploration. Individual workspace offboarding or disabling the lake requires a support request. Review permissions, billing, residency, and query paths before onboarding; it is more than a storage-retention toggle. The separate Sentinel Azure-portal transition remains after March 31, 2027.

Integrated scenarios

Scenario 1: Regulated customer-service agent

A financial-services team wants a Copilot Studio agent grounded on selected SharePoint sites and an Azure SQL customer database. It calls an internal API through APIM and uses Foundry models. Staff may view only their assigned customers; refunds require human approval; security needs prompt-attack alerts and auditable evidence.

Build the answer in layers:

1. Reduce SharePoint oversharing and label/restrict the approved knowledge corpus. Use DSPM for AI findings as discovery and prioritization, not as a substitute for permissions.
2. Give each workload component an appropriate managed or agent identity. Scope database and API authorization to the required operation; govern OAuth consent; use PIM for administration.
3. Use private endpoints/VNet integration and correct DNS for SQL, storage, Key Vault, and model dependencies where supported. Keep the APIM back end inaccessible except through the intended path.
4. Put model/tool traffic through the appropriate APIM AI Gateway pattern. Validate tokens, rate-limit, restrict tools, use managed identity to back ends, and prevent direct bypass.
5. Configure Foundry guardrails and application output validation. Put the refund tool behind a transaction limit, human approval, idempotency key, and compensating reversal.
6. Enable supported Copilot Studio real-time protection, Defender for AI Services, CSPM, and Data and AI dashboard coverage. Connect alerts to Defender XDR/Sentinel and test a safe prompt-injection simulation.
7. Preserve user, agent, API, database, approval, and security evidence with retention and role separation. Test revocation, false-positive handling, outage, and rollback.

The mistake is choosing one “AI security” product. The secure solution combines data permissions, identity, network, runtime, action, posture, detection, response, and recovery.

Scenario 2: Ransomware-resistant hybrid platform

An organization operates Azure VMs, Arc-enabled servers, Storage, SQL Managed Instance, site-to-site VPN, and Virtual WAN. Administrators have broad standing access, backups have never been restored, and the SOC receives incomplete Windows events.

1. Inventory effective Entra/Azure privilege, service principals, local/server privilege, backup roles, and attack paths. Move human roles to PIM and remove unused grants incrementally.
2. Harden Conditional Access and authentication with emergency exclusions and tested recovery. Use managed identities and Key Vault for automation.
3. Apply Trusted Launch where supported, Defender for Servers/Endpoint, vulnerability management, agentless scanning, JIT/Bastion, Machine Configuration, patching, and Arc agent governance.
4. Segment workload tiers with NSGs/ASGs and centrally governed security admin rules. Route intended traffic through secured hubs/firewalls and validate effective routes/rules and VPN failover.
5. Protect Backup with least privilege, soft delete, immutability and multi-user authorization where appropriate. Run isolated restore exercises and capture recovery time and integrity evidence.
6. Deploy AMA/DCR and WEF or direct collection according to scale. Validate known Windows events end-to-end, then build analytics and guarded playbooks.
7. Measure coverage gaps and operational health, not merely enabled-plan counts. Exercise credential compromise, host isolation, backup deletion attempt, and clean restoration.

The strongest preventive design still needs trustworthy detection and recovery. A backup icon and green posture score do not prove resilience.

Scenario 3: Internet-facing multitenant API and container platform

An AKS application uses ACR, Storage, Key Vault, Functions, and a public API. A partner needs private access to one back-end service. The company also has an AWS account and unknown internet-facing assets.

1. Federate CI/CD identity and constrain the deployment role. Scan IaC and images, require review for identity/network changes, and preserve provenance.
2. Use AKS workload identity, Entra/RBAC, admission/pod controls, network policy, private dependency access, restricted egress, supported Defender for Containers coverage, and runtime telemetry.
3. Disable ACR admin access, use private connectivity and managed identity, scan/import from approved sources, and manage retention/provenance.
4. Put WAF and APIM in the intended HTTP path; restrict the origin/back end; validate client tokens; use managed identity or mTLS to the API; tune without broad exclusions.
5. Publish the partner service through Private Link service if that matches the provider/consumer requirement. Design approval, DNS, source/NAT visibility, monitoring, and revocation.
6. Connect AWS to Defender for Cloud with least-privilege connector permissions and confirm asset/feature coverage. Use EASM to discover candidate external assets and validate ownership.
7. Centralize diagnostic and security events, build detection for registry, cluster, WAF/APIM, Key Vault, and storage behavior, and automate only reversible/approved response.

The common failure is a secure front door with a reachable origin, overprivileged workload identity, or unrestricted tool/dependency path behind it.

Worked examples

These original fixtures and calculations were checked locally. They are design aids, not observed tenant behavior or service performance promises.

1. Map the caller before assigning a policy

Request	Token subject	What to check
An assistant reads a signed-in employee’s document through OBO	Employee, with the calling agent identified	User policy, delegated permission, target audience, and the employee’s source access
A scheduled agent calls a reporting API as itself	Agent identity	Agent-targeted policy and application permission at the API
A digital worker uses its linked agent user account	Agent user account	Explicit supported agent-user targeting; neither a blueprint target nor an all-users policy proves coverage
A tool uses a static API key	Outside the Entra token flow for that call	Key lifecycle and service authorization; Entra Conditional Access cannot assess that key exchange

An access token for API A is not valid merely because the same agent also needs API B. Model the downstream token exchange and audience, then test an intentionally wrong audience. Do not ask an autonomous application to satisfy a human MFA interaction as if it were a signed-in user.

2. Compute effective access without double counting

An identity can reach resources 1–18 through grant A and resources 11–24 through grant B. The overlap is eight resources, so the union is 18 + 14 − 8 = 24. Its job needs only resources 1–6. The review has 18 unnecessary reachable resources to investigate, not 26 or 32. This simplified set ignores operation-level and deny conditions; the real review must inspect actions, data actions, inheritance, conditions, and source authorization. Removing a secret from a repository does not revoke it or change these grants.

3. State the AI protection denominator

An application receives 1,000 requests: 800 are text-only calls to supported models, 120 are image-only, and 80 are audio-only. Assume every other support prerequisite holds. Only the 800 text requests are eligible for the cited text-token scanning capability. If onboarding actually covers 750 of those, coverage is 93.75% of eligible requests and 75% of all requests. Both denominators matter. A successful plan deployment is not evidence that unscanned modalities or unsupported providers are protected.

4. Separate scanning from live endpoint protection

An estate contains 120 servers. Recent supported disk scans cover 80; healthy EDR covers 70; 65 appear in both sets. Coverage by at least one method is 80 + 70 − 65 = 85, leaving 35 servers with neither signal. Only 65/120 = 54.17% have both. A “plan enabled” count of 120 hides these operational gaps. Record the scan timestamp, supported disks, sensor state, and reason for every exclusion.

5. Prove event completeness and detection time

A source emits 1,000 events with unique stable IDs. The destination has 980 rows, but 40 are duplicates, leaving 940 unique events and 60 not yet accounted for. Later, 50 distinct delayed events arrive: completeness reaches 990/1,000 = 99%, with ten still missing. Do not use row count alone as delivery evidence.

For a hypothetical detection, collection takes 4 minutes, the next rule evaluation waits 5 minutes, evaluation takes 2 minutes, and incident publication takes 1 minute. End-to-end delay is 12 minutes. A five-minute rule schedule is not a five-minute detection promise. Test event time, ingestion time, the lookback window, parsing, and duplicate handling together.

6. Check recovery against the whole deadline

A synthetic restore copies 300 GB at a sustained 150 MB/s, using decimal units: 300,000 / 150 = 2,000 seconds, or 33m20s. Provisioning takes another 10 minutes and integrity/application checks take 12 minutes. Total recovery is 55m20s, missing a 45-minute objective by 10m20s. This model excludes additional contention and delays, so it is not a throughput guarantee. Test the protected recovery path and workload usability; a successful copy is not a completed recovery.

7. Gateway success is not backend authorization

Of 200 test requests, the gateway rejects 20 invalid client requests. It forwards 180; the backend denies ten because the gateway’s identity lacks a required permission. The remaining 170 succeed: 85% of all requests, or 94.44% of forwarded requests. The expected client rejections are useful security evidence, while the unexpected backend denials require investigation. Track both identities and test direct-backend access separately; accepting a client JWT never grants the gateway backend access.

Hands-on labs

Perform labs only in authorized disposable environments. Estimate and cap costs before enabling paid plans or provisioning network/AI resources. If licensing prevents execution, tabletop the same artifacts and clearly label simulated evidence.

Lab 1: Privileged access and overprivilege review

Create a role-assignment inventory at management-group through resource scope. Include direct/group assignment, PIM eligible/active state, service principals, managed identities, custom roles, last activity, owner, and business need. Design PIM settings for two privileged tasks and stage a Conditional Access policy in report-only mode with emergency access exclusions. Remove or narrow one safe test grant. Evidence: before/after effective access, activation/audit event, denied negative test, rollback procedure, and review date.

Lab 2: Application identity and Key Vault boundary

Deploy a test vault with RBAC, purge protection, logging, restricted public access or private endpoint, and private DNS. Give a managed identity only secret-read access to one vault. Test success, unauthorized object operation, wrong identity, public-path denial, rotation to a new secret version, consumer rollover, and recovery. Review app registration permissions and consent separately. Evidence: architecture, role scope, DNS result, allowed/denied calls, logs, rotation timeline, and teardown.

Lab 3: Policy, Defender, backup, and IaC

Author or select a policy that audits a meaningful control, then test noncompliant and compliant resources. Add a remediation-capable effect only if safe and record its managed-identity role. Deploy through Bicep or Terraform with federated CI identity and template scanning. Map one Defender standard/recommendation and one expiring exemption. Design and, where possible, test Backup soft delete/immutability/MUA and a restore. Evidence: code review, policy state, remediation result, secure score context, exemption, backup denial and restore proof.

Lab 4: Storage and SQL data plane

Deploy test Storage and Azure SQL resources with Entra-based workload access, minimal data roles/permissions, restricted network access, encryption decisions, auditing, and applicable Defender plans. Test an authorized read/write, unauthorized identity, blocked network path, expired or constrained SAS if used, SQL audit event, retention, and recovery. Evidence: authorization matrix, firewall/private DNS, logs, Defender coverage/cost, and data restore result.

Lab 5: Network path and effective controls

Draw and implement a small client-to-service path using NSGs/ASGs, routes, Azure Firewall or a tabletop equivalent, and a private endpoint. Add a central security admin rule design, VPN/Virtual WAN branch decision, and Entra Private Access comparison. Test DNS, route, effective security rule, allowed connection, blocked connection, firewall log, public bypass, failover, and rollback. Evidence: packet-path table and each decision point.

Lab 6: AI and agent security control chain

With synthetic content, model a Copilot Studio or Foundry agent that reads approved knowledge and calls one harmless tool. Inventory data permission and agent identity; configure the available guardrail, gateway, Conditional Access, Defender for AI/Copilot protection, and monitoring controls—or tabletop unavailable licensed components. Test ordinary use, overshared-content denial, prompt injection, prohibited output, unauthorized tool, excessive calls, revoked identity, and alert triage. Evidence must identify which layer detected or blocked each case and every coverage gap.

Lab 7: Hybrid VM protection and recovery

Use one Azure VM and an Arc tabletop or test server. Assess encryption choice, Trusted Launch, Bastion/JIT, Defender for Servers plan, EDR, vulnerability findings, agentless coverage, Machine Configuration, patching, and backup. Validate sensor/extension health, a safe vulnerability/remediation cycle, JIT expiry, denied direct management path, configuration drift, alert route, and isolated restore. Record feature/plan/licensing dependencies.

Lab 8: Application platform, Sentinel, and Copilot operations

Model or deploy an AKS/container or App Service/Functions/API path. Secure identity, registry/image, ingress/WAF, APIM back end, private dependencies, secrets, and diagnostics. In Sentinel, document workspace roles, install one Content Hub solution, ingest a known event through AMA/DCR or an Azure connector, create/verify a custom table if relevant, and run a guarded automation rule/playbook. Configure a read-only Security Copilot/plugin/agent scenario if licensed. Evidence: source-to-incident lineage, schema/retention, automation approval/rollback, and Copilot source citations.

Lab 9: Scope, coverage, and recovery fixtures

Reproduce examples 1–7 on paper or in a local spreadsheet/script. Keep separate identity, eligible-request, server, event, and request populations. Expected evidence: the four caller/policy cases, 24 reachable resources, 750 protected requests, 85 servers with at least one signal, 990 unique delivered events, a 12-minute detection path, and a 55m20s restore. Explain why each result has a different denominator and what a live test would still need to prove.

Lab 10: Current-control migration review

Create a change register for Key Vault RBAC defaults and trusted-service bypass, Agent 365 agent coverage, Sentinel onboarding/portal migration, the Defender recommendation/CVE changes, and ADE retirement. For each, record affected assets, source/date, owner, prerequisite, negative test, rollback/support path, and next review. Tabletop an exposed application credential: rotate/revoke it, preserve sanitized investigation evidence, assess grants and recovery controls, then validate application recovery. Do not reproduce destructive incident operations. Expected evidence: no claim that an edited disclosure, a green dashboard, or a future release date proves a control works.

Original knowledge checks

These 48 original questions include answers for self-review; they are not recalled exam items.

#	Question	Answer and reasoning
1	Why does PIM reduce standing privilege without proving that the eligible role is least privileged?	Eligibility removes permanent activation, but the role’s actions and scope may still exceed the task.
2	What recovery controls must exist before enforcing a tenant-wide Conditional Access policy?	Tested emergency access, intentional exclusions, report-only results, staged rollout, and a recovery procedure.
3	When should an application use delegated permission rather than application permission?	When a signed-in user’s context and rights are required; application permissions suit justified unattended operations.
4	How do an app registration, service principal, and enterprise application relate?	Registration defines the app; a service principal represents it in a tenant; enterprise application is its administrative view.
5	Why can a user-assigned managed identity create a larger blast radius than a system-assigned identity?	It can be assigned to several workloads and survives any single host, so review reuse and grants. It can still be an appropriate managed-identity choice.
6	What is the security difference between Key Vault control-plane permission and data-plane permission?	Management permissions configure the resource; data permissions authorize object operations. Legacy access-policy administration can enable self-granting.
7	What must be tested after creating a Key Vault private endpoint?	Private DNS/routing and the actual caller, public restrictions, trusted-service exceptions, authorization, and allowed/denied operations.
8	How do Defender CSPM secret scanning and Defender for Key Vault solve different problems?	Secret scanning identifies exposed secrets; Key Vault threat protection detects suspicious activity. Neither substitutes for revocation/rotation.
9	Why can a deny policy leave existing resources noncompliant?	Deny evaluates applicable create/update requests; it does not automatically repair previously deployed resources.
10	Which dependencies make deployIfNotExists or modify remediation succeed?	A valid effect/definition, assignment scope/parameters, appropriate managed-identity permissions, and remediation for existing resources.
11	Why is a resource lock not an authorization or data-protection control?	Locks protect supported management operations; they do not replace RBAC or prevent authorized data-plane changes.
12	What evidence proves a backup is recoverable and protected from a compromised administrator?	An isolated restore with integrity/application checks, measured recovery time, and tested deletion controls with separated authority.
13	Why is Entra data-plane authorization normally safer than Shared Key for Storage?	It supports scoped identity-based grants and avoids distributing broad account keys; actual authorization and service support still matter.
14	How do a user-delegation SAS and an account SAS differ in issuer and potential scope?	A user-delegation SAS uses an Entra-derived delegation key; an account SAS uses an account key and can span services. Neither uses a stored access policy.
15	Why does a private endpoint not by itself prove that public Storage access is disabled?	Creation of a private path does not disable the public one; inspect endpoint settings, DNS, firewall, and exceptions.
16	Contrast TDE, Always Encrypted, dynamic data masking, and row-level security by threat addressed.	TDE protects stored files; Always Encrypted protects selected client-encrypted columns; masking changes display; row-level security restricts rows.
17	Which design choices make Azure SQL auditing useful and tamper-resistant evidence?	Correct events, destination access, retention, timestamps, tamper resistance, failure monitoring, and a known-action retrieval test.
18	Why should Defender for Databases be treated as a family of plans rather than one uniform switch?	Engines, hosting models, clouds, onboarding, and vulnerability/threat capabilities differ; verify the applicable plan.
19	How do NSGs, security admin rules, Azure Firewall, and WAF differ in layer and precedence?	NSGs filter network flows; security admin rules apply central precedence; Firewall inspects/routes supported traffic; WAF handles HTTP application threats.
20	When is Private Link service appropriate instead of a private endpoint?	When publishing a provider-owned service for private consumption; consumers connect using private endpoints.
21	Why is Microsoft Entra Private Access not simply another Azure private endpoint?	It provides identity-aware access to private applications through its own connectors/client/control plane.
22	Which route and DNS evidence proves traffic actually traverses a secured Virtual WAN hub?	Effective routes, next hop, symmetric return path, DNS, firewall decisions, and a known allowed/denied test from the actual source.
23	Why can SharePoint oversharing become an AI security issue even when Copilot authorization works as designed?	Correct authorization can still honor permissions that are too broad. Fix source access and sharing.
24	Which controls remain necessary after Foundry guardrails block unsafe prompt content?	Data permissions, identity, tool authorization, transaction limits, network controls, telemetry, output handling, and recovery.
25	What does AI Gateway centralize, and what back-end controls does it not replace?	It centralizes supported model/tool traffic controls; backend permissions, direct-path restrictions, and application authorization remain necessary.
26	How do Defender AI posture, Defender for AI Services, and the Data and AI dashboard differ?	Posture assesses configuration, runtime protection detects supported activity, and the dashboard summarizes enabled/discovered coverage.
27	Which identity, permission, data, tool, and monitoring records belong in an agent inventory?	Owner/purpose, host/identity, user versus app mode, permissions, knowledge, tools, credentials, logs, licenses, and lifecycle state.
28	Why should Azure Disk Encryption retirement affect a new VM encryption decision today?	Migration includes supported alternatives and recoverable backups before September 15, 2028; existing ADE disks may fail to unlock after reboots at retirement.
29	How do Bastion and JIT VM access reduce different exposure paths?	Bastion provides a management connection path without target public IPs; JIT opens specified management access for a limited time.
30	Why does agentless VM scanning complement rather than replace EDR?	Snapshot findings are periodic; EDR health and live behavior require a separate operational signal.
31	What must be secured across registry, admission, identity, network, node, and runtime for AKS?	Trusted/scanned images, registry access, admission/pod restrictions, scoped workload identity, segmentation/egress, node maintenance, and runtime telemetry.
32	Why does App Service VNet integration not make inbound access private?	It governs outbound connectivity; inbound private access requires its own endpoint and public-access design.
33	What proves that an APIM policy protects the back end rather than only the gateway endpoint?	Correct gateway-to-backend identity/permissions plus blocked bypass, and success/denial evidence at the backend.
34	Why should Defender secure score not be optimized without risk and asset context?	Scores summarize assessed posture; prioritize actual exposure, exploitability, critical assets, coverage, and accepted exceptions.
35	What end-to-end test proves a Sentinel connector is operationally useful?	Generate a known event and trace its stable identity through collection, schema, query, rule, incident, and response, including delay and duplicate cases.
36	Which permissions, data paths, failure controls, and evidence must be reviewed before enabling a Security Copilot plugin or agent?	Platform and source roles, connection identity, sent/returned data, action scope, capacity, approval, failure handling, and revocation evidence.
37	Does a new Key Vault RBAC default migrate old vaults?	No. The API-version default applies to newly created vaults; inspect and migrate existing authorization deliberately.
38	Does publicNetworkAccess Disabled eliminate every Key Vault exception?	No. Check trusted-service bypass and perimeter mode; the explicit schema exception qualifies broad private-only wording.
39	Can an account SAS use a stored access policy?	No. Stored access policies apply to service SAS.
40	Which policy subject applies to delegated agent access?	The user; separately test the agent’s application identity when it uses app-only access.
41	Does an all-users policy prove agent user-account coverage?	No. Current agent documentation excludes agent user accounts from that target and requires supported explicit targeting.
42	Does Conditional Access evaluate an API-key-only request?	No. That request bypasses the Entra token issuance path.
43	Does Defender CSPM alone establish Foundry agent-level posture licensing?	No. Current agent-level discovery/posture requires Agent 365; account/project discovery is a different scope.
44	Are image/audio tokens scanned by the cited AI threat plan?	No. Its documented scanning support is text tokens on supported models/services.
45	Is Sentinel data-lake onboarding a reversible per-workspace toggle?	No. Same-region connected workspaces are onboarded together; offboarding requires support. Review CMK and query-access limits first.
46	Does Security Copilot Contributor grant Sentinel data access?	No. Source-service permissions such as the appropriate Sentinel workspace role are separately required.
47	Does the omitted October 27 Foundational CSPM announcement prove a current opt-in change?	No. The current release-note body no longer confirms that announcement; recheck Microsoft guidance and actual onboarding. Omission proves neither rollout nor cancellation.
48	Does deleting an exposed secret from an issue finish incident response?	No. Revoke/rotate it, assess historical use and effective permissions, and verify dependent applications and recovery controls.

Final readiness checklist

• I checked the official SC-500 page for a blueprint change, new language, Practice Assessment, or retirement notice.
• I can distinguish current SC-500 content from retired AZ-500-only content and name the AI/agent additions.
• I can map every published objective to a control boundary, configuration decision, test, and evidence artifact.
• I can distinguish Entra role, Azure RBAC, service data-plane permission, SQL permission, Kubernetes RBAC, and application authorization.
• I can design PIM, Conditional Access, strong authentication, workload identity, consent, and emergency recovery together.
• I can secure Key Vault identity, network, object lifecycle, monitoring, CSPM findings, and threat alerts.
• I can explain policy effects/remediation, standards/compliance, locks, custom roles, overprivilege, Backup, and IaC controls.
• I can secure Storage and Azure SQL across identity, network, encryption, logging, Defender, retention, and recovery.
• I can trace a flow through DNS, route, NSG/admin rule, firewall/WAF/APIM, private endpoint, identity, and data authorization.
• I can secure an AI workload across data, agent identity, prompts/outputs, tools, gateway, Foundry, Defender, and operations.
• I can choose current VM encryption, Bastion/JIT, Arc, Defender for Servers, vulnerability/EDR/agentless coverage, Trusted Launch, and Machine Configuration.
• I can secure AKS/ACR/ACI/Container Apps, Functions/Logic Apps/App Service, WAF, and APIM without confusing their boundaries.
• I can turn Defender posture findings into prioritized, owned, tested remediation across Azure, AWS, and GCP.
• I can prove Sentinel ingestion from source through table, detection, incident, automation, retention, and Purview Audit.
• I can configure Security Copilot workspaces, roles, plugins, and agents with least privilege, data governance, human oversight, and rollback.
• I completed or tabletop-tested all ten labs and can explain both successful and failed tests.

Places to learn

This is a curated starting point, not a complete list. Do not try to consume every item. Pick the format and depth that work for you, use the official blueprint as the coverage checklist, and spend at least as much effort on implementation and negative testing as on passive watching. Provider runtimes and catalogs change; estimates below use public listings checked September 28, 2026 and include notes where exact current duration was unavailable.

Focused reading and evidence route

Read enable protection and review protection outputs: published estimates total 12 minutes. Then allow about 45–60 minutes for a handoff/evidence worksheet assigning the Defender URL, Power Platform configuration and matching App ID to their owners. Distinguish the proxy app from an agent’s own identity, and predict evidence for a mismatched ID, missing connector, no suspicious activity and a fresh session. Keep inventory, alert flow and hunting results as separate checks; a connected indicator or logged event alone is insufficient proof of prevention. The added range covers four failure cases, not tenant setup. VERIFY CURRENT: product prerequisites, UI, query schema and detection behavior; training examples are not guaranteed thresholds. Both unit texts were read; no tenant change or query ran.

The twelve current official paths are secure Entra access, Key Vault security, security governance and compliance, Storage security, Azure SQL security, network security controls, AI security, server and VM security, application-platform security, Defender for Cloud posture, Sentinel activity and event collection, and Security Copilot deployment and operation. The fetched overviews expose 63 module placements (3/4/6/4/3/4/9/7/6/6/8/3). Module titles/descriptions were reviewed, not every linked unit. Current runtimes are absent, so the earlier 30h08 sum is withdrawn.

Resource	Access	Estimated time
Official SC-500 study guide and credential page	Public	1–2 hours initially; 15 minutes on each recheck
Twelve official Microsoft Learn paths linked from the SC-500 course syllabus: Entra access, Key Vault, governance, Storage, SQL, networking, AI, servers/VMs, app platforms, Defender posture, Sentinel collection, and Security Copilot	Public	63 module placements; current runtime not published in fetched pages; budget exercises separately
SC-500T00 instructor-led course	Paid/partner delivery	4 days; ten course languages listed
Microsoft exam sandbox from the credential page	Public	20–40 minutes; repeat once before exam day
Microsoft Practice Assessment	Not yet available	VERIFY CURRENT; when published, allow 45–75 minutes per attempt plus source review
Tim Warner SC-500 course companion	Public (MIT)	Planning estimate: 10–20 hours selectively; root/README lists 15 lessons in active development. Individual scripts were not audited
Tim Warner’s Pearson/Microsoft Press SC-500 video course described by the companion repo	Paid; product availability varies	About 10 hours claimed by the companion; a current publisher catalog listing was not established in this review
Udemy SC-500 + AZ-500 course by Alan Rodrigues	Paid	Public indexed listing: 36h35, 11 sections/460 lectures, September 2026 update; direct fetch blocked, paid coverage unverified
Udemy SC-500/AZ-500 hands-on course by John Christopher	Paid	Public indexed listing: 18h31, 17 sections/151 lectures, August 2026; direct fetch blocked, verify current AI/Agent coverage
Udemy SC-500 practice tests by Scott Duffy and Jordi Koenderink	Paid	Planning estimate: 3–6 hours; public indexed listing shows four tests of 25 questions, August 2026. Direct fetch blocked; questions not accessed
Pluralsight AZ-500 path	Paid/trial	Public listing: six course entries 46h27 (including 12h31 practice entry) plus five labs 3h30 = 49h57; rounded header 50h. Retired AZ-500 foundation only
O’Reilly/Pearson AZ-500 video by Tim Warner	Paid	Previously listed 8h34/January 2022; direct fetch blocked and current metadata unverified. Legacy foundation only
John Savill AZ-500 Study Cram	Public	Previously listed 2h54; current fetch is a shell and video was not watched. Older Azure-security foundation only
Microsoft Reactor channel	Public	2–8 hours selectively for current Azure security, Defender, Sentinel, and AI sessions; no exact SC-500 path confirmed
Partner Skilling Hub	Partner-restricted	Varies by scheduled offering; partner sign-in is required to confirm an SC-500 listing, dates, and exact session duration

Articles to turn into practice

• Storm-3168 and compromised service principals — Microsoft Security Research, Yossi Weizman, and Tushar Mudi, September 25, 2026. Use the mitigation section for Lab 10’s credential revocation, least-privilege, and recovery-control review. The article does not establish the initial credential-compromise route; do not turn a possible cause into a proven one. No destructive operations are needed for the exercise.
• Reimagining the SOC for the agentic era — Rob Lefferts, September 23, 2026. Useful context for connecting telemetry, investigation, and controlled response. Its ISOC announcement is preview; it does not establish tenant availability, entitlement, or a new exam domain. Use example 5 to test whether your evidence reaches an actionable outcome.

Treat blogs as context and discovery. Use the current product references to decide which control is supported, what it protects, and how to verify it.