SC-500 — Microsoft Certified: Cloud and AI Security Engineer Associate Exam Blueprint

How to Use This Exam Blueprint

Use this checklist as a practical study map for the Microsoft Certified: Cloud and AI Security Engineer Associate (SC-500) exam from Microsoft. It is designed to help you decide what to review, what skills to practice, and what “ready” looks like before exam day.

This page does not assign official weights or claim to reproduce the Microsoft exam outline. Instead, it organizes the major readiness areas a cloud and AI security engineer should be able to reason through: identity, access, posture management, workload protection, data security, AI security, monitoring, incident response, and governance.

For each area, ask:

• Can I choose the right Microsoft security control for a scenario?
• Can I explain why a tempting alternative is weaker?
• Can I secure both traditional Azure workloads and AI-enabled solutions?
• Can I troubleshoot misconfigurations without over-permissioning?
• Can I connect prevention, detection, and response controls into one design?

SC-500 readiness map

Core SC-500 mental model

Security scenarios on SC-500 are rarely about a single feature in isolation. They usually test whether you can connect the control to the risk.

Identity and access checklist

Identity is the control plane for most Microsoft cloud security scenarios. Be ready to distinguish between human access, workload access, application access, and data-plane access.

Can you do this?

• Explain the difference between Microsoft Entra roles, Azure RBAC roles, and application permissions.
• Choose the correct RBAC scope: management group, subscription, resource group, or resource.
• Identify when a user needs a built-in role versus a custom role.
• Reduce excessive permissions without breaking the required task.
• Use groups for role assignment instead of assigning many individual users directly.
• Recognize when Privileged Identity Management-style controls are appropriate for elevated access.
• Choose managed identity for Azure-hosted workloads that need to call Azure services.
• Choose workload identity federation for external automation when avoiding long-lived secrets is the goal.
• Know when a client secret or certificate is a fallback, not the preferred design.
• Distinguish authentication failure, authorization failure, network denial, and policy denial during troubleshooting.

Identity decision path

    flowchart TD
	    A[Caller needs access to a cloud or AI resource] --> B{Is the caller human?}
	    B -->|Yes| C[Use Microsoft Entra identity, group assignment, least-privilege role, and conditional controls]
	    B -->|No| D{Is the workload running in Azure?}
	    D -->|Yes| E[Use managed identity with scoped Azure RBAC or data-plane permissions]
	    D -->|No| F{Is it a CI/CD or external workload?}
	    F -->|Yes| G[Prefer workload identity federation and scoped permissions]
	    F -->|No| H[Use service principal with strong secret/certificate handling and rotation]
	    C --> I[Monitor access and review privilege]
	    E --> I
	    G --> I
	    H --> I

Common identity traps

Cloud security posture and governance

SC-500 candidates should be able to move from “a finding exists” to “this is the right remediation path.”

Governance prompts

For each scenario, ask:

• What is the asset being protected?
• Is the risk caused by identity, configuration, data exposure, network exposure, or missing monitoring?
• Should the control prevent, detect, audit, or remediate?
• Where should the control be applied so it covers future resources?
• What exception process prevents permanent policy bypass?

Network, workload, and application security

Be ready to secure workloads without assuming every answer is “block public access.” Some services need controlled public access, while others should be private-only.

Workload protection checklist

• Identify management-plane versus runtime risk.
• Secure inbound and outbound network paths.
• Require encrypted transport where applicable.
• Use managed identities for service-to-service calls.
• Apply vulnerability management to VMs, containers, dependencies, and images.
• Centralize logs from workloads and platform resources.
• Understand when Defender for Cloud recommendations relate to workload hardening.
• Know how container registry, image scanning, admission controls, and runtime monitoring fit together.
• Avoid solving every workload problem with a network rule when identity or data permissions are the real issue.

Data protection, secrets, and key management

Data security scenarios often combine identity, encryption, storage configuration, and monitoring.

Data security “can you do this?” checklist

• Decide when to use Key Vault for a secret versus managed identity to avoid a secret.
• Explain why a SAS token can be risky if it is long-lived or over-scoped.
• Identify where logs may leak sensitive data, including AI prompts and responses.
• Apply least privilege to data-plane operations, not just resource management.
• Separate key administration from data access when the scenario requires separation of duties.
• Recognize the difference between encryption, masking, classification, and access control.
• Protect backup, export, and replication paths, not only the primary service.

AI security readiness

For SC-500, AI security is not just “use an AI service securely.” You should be able to reason about data flow, identity, model access, grounding data, prompt handling, tools, output, and monitoring.

AI workload threat model

AI security controls checklist

• Secure Azure AI service access with Microsoft Entra identity and scoped permissions where applicable.
• Use managed identity for apps that call Azure AI services from Azure workloads.
• Restrict AI service network access when the architecture requires private connectivity.
• Protect API keys when key-based access is unavoidable.
• Treat prompts and responses as potentially sensitive data.
• Add content safety controls for harmful or policy-violating output.
• Defend against prompt injection with layered controls, not only stronger prompt wording.
• Limit tool/function permissions so the AI app cannot perform actions beyond the user’s authorization.
• Apply authorization checks before retrieval from grounding data sources.
• Monitor unusual AI usage patterns, errors, denials, and possible abuse.
• Prevent sensitive data from being copied into training, evaluation, logs, or analytics without controls.
• Document trust boundaries between users, app services, model endpoints, tools, and data stores.

AI scenario decision checks

AI traps

DevSecOps and deployment security

A cloud and AI security engineer should understand how insecure code and pipeline choices become runtime risk.

Pipeline security checklist

• Avoid long-lived deployment credentials when federation is available.
• Scope pipeline permissions to the target environment.
• Store secrets in approved secret stores, not repository files.
• Scan IaC for public exposure, missing encryption, missing diagnostics, and overly broad roles.
• Require review for changes to model configuration, retrieval sources, safety filters, and tool permissions.
• Ensure deployment logs do not expose secrets, prompts, keys, or sensitive outputs.
• Monitor changes to RBAC assignments, policy exemptions, network rules, and AI endpoints.

Monitoring, detection, and incident response

SC-500 readiness includes knowing which telemetry supports investigation and response. You do not need to memorize every KQL function, but you should recognize useful queries and detection logic.

KQL readiness examples

Be able to interpret and adapt simple queries like these.

SigninLogs
| where ResultType != 0
| summarize FailedSignIns = count() by UserPrincipalName, AppDisplayName, bin(TimeGenerated, 1h)
| order by FailedSignIns desc

AzureActivity
| where OperationNameValue has "roleAssignments"
| project TimeGenerated, Caller, OperationNameValue, ActivityStatusValue, ResourceGroup, ResourceProviderValue
| order by TimeGenerated desc

SecurityAlert
| summarize AlertCount = count() by ProviderName, AlertSeverity
| order by AlertCount desc

Command and artifact checks

You should be comfortable recognizing the purpose of common administrative checks, even if the exam does not ask you to type exact commands.

az role assignment list --assignee <principal-id> --scope <scope>
az monitor diagnostic-settings list --resource <resource-id>
az keyvault secret list --vault-name <vault-name>

Know what each command helps answer:

Scenario and decision-point practice

Use these prompts to test readiness across multiple topic areas.

Common weak areas to fix before exam day

Final-week checklist

Practical next step

Pick three weak rows from this checklist and turn each into a scenario: the asset, the risk, the Microsoft control, the reason it fits, and the reason two alternatives are weaker. Then test yourself with original SC-500 practice questions that force service selection, troubleshooting, and security design decisions.