SC-500 — Microsoft Certified: Cloud and AI Security Engineer Associate Cheat Sheet
Last revised: September 16, 2026
Compact SC-500 Cheat sheet for Microsoft cloud and AI security controls, identity, data, DevSecOps, monitoring, and incident response decisions.
This independent Cheat Sheet supports preparation for the Microsoft Certified: Cloud and AI Security Engineer Associate (SC-500) exam. Use it to review Microsoft security service selection, cloud architecture controls, AI workload risks, identity patterns, monitoring, and response workflows.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Core Exam Mental Model
SC-500 questions commonly test whether you can choose the right Microsoft control for a security goal across cloud, AI, data, identity, and DevSecOps scenarios.
“Prevent everyone, including Owners, from changing a protected resource”
Azure Policy deny, locks, or deny assignments may be relevant
“Temporary admin elevation”
PIM, not a permanent Owner assignment
Conditional Access quick rules
Conditional Access is often the right answer when a scenario includes who, where, device state, risk, application, or session control.
Requirement
Likely Conditional Access component
Require MFA for risky sign-ins
Sign-in risk or user risk condition
Block access from unknown locations
Named locations / location condition
Require compliant or hybrid joined device
Device condition / grant control
Limit session persistence
Session controls
Apply policy only to a cloud app
Cloud app assignment
Test before enforcement
Report-only mode
Exclude emergency accounts
Exclusions, with careful governance
Trap: Conditional Access grants access only after authentication signals are evaluated. It does not replace Azure RBAC, app permissions, network controls, or data permissions.
No stored secret; lifecycle tied to Azure identity
Workload outside Azure needs Microsoft Entra token
Workload identity federation, certificate-based auth, or service principal
Avoid client secrets when possible
Multiple resources need same identity and permissions
User-assigned managed identity
Reusable and independently managed
One resource needs its own lifecycle identity
System-assigned managed identity
Deleted when the resource is deleted
Candidate mistake: Seeing “service-to-service access” and immediately choosing a client secret. In modern Azure designs, managed identity or federation is usually safer.
Logging, prompt/response telemetry where appropriate, incident correlation
Azure OpenAI and Azure AI workload hardening
Requirement
High-yield design choice
Secure access to model deployments
Microsoft Entra authentication where supported; avoid unmanaged keys
Restrict network exposure
Private endpoints, firewalls, approved VNets
Protect application secrets
Managed identity + Key Vault
Prevent broad data retrieval in RAG
Enforce source ACLs and index-level filtering
Reduce prompt attack impact
Limit tools/actions, validate outputs, separate system/developer/user instructions
Detect abuse
Enable diagnostic logging and centralize monitoring
Separate dev/test/prod
Separate resources, identities, deployments, and data stores
Control administrative access
Azure RBAC, PIM, access reviews
Prompt injection and RAG traps
Risk
What candidates should recognize
Direct prompt injection
Malicious user prompt tries to override instructions
Indirect prompt injection
Malicious text hidden in retrieved documents, web pages, emails, or data sources
Oversharing through RAG
AI retrieves documents the user should not access
Tool misuse
Model is allowed to call plugins/functions/actions with excessive permissions
Data exfiltration
Prompt asks model to reveal secrets, system prompts, hidden context, or retrieved content
Unsafe automation
AI-generated action executes without validation or approval
Decision rule: AI security is not only “turn on content filtering.” You also need identity, least privilege, network isolation, data governance, logging, and safe tool design.
Secure AI application workflow
flowchart TD
A[AI workload requirement] --> B{Uses enterprise data?}
B -- No --> C[Secure model endpoint, identity, network, logging]
B -- Yes --> D[Classify data and confirm access boundaries]
D --> E[Enforce source permissions and retrieval filters]
E --> F{Can model call tools or actions?}
F -- No --> G[Apply prompt/output controls and monitor]
F -- Yes --> H[Limit tool permissions and require validation]
H --> G
G --> I[Centralize logs and test with adversarial prompts]
Data Protection and Microsoft Purview
Requirement
Use
Exam note
Discover and classify sensitive data
Microsoft Purview data classification/catalog capabilities
Helps identify where sensitive data exists
Apply labels to documents and emails
Sensitivity labels
Labels can drive encryption and usage restrictions
Prevent sharing or leakage
Data loss prevention policies
Focuses on sensitive content leaving approved channels
Govern data lifecycle
Retention labels/policies where applicable
Retention and deletion are governance controls
Investigate risky data activity
Audit and compliance investigation tools
Match tool to workload and data source
Protect secrets
Azure Key Vault, Managed HSM
Do not store secrets in source code, prompts, app settings, or pipeline logs
Protect storage data access
RBAC, ACLs, SAS governance, firewall/private endpoint
Avoid broad shared keys or overly permissive SAS
Protect database access
Microsoft Entra authentication, RBAC/roles, firewall/private endpoint, auditing
Prefer centralized identity over embedded credentials
Notes and examples
Key Vault and managed HSM
Requirement
Likely choice
Store secrets, keys, and certificates for applications
Azure Key Vault
Use FIPS-validated dedicated HSM-backed key storage
Azure Managed HSM may be relevant
Let an app retrieve a secret securely
Managed identity + Key Vault access
Avoid public network access to vault
Private Endpoint and firewall settings
Audit secret access
Diagnostic settings to Log Analytics / Sentinel
Rotate secrets and certificates
Key Vault lifecycle and automation
Trap: Storing a secret in Key Vault is not enough. The application identity still needs least-privilege access, network restrictions may be required, and logs should be monitored.
Storage security quick review
Need
Control
Avoid shared account keys
Microsoft Entra authorization and RBAC where supported
Time-limited delegated access
SAS, preferably user delegation SAS when appropriate
Protect against deletion or tampering
Soft delete, versioning, immutable storage, legal hold where applicable
Restrict network access
Firewall, private endpoint, selected networks
Detect suspicious access
Defender for Storage and logging
Encrypt at rest
Microsoft-managed keys by default; CMK when required by design
Candidate mistake: Choosing a broad account SAS when the scenario requires least privilege, short duration, and user delegation.
Data classification and governance
Microsoft Purview-related concepts may appear in scenarios involving data discovery, classification, sensitivity, retention, DLP, and audit.
Scenario
Think
Identify sensitive data across repositories
Data discovery/classification
Apply labels to protect documents and emails
Sensitivity labels
Prevent sharing of sensitive content
DLP policies
Investigate data activity
Audit and compliance tooling
Govern data used by AI/RAG solutions
Classification, access controls, lineage, and least privilege
Key Vault and Secret Management
Scenario
Best answer pattern
App needs to read a secret
Assign managed identity access to Key Vault secret with least privilege
Diagnostic settings to Log Analytics, storage, or event hub
Notes and examples
Defender for Cloud Concepts
Concept
Meaning
Secure score
Prioritized posture indicator based on recommendations
Recommendations
Hardening actions mapped to resource configuration and threat posture
Regulatory compliance view
Compliance-oriented assessment against selected standards
Defender plans
Workload protection capabilities for supported resource types
Security alerts
Threat detections from protected workloads
Attack path analysis
Helps prioritize exploitable combinations of weaknesses
Just-in-time VM access
Reduces exposed management ports where configured
Sentinel Concepts
Concept
Use
Data connector
Ingests logs from Microsoft or third-party source
Log Analytics workspace
Stores queryable log data
Analytics rule
Detects suspicious behavior and creates incidents
Incident
Case container for investigation
Entity
Account, host, IP, URL, file, or other object involved in detection
Workbook
Visualization and reporting
Hunting query
Analyst-driven search for suspicious behavior
Watchlist
Reference data for queries and rules
Automation rule
Automates incident handling logic
Playbook
Logic Apps workflow for response actions
Microsoft Defender for Cloud review
Microsoft Defender for Cloud is a key security posture and workload protection service for Azure and multicloud environments.
Concept
What to remember
Secure score
Prioritization signal, not a guarantee of compliance
Recommendations
Configuration and risk findings mapped to resources
Regulatory compliance view
Helps assess controls against selected standards; does not create legal compliance by itself
Defender plans
Workload-specific protection capabilities
Attack path analysis
Shows exploitable chains of risk across resources
Cloud Security Explorer
Helps query and investigate risk paths and resource exposure
Workload protections
Alerts and detection for supported services and workloads
Integration with Sentinel
Defender alerts can feed SIEM investigation workflows
Common Defender for Cloud traps
A recommendation may require manual remediation, policy assignment, configuration change, or deployment of an agent/extension.
Secure score is useful for prioritization but is not an official certification of compliance.
Defender for Cloud posture management is different from Microsoft Defender XDR incident correlation.
Enabling a Defender plan may add detection capabilities, but you still need correct identity, network, and data controls.
Multicloud visibility depends on connectors, permissions, and supported configurations.
KQL Patterns for Exam Review
Use KQL concepts more than memorized queries. Know filtering, projection, summarization, joins, time windows, and entity correlation.
Sign-in Failure Spike
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize Failures=count() by UserPrincipalName, IPAddress
| order by Failures desc
Notes and examples
Azure Administrative Changes
AzureActivity
| where TimeGenerated > ago(24h)
| where CategoryValue == "Administrative"
| project TimeGenerated, OperationNameValue, ActivityStatusValue, Caller, ResourceGroup, ResourceId
| order by TimeGenerated desc
Key Vault Secret Access Review
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName has "Secret"
| project TimeGenerated, OperationName, identity_claim_appid_g, CallerIPAddress, ResultType
| order by TimeGenerated desc
Suspicious Multiple IP Sign-ins
SigninLogs
| where TimeGenerated > ago(1d)
| summarize IPCount=dcount(IPAddress), IPs=make_set(IPAddress) by UserPrincipalName
| where IPCount > 3
| order by IPCount desc
Common KQL Operators
Operator
Use
where
Filter rows
project
Select columns
extend
Add calculated columns
summarize
Aggregate data
join
Correlate tables
distinct
Return unique values
order by
Sort results
ago()
Relative time filter
bin()
Group time into intervals
make_set()
Build a set of values
DevSecOps and Secure Delivery
Need
Microsoft/GitHub capability
Exam focus
Detect hardcoded secrets
GitHub secret scanning
Prevent credential exposure before deployment
Detect vulnerable dependencies
Dependabot alerts, dependency review
Identify package risk in pull requests and repositories
“Correlate third-party firewall logs with Azure logs”
Microsoft Sentinel
“Investigate identity, endpoint, and email incident together”
Microsoft Defender XDR
“Protect public web application from SQL injection/XSS”
WAF
“Make Azure PaaS service reachable only privately”
Private Endpoint / Private Link
“Find secrets in repositories”
GitHub secret scanning
“Prevent vulnerable package from entering main branch”
Dependency review and required checks
“Prevent AI app from leaking retrieved documents”
Identity-aware RAG, document ACLs, data minimization
“Detect harmful prompts or outputs”
Azure AI Content Safety and app guardrails
“Allow model to call tools safely”
Least-privilege tools, allowlist, validation, human approval for high-risk actions
“Track who accessed secrets”
Key Vault diagnostic logs
“Respond automatically to a Sentinel incident”
Automation rule and playbook
Final Review Checklist
Know when to choose Defender for Cloud, Defender XDR, Sentinel, Purview, Entra ID, Key Vault, Azure Policy, GitHub Advanced Security, and Azure AI security controls.
Separate authentication, authorization, Conditional Access, RBAC, and policy enforcement.
Prefer managed identity or workload identity federation over long-lived secrets.
Apply least privilege to both users and workloads.
Treat AI prompts, retrieved context, embeddings, outputs, and logs as potentially sensitive.
Enforce RAG authorization before retrieval.
Use application-layer controls for AI tool execution; do not rely only on prompt instructions.
Know which logs support identity, resource, data, AI, and incident investigations.
Practice KQL basics: where, summarize, project, join, and time filtering.
For scenario questions, identify the asset, identity, data sensitivity, network exposure, detection need, and response objective before selecting a control.
Notes and examples
Fast final review checklist
Use this checklist before topic drills or a mock exam.
Identity
Can you distinguish Microsoft Entra roles, Azure RBAC, app permissions, and data-plane permissions?
Do you know when to use Conditional Access, PIM, access reviews, and managed identities?
Can you identify risky service principal secrets and replace them with safer patterns?
Azure platform
Can you choose between NSG, Azure Firewall, WAF, Private Endpoint, Bastion, and DDoS Protection?
Can you explain Azure Policy versus Defender for Cloud versus Azure RBAC?
Can you identify the right control for public exposure, insecure configuration, and missing monitoring?
Data and secrets
Can you secure Key Vault access with identity, RBAC/access policy, network restrictions, and logging?
Can you choose between Microsoft-managed keys and customer-managed keys when a scenario requires key control?
Can you reduce risk from shared keys, broad SAS tokens, and exposed secrets?
AI security
Can you secure model endpoints, AI app identities, RAG data sources, prompts, outputs, and logs?
Can you recognize direct and indirect prompt injection?
Can you prevent AI oversharing by enforcing source permissions and retrieval boundaries?
Detection and response
Can you distinguish Defender for Cloud, Defender XDR, Sentinel, Log Analytics, workbooks, and playbooks?
Can you recognize alert versus incident versus connector versus analytics rule?
Can you read simple KQL intent even if syntax is not the main focus?
Cheat Sheet scope for SC-500
This Cheat Sheet is for candidates preparing for Microsoft SC-500, Microsoft Certified: Cloud and AI Security Engineer Associate (SC-500). Use it to refresh high-yield concepts before moving into IT Mastery practice, original practice questions, topic drills, mock exams, and detailed explanations.
SC-500 preparation should focus on practical security engineering decisions across Microsoft cloud and AI environments: identity, access control, network isolation, data protection, posture management, threat detection, DevOps/container security, and secure AI implementation.
This page is IT Mastery exam-prep support and is not affiliated with Microsoft.
High-yield review map
Area
Know how to decide
Common SC-500-style trap
Identity and access
Choose Microsoft Entra ID controls, Conditional Access, PIM, managed identities, workload identity federation, and app consent patterns
Confusing authentication, authorization, directory roles, and Azure RBAC
Trap: Kubernetes has its own RBAC and runtime model. Azure RBAC alone does not automatically solve pod permissions, container image risk, network policy, or secret handling.
Monitoring, detection, and response
Defender XDR, Sentinel, and Log Analytics
Tool
Main role
Microsoft Defender XDR
Correlates incidents across Microsoft Defender workloads
Microsoft Sentinel
Cloud-native SIEM/SOAR for collecting, correlating, hunting, and automating response
Log Analytics
Stores and queries telemetry with KQL
Defender for Cloud
Cloud posture and workload protection alerts
Workbooks
Visualize and analyze security data
Playbooks
Logic Apps-based automated response
Analytics rules
Create incidents from suspicious patterns
Hunting queries
Proactively search for threats
Notes and examples
Incident and alert vocabulary
Term
Meaning
Alert
A detection signal from a product or rule
Incident
Grouped set of related alerts/entities for investigation
Entity
User, host, IP, resource, file, process, or account involved
Connector
Data ingestion source for Sentinel
Playbook
Automated workflow for response or enrichment
Workbook
Dashboard/reporting view
KQL
Query language used for logs and hunting
KQL concepts to recognize
You do not need to memorize every KQL function, but you should understand common operations.
Need
KQL idea
Filter rows
where
Select columns
project
Count or aggregate
summarize
Sort results
order by
Join data sets
join
Parse dynamic JSON-like fields
parse_json, extend
Limit time range
TimeGenerated filter
Detect rare events
summarize, baselines, anomaly-style logic
Trap: A workbook visualizes data. It does not ingest logs by itself. A connector or diagnostic setting usually supplies the data.
Practical decision rules
“Which Microsoft security service should I choose?”
If the scenario asks you to…
Choose or consider…
Enforce configuration standards at deployment
Azure Policy
Identify risky Azure resources and attack paths
Defender for Cloud
Protect endpoints and correlate Defender alerts
Microsoft Defender XDR
Collect logs from many sources and automate response
Microsoft Sentinel
Store and control secrets/keys/certificates
Azure Key Vault or Managed HSM
Manage privileged admin activation
Microsoft Entra PIM
Control user access based on risk/device/location
Conditional Access
Secure AI prompts and outputs
Azure AI safety controls, content filters, prompt shields, validation
Govern sensitive data
Microsoft Purview capabilities
Protect web apps from OWASP-style attacks
WAF
Avoid public access to PaaS services
Private Endpoint / Private Link
Secure pipeline access to Azure
Workload identity federation or managed identity pattern
Notes and examples
“What should be done first?”
When several answers are plausible, look for the first control that removes the largest risk with least operational complexity.
Scenario wording
Strong first move
“Developers store secrets in code”
Move secrets to Key Vault and rotate exposed secrets
“Admins have permanent Owner rights”
Implement PIM and reduce standing privilege
“Storage account is publicly accessible”
Disable public access / restrict network and identity access
“AI app can retrieve all documents”
Enforce data permissions and retrieval filtering
“Alerts are not investigated centrally”
Connect data sources to Sentinel or Defender XDR workflow
“Resources are repeatedly deployed insecurely”
Azure Policy / IaC guardrails
“VMs have public RDP/SSH”
Remove public exposure; use Bastion/JIT/private access
“Pipeline uses long-lived secret”
Replace with federated credential or managed identity where possible
Common candidate mistakes
Confusing Azure RBAC with Microsoft Entra roles
Azure RBAC controls Azure resources. Microsoft Entra roles control tenant/directory administration.
Assuming MFA solves authorization
MFA strengthens authentication. It does not grant least privilege or replace RBAC.
Using shared keys when identity-based access is available
Prefer Microsoft Entra authorization and managed identities when supported.
Treating secure score as compliance
Secure score helps prioritize security improvements; it is not a legal or regulatory guarantee.
Ignoring data-plane permissions
Management-plane access and data-plane access are not always the same.
Forgetting private endpoint DNS
Private connectivity often fails because name resolution still points to the public endpoint.
Overtrusting AI content filters
Filters are important, but AI systems also need data access control, prompt hardening, monitoring, and safe tool boundaries.
Giving AI tools excessive permissions
If an AI agent can call a tool, the tool’s identity and scope matter. Least privilege still applies.
Thinking logging equals prevention
Logs support detection and investigation. Preventive controls still need to be configured.
Skipping remediation ownership
Recommendations, alerts, and policies only help when teams know who must act.