SC-500 — Microsoft Certified: Cloud and AI Security Engineer Associate Cheat Sheet

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.

Security goalPrimary Microsoft capabilities to knowExam decision focus
Secure human accessMicrosoft Entra ID, Conditional Access, MFA, Identity Protection, Privileged Identity ManagementWho can access what, from where, under which risk conditions
Secure workload accessManaged identities, service principals, workload identity federation, Key Vault, RBACAvoid secrets, use least privilege, isolate production identities
Secure Azure resourcesMicrosoft Defender for Cloud, Azure Policy, Azure RBAC, resource locks, network controlsPosture management, hardening, compliance, threat protection
Secure AI appsAzure AI services, Azure OpenAI, Azure AI Content Safety, prompt protection patterns, private networking, loggingPrevent data leakage, prompt injection, unsafe outputs, tool abuse
Secure dataMicrosoft Purview, sensitivity labels, DLP, encryption, Key Vault, storage/database access controlsClassify, protect, monitor, and govern sensitive data
Detect and investigateMicrosoft Defender XDR, Microsoft Sentinel, Log Analytics, KQL, Defender for Cloud alertsCorrelate signals, hunt, triage, automate response
Secure developmentGitHub Advanced Security, Microsoft Defender for DevOps, CI/CD controls, IaC scanningShift-left detection of secrets, vulnerable code, dependencies, misconfigurations

Microsoft Security Service Selection Matrix

NeedChooseNot the same asHigh-yield notes
Central cloud security posture managementMicrosoft Defender for CloudMicrosoft Defender XDRUse for Azure, multicloud, workload recommendations, regulatory/compliance posture, and workload protection plans
Correlated incidents across endpoint, identity, email, SaaS, and cloud appsMicrosoft Defender XDRMicrosoft SentinelDefender XDR is Microsoft’s native extended detection and response portal
SIEM/SOAR across Microsoft and non-Microsoft dataMicrosoft SentinelDefender XDRUse when you need log ingestion, analytics rules, workbooks, automation rules, playbooks, and cross-source hunting
Identity governance and access controlMicrosoft Entra IDAzure RBAC aloneEntra authenticates identities; Azure RBAC authorizes actions on Azure resources
Just-in-time privileged role activationMicrosoft Entra Privileged Identity ManagementPermanent role assignmentUse eligible assignments, approval, MFA, time-bound elevation, access reviews
Detect risky users and sign-insMicrosoft Entra ID ProtectionConditional Access aloneIdentity Protection supplies risk signals; Conditional Access enforces policies
Protect secrets, keys, and certificatesAzure Key Vault / Managed HSMApp configuration or environment variablesPrefer managed identities over client secrets; use Key Vault for secret lifecycle and access control
Enforce resource configurationAzure PolicyAzure RBACRBAC controls who can act; Policy controls what configurations are allowed or audited
Protect web apps from common web attacksAzure Web Application FirewallNSGWAF operates at HTTP/S layer; NSG filters network traffic at subnet/NIC level
Private access to PaaS servicesPrivate Endpoint / Private LinkService endpointPrivate Endpoint gives private IP connectivity to a specific service instance
Classify and govern dataMicrosoft PurviewDefender for CloudPurview focuses on data governance, cataloging, classification, lineage, DLP, and information protection
Scan code and dependenciesGitHub Advanced SecurityRuntime threat protectionUse code scanning, secret scanning, dependency review, Dependabot alerts
Connect DevOps security findings into Microsoft security postureMicrosoft Defender for DevOpsGitHub branch protectionDefender for DevOps provides security visibility and integration across DevOps environments
Protect AI-generated content workflowsAzure AI Content Safety and AI application guardrailsNetwork firewallContent and prompt protections address model input/output risks, not just traffic flow

Identity and Access Cheat Sheet

Entra, Azure RBAC, and App Authorization

ConceptControlsExam distinction
AuthenticationMicrosoft Entra ID, MFA, federated identity, passwordless methodsProves who the principal is
Authorization to Azure resourcesAzure RBAC roles, custom roles, scopesControls actions on management plane or data plane resources
Authorization inside an applicationApp roles, groups, claims, custom authorization logicControls what the user can do inside the app
Delegated API accessOAuth delegated permissionsApp acts on behalf of a signed-in user
Application-only API accessApplication permissions / app rolesApp acts as itself, often requiring admin consent
Workload identityManaged identity, service principal, workload identity federationNon-human identity used by apps, services, pipelines, and automation
Notes and examples

Identity Decision Table

ScenarioPreferWhy
Azure VM, Function, App Service, or AKS workload needs Azure resource accessManaged identityAvoids stored credentials and supports Azure RBAC
GitHub Actions or external CI/CD needs Azure accessWorkload identity federationAvoids long-lived secrets in pipeline variables
Legacy app cannot use managed identityService principal with certificate or secret in Key VaultUse least privilege and rotate credentials
Admin needs occasional privileged accessPIM eligible assignmentReduces standing privilege
Require MFA only for risky sign-insConditional Access using risk signalsMore targeted than requiring MFA for every action
Block access from unmanaged devicesConditional Access device compliance or app protection conditionsTie access to device or app state
Review excessive group or role membershipAccess reviewsSupports periodic governance
Limit third-party app permissionsAdmin consent workflow and app consent policiesControls OAuth consent sprawl

Common Identity Traps

TrapCorrect thinking
“Owner” is needed for all administrationUse least privilege; many tasks require narrower roles
Conditional Access grants permissionsConditional Access controls access conditions; RBAC grants permissions
A service principal secret is as safe as managed identityManaged identity removes credential handling where supported
PIM removes need for monitoringPIM reduces standing access; still audit activations and privileged actions
Group membership always updates instantly in app tokensToken claims may reflect token issuance time; reauthentication may be needed

Authentication, authorization, and privilege

A large share of Microsoft security questions test whether you know which identity layer controls which decision.

NeedPrimary controlKey point
Prove who the user isMicrosoft Entra authentication, MFA, passwordless, federationAuthentication happens before access decisions
Decide whether access is allowedConditional Access, app permissions, Azure RBAC, resource ACLsAuthorization may involve multiple layers
Control Azure resource managementAzure RBACApplies to Azure management plane and some data-plane operations
Control Microsoft Entra tenant administrationMicrosoft Entra rolesDifferent from Azure RBAC roles
Reduce standing privilegeMicrosoft Entra Privileged Identity ManagementPrefer eligible, time-bound, approved, audited elevation
Let an Azure service access another serviceManaged identityAvoid embedded credentials where possible
Let external workload access Azure without secretsWorkload identity federationReduces long-lived service principal secrets
Control app access to APIsApp registrations, enterprise apps, delegated/application permissions, consentApplication permissions can be very powerful

Azure RBAC versus Microsoft Entra roles

If the question says…Think…
“Manage VMs, storage accounts, VNets, resource groups, subscriptions”Azure RBAC
“Manage users, groups, app registrations, Conditional Access, directory settings”Microsoft Entra roles
“Read blobs, queues, or Key Vault secrets”Data-plane role or service-specific access model
“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.

RequirementLikely Conditional Access component
Require MFA for risky sign-insSign-in risk or user risk condition
Block access from unknown locationsNamed locations / location condition
Require compliant or hybrid joined deviceDevice condition / grant control
Limit session persistenceSession controls
Apply policy only to a cloud appCloud app assignment
Test before enforcementReport-only mode
Exclude emergency accountsExclusions, 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.

Managed identity versus service principal

ScenarioPreferWhy
Azure VM, App Service, Function, Logic App, AKS workload needs Azure resource accessManaged identityNo stored secret; lifecycle tied to Azure identity
Workload outside Azure needs Microsoft Entra tokenWorkload identity federation, certificate-based auth, or service principalAvoid client secrets when possible
Multiple resources need same identity and permissionsUser-assigned managed identityReusable and independently managed
One resource needs its own lifecycle identitySystem-assigned managed identityDeleted 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.

Conditional Access and Zero Trust Controls

RequirementUse
Require MFA for privileged rolesConditional Access targeting directory roles
Require compliant or hybrid-joined devicesDevice-based Conditional Access
Restrict sessions in browser/SaaS appsConditional Access session controls
Block legacy authenticationConditional Access policy targeting legacy clients
Require stronger auth for high-risk sign-insIdentity Protection risk-based policy or Conditional Access risk conditions
Limit access by network locationNamed locations in Conditional Access
Protect unmanaged mobile accessApp protection policies and Conditional Access app controls
Reduce permanent administrator exposurePIM with approval, justification, MFA, time limit

Cloud Resource Security Architecture

Azure Control Plane vs Data Plane

LayerExamplesSecurity controls
Management/control planeCreate VM, update storage account, assign roleAzure RBAC, Azure Policy, activity logs, PIM
Data planeRead blob, query database, pull secretData-plane RBAC, ACLs, firewall rules, private endpoints, audit logs
Application planeApp-specific action such as approving a transactionApp authorization, claims, app roles, business logic
Network planeConnect to endpoint, route traffic, filter packetsNSG, Azure Firewall, WAF, Private Link, DDoS Protection
Notes and examples

Resource Governance Matrix

NeedControlNotes
Prevent deployment of noncompliant resourcesAzure Policy with deny effectUse for guardrails such as required tags, allowed locations, required encryption settings
Audit resource configuration driftAzure Policy audit effectUseful before enforcing deny
Remediate missing configurationAzure Policy deployIfNotExists / modify where appropriateOften used for diagnostic settings or required agents/extensions
Control who can modify resourcesAzure RBACAssign at the narrowest practical scope
Temporarily protect critical resources from deletionResource locksLocks do not replace RBAC or backups
Organize governance at scaleManagement groups, subscriptions, resource groupsApply policy and RBAC at appropriate hierarchy
Track administrative changesAzure Activity LogControl-plane activity, not full data-plane access

Network Security Decision Points

ScenarioChooseWhy
Restrict inbound traffic to VM subnetNSGBasic subnet/NIC traffic filtering
Centralize egress inspection and routingAzure FirewallStateful network filtering and centralized policy
Protect public web app from HTTP/S attacksWAFLayer 7 web attack protection
Reduce exposure of PaaS endpoint to public internetPrivate EndpointAccess service over private IP
Restrict PaaS access to selected virtual networksService endpoint or Private EndpointPrivate Endpoint is more isolated and service-instance specific
Protect public endpoints from volumetric attacksAzure DDoS ProtectionNetwork-layer DDoS mitigation
Publish internal app without inbound public exposureApp proxy, private access, or application gateway pattern depending on workloadMatch identity, network, and app requirements
Control DNS resolution for private endpointsPrivate DNS zonesRequired for predictable private endpoint name resolution
Notes and examples

AI Workload Network Controls

AI componentSecurity design choice
Azure OpenAI or Azure AI service endpointPrefer private endpoint where supported for sensitive workloads
App service calling AI serviceUse managed identity where supported and restrict network path
RAG data sourceKeep storage/search/database private; enforce authorization before retrieval
Agent tools/pluginsAllowlist destinations and operations; avoid broad outbound access
Logging pipelineAvoid sending sensitive prompts/responses to unsecured logs

AI Security Cheat Sheet

AI Threats and Controls

ThreatWhat it looks likePractical controls
Prompt injectionUser input attempts to override system instructionsSystem prompt hardening, prompt shields, input validation, tool constraints, output checks
Data exfiltration through promptsUser asks model to reveal hidden context, secrets, or retrieved documentsDo not include secrets in prompts; enforce per-user retrieval authorization; redact sensitive data
Insecure RAG retrievalUser receives documents they are not authorized to accessApply identity-aware retrieval, document-level ACLs, filtered indexes
Tool/plugin abuseModel is tricked into calling dangerous functionsLeast-privilege tools, explicit approval for high-risk actions, allowlists, parameter validation
HallucinationModel returns plausible but false informationGrounding, citations, confidence handling, human review for high-impact decisions
Unsafe contentModel generates harmful or disallowed contentAzure AI Content Safety, output filtering, policy-based handling
Training data poisoningMalicious or low-quality data affects model behaviorData provenance, validation, versioning, controlled ingestion
Model theft or endpoint abuseExcessive calls or attempts to extract behaviorAuthentication, rate controls, monitoring, anomaly detection
Sensitive data retention riskPrompts/responses contain regulated or confidential dataData minimization, retention controls, encryption, access controls, redaction
Supply-chain compromiseVulnerable packages, models, or pipeline artifactsDependency scanning, artifact signing, provenance, secured CI/CD
Notes and examples

Secure AI Application Pattern

LayerSecure-by-design questions
IdentityWhich human and workload identities can call the AI endpoint? Are managed identities used?
NetworkIs the AI service publicly reachable? Are private endpoints and DNS configured correctly?
Prompt orchestrationAre system instructions separated from user input? Are prompts versioned and reviewed?
RetrievalDoes RAG enforce per-user authorization before adding context?
Tools/actionsCan the model trigger writes, purchases, deletion, emails, or external calls? Are approvals required?
Data protectionAre prompts, embeddings, files, and outputs classified and protected?
LoggingAre logs useful for investigation without leaking secrets or sensitive content?
MonitoringAre abuse, anomalous usage, unsafe content, and drift monitored?
Incident responseCan keys be rotated, endpoints disabled, indexes rebuilt, and prompts rolled back?

RAG and Vector Search Security

Design areaHigh-yield control
Document ingestionClassify data before indexing; exclude secrets and unnecessary sensitive fields
EmbeddingsTreat embeddings as sensitive if they can reveal source meaning
Index accessUse RBAC and network isolation; avoid shared indexes that ignore authorization boundaries
Query filteringApply user/group ACL filters before retrieval, not after model generation
Context windowProvide only the minimum relevant context
Source citationReturn citations to support validation and investigation
DeletionEnsure document deletion or permission changes propagate to the index
Tenant separationSeparate indexes, keys, or resource boundaries when isolation requirements justify it

AI Content Safety and Guardrails

NeedControl pattern
Detect harmful user inputInput classification and prompt shield controls
Detect harmful model outputOutput content filtering
Prevent secret leakageSecret scanning, redaction, prompt design, do not inject credentials
Reduce jailbreak successSystem prompt hardening, adversarial testing, restricted tool use
Enforce policy decisionsApplication-layer policy engine, not just model instructions
Support auditabilityLog model version/configuration, prompt template version, tool calls, safety decisions

AI security review

SC-500’s AI security angle is likely to test whether you can secure AI workloads as cloud applications with additional AI-specific risks.

AI security responsibility model

Security concernPractical control
Who can deploy or call AI resourcesEntra ID, Azure RBAC, managed identities, API access controls
What data the AI can retrieveData source ACLs, search index permissions, RAG filters, Purview classification
Whether traffic uses public endpointsPrivate Link, firewall, VNet integration where supported
Secrets used by apps and pipelinesManaged identity, Key Vault, secret scanning
Prompt injection and jailbreak attemptsPrompt shields, content safety controls, system prompt hardening, tool restrictions
Unsafe generated outputContent filtering, output validation, human review for high-risk actions
Data leakage through grounding dataLeast-privilege retrieval, tenant isolation, sensitivity labels, logging
Model/app abuseRate limiting, monitoring, anomaly detection, abuse detection
TraceabilityLogging, prompt/response telemetry where appropriate, incident correlation

Azure OpenAI and Azure AI workload hardening

RequirementHigh-yield design choice
Secure access to model deploymentsMicrosoft Entra authentication where supported; avoid unmanaged keys
Restrict network exposurePrivate endpoints, firewalls, approved VNets
Protect application secretsManaged identity + Key Vault
Prevent broad data retrieval in RAGEnforce source ACLs and index-level filtering
Reduce prompt attack impactLimit tools/actions, validate outputs, separate system/developer/user instructions
Detect abuseEnable diagnostic logging and centralize monitoring
Separate dev/test/prodSeparate resources, identities, deployments, and data stores
Control administrative accessAzure RBAC, PIM, access reviews

Prompt injection and RAG traps

RiskWhat candidates should recognize
Direct prompt injectionMalicious user prompt tries to override instructions
Indirect prompt injectionMalicious text hidden in retrieved documents, web pages, emails, or data sources
Oversharing through RAGAI retrieves documents the user should not access
Tool misuseModel is allowed to call plugins/functions/actions with excessive permissions
Data exfiltrationPrompt asks model to reveal secrets, system prompts, hidden context, or retrieved content
Unsafe automationAI-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

RequirementUseExam note
Discover and classify sensitive dataMicrosoft Purview data classification/catalog capabilitiesHelps identify where sensitive data exists
Apply labels to documents and emailsSensitivity labelsLabels can drive encryption and usage restrictions
Prevent sharing or leakageData loss prevention policiesFocuses on sensitive content leaving approved channels
Govern data lifecycleRetention labels/policies where applicableRetention and deletion are governance controls
Investigate risky data activityAudit and compliance investigation toolsMatch tool to workload and data source
Protect secretsAzure Key Vault, Managed HSMDo not store secrets in source code, prompts, app settings, or pipeline logs
Protect storage data accessRBAC, ACLs, SAS governance, firewall/private endpointAvoid broad shared keys or overly permissive SAS
Protect database accessMicrosoft Entra authentication, RBAC/roles, firewall/private endpoint, auditingPrefer centralized identity over embedded credentials
Notes and examples

Key Vault and managed HSM

RequirementLikely choice
Store secrets, keys, and certificates for applicationsAzure Key Vault
Use FIPS-validated dedicated HSM-backed key storageAzure Managed HSM may be relevant
Let an app retrieve a secret securelyManaged identity + Key Vault access
Avoid public network access to vaultPrivate Endpoint and firewall settings
Audit secret accessDiagnostic settings to Log Analytics / Sentinel
Rotate secrets and certificatesKey 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

NeedControl
Avoid shared account keysMicrosoft Entra authorization and RBAC where supported
Time-limited delegated accessSAS, preferably user delegation SAS when appropriate
Protect against deletion or tamperingSoft delete, versioning, immutable storage, legal hold where applicable
Restrict network accessFirewall, private endpoint, selected networks
Detect suspicious accessDefender for Storage and logging
Encrypt at restMicrosoft-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.

ScenarioThink
Identify sensitive data across repositoriesData discovery/classification
Apply labels to protect documents and emailsSensitivity labels
Prevent sharing of sensitive contentDLP policies
Investigate data activityAudit and compliance tooling
Govern data used by AI/RAG solutionsClassification, access controls, lineage, and least privilege

Key Vault and Secret Management

ScenarioBest answer pattern
App needs to read a secretAssign managed identity access to Key Vault secret with least privilege
Pipeline needs deployment accessPrefer federated identity; avoid static client secrets
Secret exposed in repositoryRevoke/rotate immediately, remove from history as appropriate, enable secret scanning
Need cryptographic key controlUse Key Vault key or Managed HSM depending on control and isolation needs
Need certificate lifecycleStore and manage certificates in Key Vault where appropriate
Need auditabilityEnable diagnostic logging and monitor access patterns

Secret Handling Traps

AvoidPrefer
API keys in source codeManaged identity or Key Vault reference
Secrets in promptsSecure service-side retrieval and redaction
Broad Key Vault access policies/rolesLeast privilege per identity
One shared secret across environmentsSeparate identities and secrets per environment
Logging request bodies with secretsRedaction and safe telemetry design

Microsoft Defender, Sentinel, and Monitoring

Detection Tool Selection

NeedUse
View correlated incidents across Microsoft security productsMicrosoft Defender XDR
Hunt across endpoint, identity, email, cloud app signalsAdvanced hunting in Defender XDR
Protect Azure and hybrid workloadsMicrosoft Defender for Cloud
Central SIEM for Microsoft and third-party logsMicrosoft Sentinel
Automate incident response workflowsSentinel playbooks / automation, Defender response actions
Monitor Azure platform metrics and logsAzure Monitor and Log Analytics
Track control-plane changesAzure Activity Log
Track resource-specific eventsDiagnostic settings to Log Analytics, storage, or event hub
Notes and examples

Defender for Cloud Concepts

ConceptMeaning
Secure scorePrioritized posture indicator based on recommendations
RecommendationsHardening actions mapped to resource configuration and threat posture
Regulatory compliance viewCompliance-oriented assessment against selected standards
Defender plansWorkload protection capabilities for supported resource types
Security alertsThreat detections from protected workloads
Attack path analysisHelps prioritize exploitable combinations of weaknesses
Just-in-time VM accessReduces exposed management ports where configured

Sentinel Concepts

ConceptUse
Data connectorIngests logs from Microsoft or third-party source
Log Analytics workspaceStores queryable log data
Analytics ruleDetects suspicious behavior and creates incidents
IncidentCase container for investigation
EntityAccount, host, IP, URL, file, or other object involved in detection
WorkbookVisualization and reporting
Hunting queryAnalyst-driven search for suspicious behavior
WatchlistReference data for queries and rules
Automation ruleAutomates incident handling logic
PlaybookLogic 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.

ConceptWhat to remember
Secure scorePrioritization signal, not a guarantee of compliance
RecommendationsConfiguration and risk findings mapped to resources
Regulatory compliance viewHelps assess controls against selected standards; does not create legal compliance by itself
Defender plansWorkload-specific protection capabilities
Attack path analysisShows exploitable chains of risk across resources
Cloud Security ExplorerHelps query and investigate risk paths and resource exposure
Workload protectionsAlerts and detection for supported services and workloads
Integration with SentinelDefender 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

OperatorUse
whereFilter rows
projectSelect columns
extendAdd calculated columns
summarizeAggregate data
joinCorrelate tables
distinctReturn unique values
order bySort results
ago()Relative time filter
bin()Group time into intervals
make_set()Build a set of values

DevSecOps and Secure Delivery

NeedMicrosoft/GitHub capabilityExam focus
Detect hardcoded secretsGitHub secret scanningPrevent credential exposure before deployment
Detect vulnerable dependenciesDependabot alerts, dependency reviewIdentify package risk in pull requests and repositories
Detect insecure code patternsCode scanningStatic analysis for vulnerabilities
Protect main branchBranch protection rules, required reviews, required checksEnforce workflow controls
Secure IaC templatesIaC scanning, policy validation, Defender for DevOpsCatch cloud misconfiguration before deployment
Connect repo findings to cloud securityDefender for DevOps integrationImproves security posture visibility
Avoid pipeline secretsWorkload identity federationReplaces long-lived credentials
Separate environmentsDifferent subscriptions/resource groups/identitiesPrevent dev/test compromise from impacting production
Verify artifactsSigned artifacts, controlled registries, approvalsReduce supply-chain risk
Notes and examples

CI/CD Security Checklist

  • Use least-privilege deployment identities.
  • Prefer federated credentials over stored secrets.
  • Scope credentials per environment.
  • Require peer review for production changes.
  • Run code, dependency, secret, and IaC scanning before merge.
  • Protect pipeline variables and logs.
  • Do not print tokens, prompts, connection strings, or API keys.
  • Require approvals for high-risk production deployments.
  • Monitor deployment activity in Azure Activity Log and SIEM.

Incident Response Workflow

PhaseCandidate actions to recognize
PrepareLogging enabled, alert rules, playbooks, roles, runbooks, escalation paths
DetectAlerts from Defender, Sentinel analytics, identity risk, workload alerts
TriageValidate alert, identify entities, determine scope and severity
ContainDisable account, revoke sessions, isolate endpoint, block IP, disable key, restrict network
EradicateRemove persistence, patch vulnerability, rotate secrets, fix misconfiguration
RecoverRestore service, validate controls, monitor recurrence
ImproveUpdate detections, policies, playbooks, training, architecture controls
Notes and examples

Fast Response Decisions

Incident clueImmediate control to consider
User account compromiseRevoke sessions, reset credentials, require MFA, review sign-ins, disable account if needed
Service principal abuseDisable credential, rotate certificate/secret, review app permissions, inspect audit logs
Key Vault secret leakedRotate secret, review access logs, remove exposed copy, enable/verify secret scanning
Public storage exposureDisable public access, review ACLs/SAS, rotate keys if exposed, investigate downloads
AI prompt data leakRemove sensitive context, rotate exposed secrets, review logs, update prompt/RAG controls
Malicious pipeline runDisable pipeline/credential, rotate deployment identity, review recent deployments
VM compromiseIsolate network, collect evidence, rebuild from trusted image, patch root cause

Logging and Diagnostic Settings

Log sourceWhy it matters
Entra sign-in logsAuthentication, Conditional Access, risk, user access investigations
Entra audit logsDirectory changes, role assignments, app consent, policy changes
Azure Activity LogSubscription/resource management operations
Resource diagnostic logsData-plane and service-specific events
Defender XDR incidentsCorrelated security detections
Defender for Cloud alertsWorkload and posture-related security findings
Sentinel incidentsSIEM case management and correlation
Application logsApp-specific events, AI prompt orchestration, authorization decisions
Key Vault logsSecret, key, and certificate access patterns
Storage/database audit logsSensitive data access and exfiltration investigation

High-Yield Architecture Patterns

Secure AI Chat/RAG Application

ComponentRecommended pattern
Front endEntra-authenticated access, HTTPS, WAF if internet-facing
API layerAuthorization checks before prompt construction
Identity to Azure servicesManaged identity
SecretsKey Vault, no secrets in prompts or code
AI endpointPrivate networking where appropriate, RBAC, diagnostic logging
Search/vector indexPrivate access, per-user ACL filtering, minimal indexed sensitive data
StoragePrivate endpoint, encryption, RBAC/ACLs, logging
GuardrailsInput/output filtering, prompt injection detection, tool allowlisting
MonitoringApp telemetry, AI safety events, Defender/Sentinel integration
ResponseAbility to revoke access, rotate keys, disable tools, roll back prompt templates
Notes and examples

Secure Azure Landing Zone Controls

AreaControls
IdentityEntra ID, PIM, Conditional Access, break-glass accounts with monitoring
GovernanceManagement groups, Azure Policy, tagging, resource organization
NetworkHub-spoke, firewall, NSGs, private endpoints, DNS, DDoS/WAF where needed
Security postureDefender for Cloud, secure score, recommendations, regulatory views
LoggingDiagnostic settings, Log Analytics, Sentinel, retention aligned to requirements
DataPurview, encryption, Key Vault, private access, DLP
DevOpsSecure pipelines, IaC scanning, branch protections, federated identity
OperationsIncident response runbooks, backup/recovery, patching, vulnerability management

Common Exam Traps and Correct Distinctions

TrapCorrect distinction
Sentinel and Defender XDR are interchangeableSentinel is SIEM/SOAR; Defender XDR is native XDR correlation and response
RBAC and Azure Policy do the same thingRBAC controls user actions; Policy enforces resource configuration rules
Private endpoint is just a firewall rulePrivate endpoint creates private network access to a service instance
Encryption solves data leakageEncryption helps protect stored/in-transit data; authorization, DLP, logging, and minimization still matter
Prompt instructions can enforce security aloneSecurity decisions must be enforced in application/tooling layers
RAG authorization can be checked after generationAuthorization must restrict retrieval before context reaches the model
A managed identity is a permission grant by itselfManaged identity is an identity; it still needs RBAC or service-specific permissions
Secret scanning fixes exposed secretsIt detects exposure; you must rotate/revoke and investigate
Secure score is proof of complianceIt is a posture indicator, not a complete compliance attestation
Logs are useful by defaultRequired logs must be enabled, routed, retained, and protected

Scenario-to-Control Drill Table

If the question says…Look for…
“Minimize standing privilege”PIM, eligible assignments, just-in-time access
“Access only from compliant devices”Conditional Access device compliance
“Avoid storing credentials in code”Managed identity, workload identity federation, Key Vault
“Block deployment of noncompliant resources”Azure Policy deny
“Audit existing resources before enforcement”Azure Policy audit
“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

AreaKnow how to decideCommon SC-500-style trap
Identity and accessChoose Microsoft Entra ID controls, Conditional Access, PIM, managed identities, workload identity federation, and app consent patternsConfusing authentication, authorization, directory roles, and Azure RBAC
Azure platform securityHarden subscriptions, resource groups, VNets, PaaS services, Key Vault, Storage, SQL, App Service, and APIsTreating network access controls as a substitute for identity and data controls
Cloud security postureUse Microsoft Defender for Cloud, security recommendations, secure score, attack paths, and Azure PolicyAssuming a recommendation automatically remediates the risk
AI securitySecure Azure AI services, Azure OpenAI workloads, RAG data, model endpoints, prompts, outputs, and identitiesThinking content filters alone protect confidential data or prevent all prompt attacks
Data protectionUse encryption, Key Vault, managed HSM, customer-managed keys, sensitivity controls, Purview, and least-privilege data accessOverusing shared keys, broad SAS tokens, and unmanaged secrets
DevOps and containersSecure GitHub/Azure DevOps, IaC, AKS, ACR, CI/CD credentials, images, and runtime workloadsScanning images but ignoring cluster identity, network, and admission controls
Monitoring and responseUse Defender XDR, Microsoft Sentinel, Log Analytics, KQL, incidents, alerts, workbooks, and playbooksConfusing SIEM/SOAR workflows with endpoint or workload protection

Azure security architecture essentials

Defense-in-depth for Azure workloads

For SC-500, expect scenarios that require combining controls rather than picking one “magic” product.

LayerExamplesWhat it protects against
IdentityEntra ID, MFA, PIM, managed identities, Conditional AccessCredential misuse, over-privilege
NetworkNSGs, Azure Firewall, WAF, Private Link, DDoS Protection, route tablesUnwanted network exposure
Resource governanceAzure Policy, initiatives, tags, locks, management groupsMisconfiguration and drift
DataEncryption, Key Vault, CMK, Purview, immutable storage, access reviewsData exposure and unauthorized modification
Workload protectionDefender for Cloud, Defender plans, endpoint/workload sensorsVulnerabilities and threats
Detection/responseDefender XDR, Sentinel, Log Analytics, playbooksAlerting, investigation, response
Notes and examples

Network security decision table

RequirementLikely control
Filter traffic at subnet or NIC levelNetwork security group
Centralized L3/L4 and FQDN filteringAzure Firewall
Protect HTTP/S apps from common web attacksWeb Application Firewall
Keep PaaS access off the public internetPrivate Endpoint / Private Link
Restrict PaaS access to selected VNetsService endpoints or private endpoints, depending on design
Secure admin access to VMs without public IPsAzure Bastion or just-in-time VM access
Protect public endpoints from volumetric attacksAzure DDoS Protection
Control outbound traffic from private workloadsFirewall, NAT Gateway, route tables, egress policy

Private Endpoint trap: Private Endpoint requires DNS planning. A workload can still fail if the private DNS zone, records, or resolver path are wrong.

Azure Policy versus RBAC versus Defender for Cloud

ToolPrimary purposeNot for
Azure PolicyEnforce or audit resource configurationGranting user permissions
Azure RBACGrant management/data accessDetecting vulnerabilities
Defender for CloudPosture management, workload protection, recommendations, alertsReplacing governance or least privilege
Resource locksPrevent delete or modification actionsFine-grained access design
Management groupsOrganize policy and access at scaleRuntime threat detection

Decision rule:

  • If the scenario says “prevent noncompliant resources from being created,” think Azure Policy.
  • If it says “allow a user to manage a resource,” think Azure RBAC.
  • If it says “find, prioritize, and remediate security risks,” think Defender for Cloud.

DevOps, containers, and workload security

CI/CD security decisions

ScenarioBest review answer
Pipeline needs Azure accessFederated identity or managed identity pattern where possible
Secrets appear in code or pipeline variablesSecret scanning, Key Vault, rotation, remove from history
Infrastructure driftInfrastructure as code plus Azure Policy
Insecure templatesIaC scanning and policy-as-code
Unreviewed production changesBranch protection, pull request approvals, environment approvals
Supply chain riskDependency scanning, artifact signing, provenance, least-privilege pipeline permissions
Notes and examples

AKS and container review

RequirementControl
Secure cluster accessMicrosoft Entra integration, Kubernetes RBAC, least privilege
Avoid static pod credentialsWorkload identity
Restrict pod-to-pod or pod-to-egress trafficNetwork policies and egress controls
Scan imagesDefender for Containers / registry scanning capabilities
Prevent untrusted imagesAdmission controls and policy
Protect secretsExternal secrets pattern, Key Vault integration, avoid plaintext Kubernetes secrets
Monitor runtime threatsDefender for Containers and logs
Keep control plane privatePrivate AKS cluster where required

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

ToolMain role
Microsoft Defender XDRCorrelates incidents across Microsoft Defender workloads
Microsoft SentinelCloud-native SIEM/SOAR for collecting, correlating, hunting, and automating response
Log AnalyticsStores and queries telemetry with KQL
Defender for CloudCloud posture and workload protection alerts
WorkbooksVisualize and analyze security data
PlaybooksLogic Apps-based automated response
Analytics rulesCreate incidents from suspicious patterns
Hunting queriesProactively search for threats
Notes and examples

Incident and alert vocabulary

TermMeaning
AlertA detection signal from a product or rule
IncidentGrouped set of related alerts/entities for investigation
EntityUser, host, IP, resource, file, process, or account involved
ConnectorData ingestion source for Sentinel
PlaybookAutomated workflow for response or enrichment
WorkbookDashboard/reporting view
KQLQuery 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.

NeedKQL idea
Filter rowswhere
Select columnsproject
Count or aggregatesummarize
Sort resultsorder by
Join data setsjoin
Parse dynamic JSON-like fieldsparse_json, extend
Limit time rangeTimeGenerated filter
Detect rare eventssummarize, 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 deploymentAzure Policy
Identify risky Azure resources and attack pathsDefender for Cloud
Protect endpoints and correlate Defender alertsMicrosoft Defender XDR
Collect logs from many sources and automate responseMicrosoft Sentinel
Store and control secrets/keys/certificatesAzure Key Vault or Managed HSM
Manage privileged admin activationMicrosoft Entra PIM
Control user access based on risk/device/locationConditional Access
Secure AI prompts and outputsAzure AI safety controls, content filters, prompt shields, validation
Govern sensitive dataMicrosoft Purview capabilities
Protect web apps from OWASP-style attacksWAF
Avoid public access to PaaS servicesPrivate Endpoint / Private Link
Secure pipeline access to AzureWorkload 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 wordingStrong 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

  1. Confusing Azure RBAC with Microsoft Entra roles Azure RBAC controls Azure resources. Microsoft Entra roles control tenant/directory administration.

  2. Assuming MFA solves authorization MFA strengthens authentication. It does not grant least privilege or replace RBAC.

  3. Using shared keys when identity-based access is available Prefer Microsoft Entra authorization and managed identities when supported.

  4. Treating secure score as compliance Secure score helps prioritize security improvements; it is not a legal or regulatory guarantee.

  5. Ignoring data-plane permissions Management-plane access and data-plane access are not always the same.

  6. Forgetting private endpoint DNS Private connectivity often fails because name resolution still points to the public endpoint.

  7. Overtrusting AI content filters Filters are important, but AI systems also need data access control, prompt hardening, monitoring, and safe tool boundaries.

  8. Giving AI tools excessive permissions If an AI agent can call a tool, the tool’s identity and scope matter. Least privilege still applies.

  9. Thinking logging equals prevention Logs support detection and investigation. Preventive controls still need to be configured.

  10. Skipping remediation ownership Recommendations, alerts, and policies only help when teams know who must act.

Put the review into practice