MicrosoftSC-500118 concepts

SC-500 Cheat Sheet

Quick reference for the Microsoft Certified: Cloud and AI Security Engineer Associate exam.

Quick Navigation

PIM — Privileged Identity Management Conditional Access and Authentication Managed Identities and Application Identity Azure Key Vault Azure Policy and RBAC Governance Network Security — NSG, ASG, Firewall Private Endpoints, Private Link, and Service Endpoints VPN, Virtual WAN, and Hybrid Connectivity Storage and Database Security AI Security — Entra Agent ID and Purview DSPM AI Security — Defender for AI and AI Gateway Compute Security — Servers and VMs Defender for Cloud — CSPM and Workload Protection Microsoft Sentinel — Data Ingestion and Analytics Microsoft Sentinel — Automation and Response Microsoft Security Copilot Container and Application Security

PIM — Privileged Identity Management

Eligible assignment: Grants JIT access — user must explicitly activate the role (with optional MFA and approval) before it is usable; does NOT grant immediate access.
Active assignment: Immediately grants the role without any activation step; use only for break-glass or service accounts that need always-on access.
PIM activation workflow: User requests activation → approval from designated approver → MFA challenge → time-limited role grant (max hours set by policy, up to 24h).
Access review (PIM): Periodic recertification where reviewers confirm whether an eligible/active assignment is still needed; unanswered reviews auto-deny or auto-approve per policy.
PIM eligible assignment — creation: No Azure CLI command exists for PIM role assignments; use Entra portal (Identity Governance > PIM > Roles > Add assignments) or Microsoft Graph API (roleManagement/directory/roleEligibilityScheduleRequests).
Exam trap — eligible vs active: Eligible assignments do NOT grant access until activated. A question asking who has 'access right now' must check active assignments, not eligible ones.

Conditional Access and Authentication

Conditional Access policy components: Assignments (users/groups, cloud apps, conditions) + Grant/Session controls — all components must match for the policy to trigger.
Named location: IP range or country/region definition used as a condition in Conditional Access policies; mark corporate IP ranges as trusted to exclude from MFA.
Authentication strength policy: Defines which authentication methods satisfy a grant control; use to require FIDO2 or Windows Hello instead of basic MFA for privileged roles.
Risk-based Conditional Access: Uses Entra ID Protection sign-in risk (low/medium/high) as a condition; require MFA or block access when sign-in risk is high.
Conditional Access for Entra Agent ID: Extends standard CA policy assignments to AI agents; agents evaluated on the same signals (risk, compliance, location) as human users.
Session control — sign-in frequency: Forces re-authentication after a specified interval; use for sensitive apps to limit persistent sessions even after a successful MFA challenge.
Device compliance condition: Requires that the device joining the session is Intune-compliant or Entra hybrid-joined before granting access to a cloud app.

Managed Identities and Application Identity

System-assigned managed identity: Created and tied to a single resource lifecycle — auto-deleted when the resource is deleted; cannot be shared across multiple resources.
User-assigned managed identity: Standalone resource with independent lifecycle; can be assigned to multiple VMs, Function Apps, etc. simultaneously; persists after resource deletion.
az identity create --name myId --resource-group myRG: Creates a user-assigned managed identity that can be attached to multiple resources.
OAuth permission grant types: Delegated permissions act on behalf of signed-in user; application permissions act as the app itself (daemon/service) — application permissions require admin consent.
Entra Agent ID: First-class identity construct for autonomous AI agents in Microsoft Entra; enables Conditional Access, blast-radius analysis in Defender XDR, and access reviews.
Exam trap — Agent ID vs Managed Identity: Managed Identity = Azure resources (VMs, Functions). Entra Agent ID = AI agents (Copilot, autonomous agents). Both eliminate stored credentials but serve different identity scenarios.

Azure Key Vault

az keyvault create --name myKV --resource-group myRG --location eastus --enable-rbac-authorization true: Creates a Key Vault using RBAC for data-plane authorization instead of legacy access policies.
az keyvault update --name myKV --default-action Deny --bypass AzureServices: Sets the Key Vault firewall to deny all public traffic while allowing trusted Azure services to bypass.
az keyvault network-rule add --name myKV --ip-address 203.0.113.0/24: Allows a specific IP range through the Key Vault firewall.
Access policy model vs RBAC model: A Key Vault uses ONE authorization model at a time — either vault access policies OR Azure RBAC for data-plane operations, not both simultaneously.
Defender for Key Vault alert: Detects suspicious access patterns (unusual caller, high-volume secret enumeration, access from Tor) — separate from Defender CSPM which finds exposed secrets.
Key rotation policy: Configures automatic rotation of cryptographic keys on a schedule; reduces risk of long-lived key exposure without manual operational overhead.
Private endpoint for Key Vault: Assigns a private IP inside the VNet to Key Vault; traffic stays on Microsoft backbone — combine with firewall deny-public to fully isolate the vault.

Azure Policy and RBAC Governance

Policy effect — deny: Blocks resource creation/update if the resource does not comply with the policy definition; strongest preventive control.
Policy effect — audit: Creates a compliance record for non-compliant resources without blocking deployment; useful for visibility before enforcing deny.
Policy effect — deployIfNotExists: Deploys a linked resource automatically when the evaluated resource lacks a required configuration; used for auto-remediation (e.g., adding missing tags, enabling diagnostics).
Policy effect — modify: Adds, replaces, or removes properties on a resource during creation or update; commonly used to enforce tags or routing table associations.
Policy initiative (definition set): Groups multiple policy definitions into a single assignable unit; assign one initiative to a scope instead of assigning many individual policies.
RBAC scope hierarchy: Management Group > Subscription > Resource Group > Resource — roles assigned at higher scopes inherit down; assignments at lower scopes can be more restrictive.
Resource lock CanNotDelete vs ReadOnly: CanNotDelete: authorized users can read/modify but not delete. ReadOnly: authorized users cannot modify or delete (blocks start/stop VM operations too).
Exam trap — Azure roles vs Entra roles: Azure RBAC roles (Owner, Contributor, Reader) control access to Azure resources. Entra directory roles (Global Administrator, Security Administrator) control Entra directory operations — completely separate role systems.

Network Security — NSG, ASG, Firewall

NSG rule evaluation order: Rules processed by ascending priority number (100 = highest priority); first matching rule wins — lower number always overrides a higher-numbered rule for the same traffic.
az network nsg rule create --nsg-name myNSG -g myRG -n AllowHTTPS --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 443: Creates an NSG inbound rule allowing HTTPS at priority 100.
Application Security Group (ASG): Logical grouping of VMs used as source or destination in NSG rules; eliminates manual IP management — assign VMs to ASGs and reference the ASG in rules.
Azure Firewall rule types: DNAT rules (inbound port translation), Network rules (L4 IP/port allow/deny), Application rules (L7 FQDN/URL filtering) — processed in that order.
Azure Firewall threat intelligence mode: Alert mode logs traffic to known malicious IPs/domains; Alert and Deny mode also blocks it — enable for all production deployments.
NSGs vs Azure Firewall: NSGs are free L3/L4 subnet/NIC filters; Azure Firewall is a paid, centralized L3-L7 service with FQDN filtering, TLS inspection, and threat intel — use both together.
Network Watcher — IP flow verify: Tests whether a specific packet (5-tuple) is allowed or denied by NSG rules for a VM; fastest tool for diagnosing blocked connectivity.
Network Watcher — effective security rules: Shows all NSG rules applied to a NIC from both NIC-level and subnet-level NSGs, merged and ordered by priority — use to diagnose rule conflicts.

Private Endpoints, Private Link, and Service Endpoints

Private Endpoint: Consumer-side: creates a NIC with a private IP in your VNet that connects to a specific Azure PaaS resource; traffic never leaves the Microsoft backbone.
Private Link Service: Provider-side: exposes your own service (behind a Standard Load Balancer) via Private Link so consumers in other VNets or subscriptions can connect privately.
Service Endpoint: Keeps the PaaS service's public IP but routes VNet subnet traffic directly over the Azure backbone — less isolation than Private Endpoints, no private IP assigned.
az network private-endpoint create --name myPE --resource-group myRG --vnet-name myVNet --subnet mySubnet --private-connection-resource-id <resourceId> --group-id blob: Creates a Private Endpoint connecting a VNet subnet to an Azure Blob Storage account.
Private DNS zone for Private Endpoints: Required for name resolution — link a privatelink.*.core.windows.net zone to the VNet so clients resolve the storage FQDN to the private endpoint IP, not the public IP.
Exam trap — Private Endpoint vs Service Endpoint: Private Endpoint assigns a private IP (complete isolation). Service Endpoint optimizes routing but keeps public IP. Exam scenarios requiring 'no public internet exposure' need Private Endpoints.
Microsoft Entra Private Access: Zero Trust Network Access (ZTNA) service replacing traditional VPN; secures access to private corporate resources using identity-based policies instead of network perimeter — does not require opening inbound firewall ports.
Azure Virtual Network Manager: Centralized management service for security admin rules and connectivity configurations across multiple VNets and subscriptions; enforces organization-wide network policies at scale.

VPN, Virtual WAN, and Hybrid Connectivity

VPN Gateway — site-to-site IPsec/IKE: Encrypted S2S tunnel between on-premises network and Azure VNet using IPsec/IKEv2; configure shared key or certificate auth, and select SKU based on aggregate throughput needs.
VPN Gateway — point-to-site (P2S): Per-user VPN from individual devices to Azure VNet; supports OpenVPN, SSTP, and IKEv2 — use Entra ID authentication for P2S to enforce Conditional Access and MFA on VPN connections.
Exam trap — Entra Private Access vs VPN Gateway: VPN Gateway creates encrypted tunnels (network-centric). Entra Private Access is identity-centric ZTNA — enforces Conditional Access, no inbound firewall ports required, preferred for Zero Trust architectures.
Azure Virtual WAN: Managed hub-and-spoke network topology integrating VPN, ExpressRoute, and Azure Firewall in a secure hub; centralized routing and security policy reduces operational overhead for large branch deployments.

Storage and Database Security

az storage account update --name myStorage --resource-group myRG --default-action Deny --bypass AzureServices Logging Metrics: Enables the storage firewall and denies all traffic except Azure trusted services, logging, and metrics.
Shared Access Signature (SAS) types: Account SAS (multi-service), Service SAS (single service), User Delegation SAS (Entra-backed, most secure) — always prefer User Delegation SAS for delegated access.
Stored access policy: Named policy on a container/queue/table/share that defines SAS permissions and expiry; revoke all SAS tokens sharing the policy by deleting the policy.
Defender for Storage — malware scanning: Scans blobs uploaded to Storage accounts for malware in near-real-time; separate feature from anomalous access detection — both must be enabled independently.
Azure SQL — Transparent Data Encryption (TDE): Encrypts SQL database, log, and backup files at rest using a DEK protected by a TDE protector — service-managed or customer-managed key in Key Vault.
Azure SQL Managed Instance — audit log destinations: Uses diagnostic settings to route audit logs to Storage Account, Log Analytics, or Event Hubs — configure in Diagnostic Settings, not server-level auditing (that is for Azure SQL Database).
Defender for Databases: Covers Azure SQL, Cosmos DB, PostgreSQL, MySQL, MariaDB, and SQL Server on VMs — provides vulnerability assessments and threat detection (e.g., SQL injection alerts).

AI Security — Entra Agent ID and Purview DSPM

Entra Agent ID — blast radius analysis: Use Defender XDR to analyze what resources an AI agent identity could reach if compromised; assess lateral movement potential before granting agent permissions.
Conditional Access for agents: Apply CA policies to Entra Agent ID identities — require compliant device or location conditions before an agent is allowed to call sensitive APIs.
Purview DSPM for AI — data overexposure: Identifies SharePoint sites and OneDrive files that are accessible to Microsoft Copilot but contain sensitive data not intended for AI consumption.
Purview DSPM for AI — AI activity insights: Provides analytics on how Copilot and other AI apps are accessing data; use to detect sensitive data being referenced in prompts and generate ready-to-use DLP policies.
Copilot Studio real-time protection: Security capability that monitors Copilot Studio agents during operation, detecting and blocking threats in real time against autonomous agent workflows.
Exam trap — DSPM for AI vs Defender for AI: Purview DSPM for AI protects DATA used by AI (overexposure in SharePoint). Defender for AI Service protects AI WORKLOADS (threat detection in Foundry). Different targets.
Microsoft 365 admin center — agent management: Central location to inventory, govern, and manage Microsoft 365 Copilot agents deployed across the enterprise.

AI Security — Defender for AI and AI Gateway

Defender for AI Service: Cloud workload protection plan in Defender for Cloud that monitors Azure AI Foundry workloads for AI-specific threat patterns (e.g., prompt injection attacks, model abuse).
Data and AI security dashboard: Unified view in Defender for Cloud showing AI workload security posture, Defender for AI alerts, and data risks from Purview DSPM — enable Defender for AI to populate it.
AI Gateway in Azure API Management: Deploy APIM as an AI Gateway fronting Azure AI Foundry; configure token quotas, rate limits, cost controls, and routing policies without changing application code.
Token quota policy (APIM AI Gateway): Sets per-subscription or per-product token consumption limits for AI model calls; prevents runaway cost and enforces fair usage across teams.
Foundry guardrails: Content safety filters and behavioral constraints configured in Azure AI Foundry that constrain what agent prompts and responses are allowed — Azure AI Content Safety integration.
Exam trap — AI Gateway vs NSG for AI: NSGs filter network traffic (IP/port). AI Gateway enforces token limits, rate limiting, and AI-specific policies at the API level — cannot be substituted by NSG rules.

Compute Security — Servers and VMs

Azure Bastion: Fully managed PaaS providing RDP/SSH through the Azure portal without exposing VM public IPs — eliminates the need for jump servers and public IP addresses on VMs.
Just-in-Time (JIT) VM Access: Locks management ports (RDP/SSH) in NSG rules until access is requested; creates time-limited NSG rules upon approval — requires Defender for Servers Plan 2.
Exam trap — Bastion vs JIT: Bastion = HOW you connect (secure browser-based RDP/SSH). JIT = WHEN ports are open (time-limited NSG rule). They solve different problems and are often used together.
Azure Disk Encryption (ADE): Guest-OS level encryption using BitLocker (Windows) or DM-Crypt (Linux); keys stored in Key Vault — protects data if physical disk is removed from datacenter.
Server-side encryption (SSE): Platform-level encryption of managed disk data at the storage layer; transparent to the OS — use customer-managed keys (CMK) in Key Vault for control over key lifecycle.
Trusted Launch (Secure Boot + vTPM): VM security type providing Secure Boot, virtual TPM, and integrity monitoring — protects against boot-level rootkits and firmware attacks on Gen 2 VMs.
Azure Arc — hybrid server onboarding: Install the Connected Machine agent on on-premises or multi-cloud servers to onboard them to Azure management, including Defender for Servers and Azure Policy.
Defender Vulnerability Management: Integrated vulnerability scanning in Defender for Servers that discovers and prioritizes OS and software vulnerabilities on Azure, Arc-enabled, and multi-cloud VMs without deploying a separate scanner agent.

Defender for Cloud — CSPM and Workload Protection

Defender CSPM: Cloud Security Posture Management: continuously evaluates configurations, generates security recommendations, maps attack paths, and assesses compliance — proactive, not reactive.
Attack path analysis: Defender CSPM feature that models how an attacker could move through misconfigurations across resources — prioritizes remediation by actual exploitability.
Defender for Cloud workload protection plans: Per-resource-type threat detection: Servers, Containers, Storage, Databases, Key Vault, App Service, DNS, Resource Manager, AI — each enabled independently.
Multi-cloud connector — AWS: Connect AWS accounts to Defender for Cloud using a CloudFormation template that deploys an IAM role; extends CSPM and threat protection to EC2 and AWS services.
Exam trap — CSPM vs workload protection: CSPM = finds misconfigurations and compliance gaps (proactive). Workload protection = detects active threats and anomalies (reactive). Enable both for complete coverage.
Defender EASM: Defender External Attack Surface Management — discovers unprotected external-facing assets (shadow IT, forgotten subdomains, exposed APIs) visible to attackers on the internet.
Security score: Defender for Cloud metric (0-100%) measuring adherence to security recommendations; improvements are weighted by severity — fix high-severity findings first for maximum score gain.
Multi-cloud connectors — AWS and GCP: Connect AWS accounts (CloudFormation IAM role) and GCP projects to Defender for Cloud; each cloud has its own connector; extends CSPM and Defender plans to non-Azure environments.

Microsoft Sentinel — Data Ingestion and Analytics

Sentinel workspace architecture: Sentinel runs on a Log Analytics workspace; create a dedicated workspace per environment (prod/dev) or region — roles: Sentinel Reader, Responder, Contributor.
Data connector — Microsoft 365 Defender: Built-in connector that ingests incidents and alerts from Defender XDR, Defender for Endpoint, and Defender for Office 365 into Sentinel with one click.
Data connector — Windows Security Events via AMA: Uses Azure Monitor Agent (AMA) and a Data Collection Rule (DCR) to collect Windows Security Event logs — newer approach replacing the legacy MMA agent.
Content hub: Sentinel marketplace for packaged solutions (analytics rules, workbooks, playbooks, parsers) by data source or threat scenario — install to accelerate deployment.
Custom log table (Auxiliary/Analytics): Ingest non-standard data into custom tables in the Log Analytics workspace using DCR-based ingestion or the Logs Ingestion API for third-party sources.
SecurityEvent | where EventID == 4625 | summarize count() by Account, bin(TimeGenerated, 1h): KQL query counting failed Windows logon events (Event ID 4625) per account per hour to detect brute-force attacks.
SigninLogs | where ResultType != "0" | where RiskLevelDuringSignIn == "high" | project TimeGenerated, UserPrincipalName, IPAddress, Location: KQL query finding risky failed sign-ins from Entra ID Protection sign-in logs.
Data retention policy: Set per-table retention in the Log Analytics workspace; default is 90 days — extend to 2 years for compliance, or use Auxiliary tier for long-term low-cost retention.

Microsoft Sentinel — Automation and Response

Analytics rule: Scheduled KQL query or ML-based rule that generates alerts and creates incidents in Sentinel when the query returns results above a threshold.
Automation rule: Lightweight rule triggered on incident creation/update to perform simple actions: assign owner, change severity/status, add tags, or trigger a playbook — no Logic App required.
Playbook (Logic App): Logic App workflow triggered by an automation rule or manually; performs complex multi-step orchestrated responses (enrich, notify, remediate) using connectors to any API.
Exam trap — automation rules vs playbooks: Automation rules handle simple incident-level actions (owner assignment, severity change). Playbooks are Logic Apps for complex orchestration. Automation rules can call playbooks.
Incident entity mapping: Configures which fields in analytics rule query results are extracted as entities (IP, Account, Host, URL) — entity enrichment powers investigation graph and entity behavior analytics.
UEBA (User and Entity Behavior Analytics): Sentinel feature that baselines normal user and entity behavior and surfaces anomalies; adds behavior scores to entities for prioritizing investigation.
Purview Audit in Defender XDR: Query Microsoft Purview Audit logs directly in Defender XDR portal for unified investigation; supports filtering by workload (Exchange, SharePoint, Entra) and user activity for compliance investigations.

Microsoft Security Copilot

Security Copilot workspace: Isolated Copilot environment with its own SCU (Security Compute Unit) capacity, role assignments, and plugin configurations — create separate workspaces for prod and dev.
Security Copilot roles: Copilot Owner: full admin including SCU management. Copilot Contributor: can use Copilot but cannot manage workspace settings or billing.
Plugin enablement: Security Copilot capabilities are limited without explicitly enabling plugins; enable Microsoft Sentinel, Defender XDR, Intune, Purview, and Entra plugins to give Copilot access to those data sources.
Security Copilot agents: Autonomous Security Copilot agents (e.g., Phishing Triage Agent, Vulnerability Remediation Agent) can be deployed from the Security Store to automate recurring analyst tasks.
Exam trap — Sentinel vs Security Copilot: Sentinel is the SIEM/SOAR that collects data and creates incidents. Security Copilot is the AI assistant that helps analysts investigate using natural language — Copilot does not replace Sentinel.
Promptbook: Saved sequence of Security Copilot prompts for repeatable investigation workflows (e.g., incident triage, threat actor profiling); share across analyst team for consistency.

Container and Application Security

Defender for Containers: Workload protection for AKS, Container Registry, Container Instances, and Container Apps — detects runtime misconfigurations, image vulnerabilities, and Kubernetes security risks.
Container Registry image scanning: Defender for Containers scans images in Azure Container Registry for OS and package vulnerabilities — enabled automatically when Defender for Containers plan is active.
AKS — Azure Policy add-on: Enforces Kubernetes admission control policies (e.g., no privileged pods, required resource limits) using Azure Policy for Kubernetes on AKS clusters.
AKS network policy: Calico or Azure network policies restrict pod-to-pod traffic within the cluster using label-based selectors — must be enabled at cluster creation time.
App Service authentication (Easy Auth): Built-in authentication module for App Service and Azure Functions that handles token validation with Entra ID, Facebook, Google, etc. without application code changes.
WAF policy modes: Detection mode: logs but does not block matching requests. Prevention mode: actively blocks and logs — always start in Detection, then switch to Prevention after validating rules.
Azure API Management security policies: Use APIM inbound policies to validate JWT tokens (validate-jwt), enforce rate limits, check IP allowlists, and transform requests before they reach backend AI or API services.

Ready to test yourself?

Start a timed SC-500 mock exam or review practice questions by domain.