SC-100 Study Guide

Business resiliency is the ability to keep operating while under attack and to return to normal afterwards. As an architect you start from what the business cannot afford to lose, not from the technology, so the first design step is naming the business-critical assets and ranking the threats against them.

What you need to know

• Security resiliency assumes a successful attack rather than a perfect perimeter: the goal is to limit damage and restore service, not only to prevent
• Critical asset management in Microsoft Security Exposure Management lets you tag assets as critical, which then raises their weight in attack path analysis and recommendations
• Prioritize by business impact, not by vulnerability count: a medium vulnerability on a domain controller outranks a critical one on a lab machine
• Recovery targets are business decisions the design has to meet: the recovery point target is how much data you can afford to lose, the recovery time target is how long you can afford to be down
• Security and reliability trade against each other, and the Well-Architected Framework asks you to make that trade explicitly rather than by accident

Exam tip: When a scenario asks you to prioritize, the expected answer almost always favours the asset with the highest business impact, even when another asset has a worse technical finding.

Microsoft Learn resource: Overview of critical asset management (opens in a new tab)

BCDR is the plan and the technology for surviving an outage or a destructive attack. On the exam, secure backup means backups an attacker who owns your production identity still cannot delete or encrypt, which is a different design from backups that merely exist.

What you need to know

• Keep at least one copy of critical backups offline or logically isolated, and test restores rather than assuming them
• Backup operators should not also be production administrators: separating those roles is what stops one compromised account destroying both copies
• Azure Arc brings non-Azure servers into scope for Azure Backup and Azure Policy, which is how a hybrid or multicloud estate gets one backup standard

Exam tip: If a scenario says a ransomware operator obtained Backup Contributor or Global Administrator, the answers that survive are immutability and multi-user authorization, not extra retention.

Microsoft Learn resource: What is the Azure Backup service? (opens in a new tab)

Microsoft's ransomware guidance is deliberately ordered: prepare a recovery path, limit the damage an attacker can do, then make entry harder. That order matters because the exam asks what you do first.

The three ransomware priorities:

1. Prepare a recovery plan: implement a secure, tested backup and restore path so you can recover without paying, and protect those backups from deliberate deletion
2. Limit the scope of damage: protect privileged roles first, because human-operated ransomware escalates to domain or tenant admin before it detonates
3. Make it harder to get in: remove the entry points incrementally, starting with remote access, email and endpoint, and patching

• Human-operated ransomware is an interactive intrusion, not a worm: the operator does reconnaissance, steals credentials and moves laterally, which is why identity controls matter more than anti-malware alone
• Double extortion means data is exfiltrated before encryption, so a clean restore does not remove the disclosure risk
• Microsoft Defender for Endpoint contributes attack surface reduction rules, controlled folder access and network protection, and Defender XDR adds automatic attack disruption for ransomware
• Recovery point trust is part of the design: a restore from a backup taken after the attacker was already inside reintroduces the attacker

Exam tip: When a question asks which mitigation to implement first against human-operated ransomware, secure backup and privileged access beat endpoint hardening, because they cap the damage of an attack already in progress.

Microsoft Learn resource: Ransomware protection in Azure (opens in a new tab)

Patching is a posture control, and the design question is who owns it for each class of workload. A cybersecurity architect recommends the update mechanism per platform and the process that proves the updates landed.

What you need to know

• Azure Update Manager is the Azure-native service for assessing and deploying operating system updates to Azure VMs, Arc-enabled servers and on-premises machines, with maintenance configurations for scheduled windows
• Windows Autopatch and Intune update rings handle Windows client and Microsoft 365 Apps updates for managed endpoints
• Microsoft Defender Vulnerability Management supplies the inventory and the risk view: which CVEs are present, which are exploitable and which devices are exposed
• Defender for Cloud raises system update recommendations and scores them, so gaps show up in Secure Score rather than only in a patching report
• Container and image workloads are patched by rebuilding and redeploying the image, not by updating the running container
• PaaS and SaaS updates belong to Microsoft under the shared responsibility model, so a design covers IaaS, containers and endpoints

Microsoft Learn resource: What is Azure Update Manager? (opens in a new tab)

The MCRA is a set of Microsoft diagrams that map Microsoft security capabilities onto an end-to-end architecture, and the MCSB is a prescriptive control benchmark for Azure and other clouds. One tells you which product covers which capability, the other tells you what good configuration looks like and how it maps to external standards.

What you need to know

• MCSB v1 groups controls into 12 domains: Network Security (NS), Identity Management (IM), Privileged Access (PA), Data Protection (DP), Asset Management (AM), Logging and Threat Detection (LT), Incident Response (IR), Posture and Vulnerability Management (PV), Endpoint Security (ES), Backup and Recovery (BR), DevOps Security (DS) and Governance and Strategy (GS)
• Each MCSB control carries a security principle, per-cloud implementation guidance and mappings to CIS, NIST, PCI-DSS, ISO 27001 and SOC 2, which is what lets you answer an auditor in their own vocabulary
• MCSB is applied in Defender for Cloud as a compliance standard, and many of its controls have a matching Azure Policy definition so they can be measured automatically
• The CISO Workshop and the Azure Top 10 Security Best Practices are the other two inputs the exam expects you to recognise as Microsoft best-practice sources

Exam tip: If the question asks how to measure or enforce a control, the answer is MCSB. If it asks which Microsoft capability covers a function, the answer is MCRA.

Microsoft Learn resource: Microsoft Cybersecurity Reference Architectures (MCRA) (opens in a new tab)

These three attacker classes need different designs, and the exam tests whether you pick controls that match the class. An insider already has legitimate access, an external attacker has to get in, and a supply chain attacker arrives inside something you chose to trust.

Insider risk: Microsoft Purview Insider Risk Management scores user activity against templates such as data theft by departing users, data leaks and risky AI usage, and Adaptive Protection then raises DLP and Conditional Access strictness for users whose risk level rises. Communication Compliance covers policy violations in messages. Design insider controls around detection and graduated response, because blocking legitimate access is not an option.

External attacks: Defender XDR plus Microsoft Sentinel cover detection and response, Conditional Access and phishing-resistant MFA cover the identity entry point, and Defender for Cloud plus Security Exposure Management cover the exposed surface. Defender External Attack Surface Management maps what an attacker can see from outside without any agent.

Supply chain attacks: the controls are DevOps Security in MCSB, software composition analysis and dependency scanning in GitHub Advanced Security or Defender for DevOps, artifact and image signing, and a software bill of materials. For third-party access, use B2B collaboration with entitlement management and access reviews rather than permanent accounts, and Conditional Access policies scoped to guests.

Exam tip: Insider scenarios point at Purview Insider Risk Management and Adaptive Protection; supply chain scenarios point at code, dependency and identity governance controls, not at endpoint anti-malware.

Microsoft Learn resource: Learn about Insider Risk Management (opens in a new tab)

MCSB v2 adds an Artificial Intelligence Security domain, which is the benchmark's answer to securing AI workloads. It covers AI platform security, AI application security and AI security monitoring, so an aligned design treats the model, the application around it and the telemetry as three separate control surfaces.

What you need to know

• The AI domain uses the same control identifier pattern as the rest of the benchmark, so AI-1 is Artificial Intelligence Security control 1 the way NS-1 is Network Security control 1
• Every MCSB v2 control carries a criticality level (Must have, Should have, Nice to have), which is how you defend a phased roadmap
• The three AI risks Microsoft names for Foundry workloads are prompt injection, sensitive data leakage in responses, and model misuse
• Microsoft Foundry guardrails (content filters, prompt shields, abuse detection) protect the model layer; Defender for Cloud covers posture and threat protection for the workload; Microsoft Purview covers auditing, classification and data security posture for prompts and responses
• AI security posture management in Defender for Cloud discovers AI workloads across Azure OpenAI Service, Azure AI Foundry, Azure Machine Learning, Amazon Bedrock and Google Vertex AI, and produces an AI bill of materials
• Managed identities and Azure Key Vault replace API keys in an aligned design, and private endpoints keep inference traffic off the public internet

Exam tip: Do not answer an AI security question with a single product. The expected design pairs a guardrail at the model layer, a posture and threat control in Defender for Cloud, and a data control in Purview.

Microsoft Learn resource: Overview of Microsoft cloud security benchmark v2 (preview) (opens in a new tab)

Zero Trust is a strategy rather than a product, and the adoption framework is how Microsoft turns it into business scenarios with defined outcomes. The exam expects you to state the three principles and to place a control in the right pillar.

The three Zero Trust principles:

1. Verify explicitly: authenticate and authorize on all available signals, including identity, location, device health, service, workload, data classification and anomalies
2. Use least privilege access: limit access with just-in-time and just-enough-access, risk-based adaptive policies and data protection
3. Assume breach: segment access, minimize blast radius, verify end-to-end encryption, and use analytics to get visibility, drive detection and improve defences

• The six Zero Trust pillars are identities, endpoints, applications, data, infrastructure and networks, with visibility, automation and orchestration across all of them
• The adoption framework organises work into business scenarios (such as modernizing security operations or securing remote and hybrid work) rather than product deployments, which is what makes it usable with business stakeholders
• Zero Trust replaces network location as a trust signal, so a design that grants access because a request came from the corporate network is not aligned
• Conditional Access is the policy enforcement point where verify explicitly and least privilege actually get applied in Microsoft Entra ID

Exam tip: Assume breach is the principle behind segmentation, blast radius and monitoring answers. Verify explicitly is behind MFA, device compliance and risk signals. Least privilege is behind PIM, entitlement management and access reviews.

Microsoft Learn resource: Zero Trust as a security foundation (opens in a new tab)

Secure AI adoption is a programme, not a setting. The design has to cover which AI tools people may use, what data those tools can reach, and how AI activity is monitored, because the fastest way to lose data to AI is an unmanaged tool nobody approved.

What you need to know

• Start with discovery: Defender for Cloud Apps finds and risk-scores SaaS AI apps, Purview Data Security Posture Management reports on AI usage and sensitive interactions, and Global Secure Access adds shadow AI discovery for network traffic
• Fix oversharing before you deploy an AI assistant, because a grounded assistant inherits the permissions of the user asking: SharePoint oversharing controls, sensitivity labels and DLP are the levers
• Purview DSPM for AI gives insights and analytics into AI activity, ready-to-use policies for prompts, data risk assessments for oversharing and compliance controls for handling prompt and response data
• Insider Risk Management has a risky AI template, and Adaptive Protection raises protection for users whose risk rises
• Microsoft Entra Agent ID gives agents their own identities so Conditional Access, entitlement management and Identity Protection apply to them
• For custom AI built on Azure, Defender for Cloud AI security posture management and AI threat protection cover the workload, and content filters and prompt shields cover the model

Exam tip: A secure AI adoption question that mentions data oversharing wants Purview and SharePoint controls first, before any Copilot or agent configuration.

Microsoft Learn resource: Learn about Data Security Posture Management (opens in a new tab)

CAF and WAF answer different questions and the exam tests the difference. CAF is about the cloud estate and the organisation around it, WAF is about a single workload and the trade-offs inside it.

What you need to know

• The CAF methodologies are Strategy, Plan, Ready, Adopt, Govern, Secure and Manage, and Secure is the one that carries the security modernization guidance
• The five WAF pillars are Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency, and WAF asks you to name the trade-offs between them rather than pretend they do not exist
• Evaluating an existing strategy means comparing it against the framework and reporting gaps, which is exactly what a scenario question is asking when it says "evaluate"
• CAF governance uses Azure Policy, management groups and cost controls as the enforcement layer, so a governance answer that has no enforcement mechanism is incomplete

Exam tip: Read the unit of concern in the question. One application under design points to WAF; the estate, the operating model or a multi-subscription rollout points to CAF.

Microsoft Learn resource: Cloud Adoption Framework: Secure overview (opens in a new tab)

Recommending is the step after evaluating: you have the gaps, now you name the Microsoft capability that closes each one and the order to do it in. Governance recommendations almost always come down to a policy, a scope and a role assignment.

What you need to know

• Azure Policy at a management group scope is the standard answer for enforcing a governance rule across many subscriptions, and initiatives group related policies into one assignment
• Azure RBAC answers who can do what, and custom roles exist for when no built-in role is a close enough fit
• Resource locks (CanNotDelete, ReadOnly) stop accidental deletion of production resources, independent of RBAC
• Microsoft Cost Management budgets and tag policies belong in a governance answer, because unmanaged sprawl is a security problem as well as a cost one
• Deny policies block non-compliant deployments up front, while DeployIfNotExists and Modify remediate what already exists, which is the difference between preventing and correcting
• Defender for Cloud Secure Score and the regulatory compliance dashboard are how you report governance progress to leadership

Microsoft Learn resource: What is Azure Policy? (opens in a new tab)

An Azure landing zone is the pre-built environment your workloads land in, with identity, networking, management and governance already decided. Designing one is how you make the secure path the default path instead of a document people are asked to follow.

What you need to know

• The landing zone design areas cover Azure billing and the Microsoft Entra tenant, identity and access management, resource organization, network topology and connectivity, security, management, governance, and platform automation and DevOps
• A platform landing zone holds shared services (identity, connectivity, management), and an application landing zone holds a workload; keeping them separate is what lets platform teams and app teams own different policy
• The management group hierarchy is the enforcement backbone: policies assigned high inherit down, so a new subscription is compliant on creation rather than after a review
• Accelerators deploy the reference implementation with Bicep or Terraform, which makes the landing zone reproducible and reviewable as code
• Azure Policy in the landing zone typically enforces diagnostic settings to a central Log Analytics workspace, Defender for Cloud plans, allowed regions and required tags
• Subscription vending is the pattern for handing out new application landing zones on request, with guardrails already applied

Exam tip: When a scenario wants every future subscription to inherit a control automatically, the answer is an Azure Policy assignment on a management group in the landing zone hierarchy, not a per-subscription configuration.

Microsoft Learn resource: What is an Azure landing zone? (opens in a new tab)

DevSecOps puts security checks inside the delivery pipeline so problems are found where they are cheap to fix. The design question is which control sits at which stage, and what happens when a check fails.

What you need to know

• Plan and design: threat modeling, using the Microsoft Threat Modeling Tool, and security requirements captured as work items rather than as advice
• Code and commit: secret scanning with push protection, code scanning with CodeQL, dependency and software composition analysis, and branch protection with required reviews
• Build: static application security testing, container and image vulnerability scanning, and signing artifacts so what you deploy is what you built
• Deploy: infrastructure as code scanned before apply, Azure Policy as the deployment gate, and workload identity federation so pipelines use short-lived tokens rather than stored secrets
• Operate: Defender for Cloud and Defender for Containers feeding runtime findings back to the owning repository, which is what closes the loop from cloud back to code
• Microsoft Defender for Cloud's DevOps security posture connects Azure DevOps and GitHub so pipeline and repository findings appear beside cloud findings

Exam tip: A pipeline that stores a service principal secret is the wrong answer when workload identity federation is available; short-lived, federated credentials are the aligned design.

Microsoft Learn resource: Secure DevOps environments for Zero Trust (opens in a new tab)

XDR correlates signals inside one vendor's estate and acts on them; SIEM ingests everything, including third-party and custom sources, and lets you hunt and report across all of it. Microsoft's answer is both, joined in the Microsoft Defender portal.

What you need to know

• Defender XDR covers Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps and Defender for Cloud signals, and presents one incident queue
• Automatic attack disruption is the XDR capability that contains an in-progress attack by itself, for example disabling a compromised account or containing a device, without waiting for an analyst
• Sentinel and Defender XDR are unified in the Defender portal, and the Defender XDR connector brings incidents and alerts into Sentinel with bidirectional sync
• Use Sentinel when you need third-party data, more than the XDR retention window, custom detections in KQL, or compliance reporting across the estate
• Design the workspace layout deliberately: one workspace is simplest for correlation, and multiple workspaces answer data residency and delegation requirements

Exam tip: A scenario that says "on-premises firewall logs", "AWS CloudTrail" or "a custom line-of-business application" needs Sentinel. One that stays inside Microsoft 365 and endpoints can be answered with Defender XDR alone.

Microsoft Learn resource: What is Microsoft Defender XDR? (opens in a new tab)

Centralized logging is what makes investigation possible after the fact, and the design question is always the same: which logs, to where, kept for how long, and who can read them. Microsoft splits this between Azure Monitor for Azure resources and Microsoft Purview Audit for Microsoft 365 activity.

What you need to know

• Audit (Standard) retains audit records for 180 days and is on by default for most organizations; records generated before 17 October 2023 kept the old 90-day retention
• Audit (Premium) retains Microsoft Entra ID, Exchange, OneDrive and SharePoint records for one year by default, other activity for 180 days, and adds custom audit log retention policies up to one year, or ten years with the add-on license
• Audit (Premium) also adds intelligent insights such as MailItemsAccessed, Send and SearchQueryInitiated, which are the events that let you scope a mailbox compromise
• An organization can have up to 50 audit log retention policies, and a custom policy always takes priority over the default one
• For Azure resources, diagnostic settings send platform logs and metrics to a Log Analytics workspace, a storage account for cheap long retention, or an event hub for a third-party SIEM
• The Office 365 Management Activity API is how you pull Microsoft 365 audit data into a non-Microsoft SIEM; every organization starts at a baseline of 2,000 requests per minute

Exam tip: A requirement to search Microsoft 365 user activity beyond 180 days needs Audit (Premium) and a retention policy, not a Sentinel connector on its own.

Microsoft Learn resource: Learn about auditing solutions in Microsoft Purview (opens in a new tab)

Hybrid and multicloud monitoring means getting servers and cloud accounts you do not own into the same pane of glass. Microsoft does that by projecting the resource into Azure with Azure Arc, and by connecting the other cloud's control plane directly.

What you need to know

• Azure Arc projects on-premises, AWS and GCP servers, Kubernetes clusters and data services into Azure as first-class resources, which is the prerequisite for Azure Policy, Defender for Cloud plans and Azure Monitor on them
• Defender for Cloud multicloud connectors for AWS and GCP read the other cloud's configuration for posture management, and deploy workload protection to its machines and containers
• The Azure Monitor Agent replaced the legacy Log Analytics agent, and data collection rules decide what it collects and where it sends it
• Sentinel data connectors cover AWS, GCP, Syslog and CEF sources, and the Codeless Connector Platform covers APIs with no built-in connector
• Design for one correlation point: scattered per-cloud consoles are the failure mode this skill is testing
• Sentinel workspaces support cross-workspace queries and Azure Lighthouse delegation, which is how a managed service provider or a multi-tenant group monitors several tenants

Microsoft Learn resource: Azure Arc overview (opens in a new tab)

SOAR is the automation layer: when a detection fires, something happens without an analyst typing. The design is about what you automate, what needs approval, and where the automation runs.

What you need to know

• In Sentinel, an automation rule decides when to act and in what order, and a playbook built on Azure Logic Apps does the work; automation rules can also just triage, by assigning an owner, changing severity or closing noise
• Playbooks can be triggered by an incident, by an alert, or manually on an entity, and they can run in a different tenant or subscription through the Logic Apps connector model
• Defender XDR contributes automated investigation and response, which investigates an alert and takes remediation actions according to the automation level set per device group
• Automatic attack disruption is Microsoft-managed containment inside Defender XDR and is not something you build; it complements your playbooks rather than replacing them
• Give the playbook an identity with least privilege: a managed identity with only the permissions its actions need, rather than a stored credential
• Put a human approval step in any playbook whose action is destructive or business-affecting, such as disabling a mailbox or isolating a production server

Exam tip: Automation rules handle the incident lifecycle; playbooks handle the external action. If a question asks how to automatically assign and deduplicate incidents, the answer is an automation rule, not a playbook.

Microsoft Learn resource: Automation in Microsoft Sentinel (opens in a new tab)

Workflows are the human process around the tooling, and the exam expects the standard incident response phases plus the difference between reacting to an alert and going looking for one.

What you need to know

• The incident response lifecycle Microsoft uses is preparation, detection and analysis, containment, eradication and recovery, and post-incident activity
• Threat hunting is proactive and hypothesis-driven: you query for behaviour no rule has flagged yet, then turn a good hunt into a detection rule
• Advanced hunting in the Defender portal uses KQL over a shared schema, and a successful hunting query becomes a custom detection rule that runs on a schedule
• Sentinel adds hunting queries, livestream for watching a hypothesis in near real time, bookmarks for preserving findings, and notebooks for deeper analysis
• An incident groups related alerts with their entities so the analyst works one case rather than twenty alerts, and incident tasks put the runbook step inside the incident
• Evaluate a workflow on measurable things: mean time to acknowledge, mean time to remediate, false positive rate, and whether findings from hunts ever become detections

Microsoft Learn resource: Threat hunting in Microsoft Sentinel (opens in a new tab)

MITRE ATT&CK is the shared vocabulary for attacker behaviour, and mapping detections to it is how you find out what you would miss. The exam names three matrices because your coverage answer has to match the estate you are protecting.

What you need to know

• ATT&CK is layered as tactics (the attacker's goal), techniques (how they achieve it), sub-techniques and procedures
• Sentinel's MITRE ATT&CK page shows current coverage by technique from your active analytics rules, and shows simulated coverage from rules you have not enabled yet, which is the gap analysis this skill asks for
• Defender XDR alerts and Defender for IoT detections carry ATT&CK technique references, so incident timelines read in the same vocabulary
• Use the ICS matrix when the scenario includes OT, SCADA or a plant floor, and pair it with Defender for IoT rather than Defender for Endpoint
• Coverage is not the same as detection quality: a technique covered by one noisy rule is a weaker position than the map suggests, which is why you evaluate rules as well as count them

Exam tip: If a question asks how to find the techniques you have no detection for, the answer is the Sentinel MITRE ATT&CK coverage view, not a workbook or a Secure Score.

Microsoft Learn resource: View MITRE ATT&CK framework coverage in Microsoft Sentinel (opens in a new tab)

AI agents act on their own and need an identity of their own, which is what Microsoft Entra Agent ID provides. Once an agent has an identity, the controls you already know apply to it, with one important exception: an agent cannot complete an interactive prompt.

What you need to know

• Agents reach resources in three patterns: on-behalf-of a signed-in user with delegated permissions, as an application with their own identity and app-only permissions, or through an agent's user account
• Conditional Access policies that target users and groups cover the on-behalf-of pattern, because the user is the subject of that token; policies that target agent identities cover the app-only pattern
• A policy assigned to all users does not include agents' user accounts, so a design that relies on one blanket policy leaves agents unprotected
• Agents cannot satisfy interactive controls such as MFA, so agent policies use identity filters, risk signals and named locations as their control points instead
• Custom security attributes such as Environment or DataSensitivity let you target agents at scale, for example blocking non-production agents from production resources
• Microsoft Entra ID Protection raises risk for agent identities, and there are Conditional Access templates to block high-risk agents, and to cover autonomous and on-behalf-of access

Exam tip: Test agent policies in report-only mode first, and audit broad policies such as "all users require MFA" for agent impact before you add anything new.

Microsoft Learn resource: Conditional Access for agents (opens in a new tab)

This is the domain's widest skill and it rewards a layered answer. For any service model, the design has three layers: who the identity is, how the network reaches it, and what the application itself enforces.

What you need to know

• Identity layer: one identity provider for everything. Federate or provision SaaS apps into Microsoft Entra ID, use managed identities for PaaS-to-PaaS, and use Microsoft Entra ID authentication for Azure VMs and SQL rather than local accounts
• Network layer: private endpoints and Private Link for PaaS so the service has no public path, network security groups and Azure Firewall for IaaS, and Microsoft Entra Private Access rather than a VPN for on-premises applications
• Application layer: app-enforced restrictions, Conditional Access App Control through Defender for Cloud Apps for session-level controls, and API authorization scopes
• The shared responsibility model sets how much of this is yours: in SaaS you own identity, data and configuration; in PaaS you add the application; in IaaS you add the operating system and network
• For multicloud, extend the same Entra identity plane using workload identity federation to AWS and GCP instead of long-lived keys, and bring the resources into Defender for Cloud with the AWS and GCP connectors
• Conditional Access is the one control point that covers SaaS, PaaS portals and Azure management alike, which is why it appears in almost every answer here

Exam tip: When a scenario says a PaaS service must not be reachable from the internet, the answer is a private endpoint plus disabling public network access, not a firewall rule on the service.

Microsoft Learn resource: What is Microsoft Entra? (opens in a new tab)

The tenant design decides how identities arrive, how they authenticate, and how resilient sign-in is when something breaks. Hybrid identity is where most exam scenarios live, because most organizations still have Active Directory.

What you need to know

• Microsoft Entra Connect Sync runs on a server you manage and supports filtering and complex transformations; Microsoft Entra Cloud Sync is agent-based, supports multiple disconnected forests and needs no sync server
• Enable password hash synchronization alongside pass-through authentication or federation so you have a working fallback if the on-premises path fails
• Microsoft Entra Connect Health monitors sync and AD FS, and Identity Secure Score reports posture in the Microsoft Entra admin center
• Multiple tenants are a real answer when data residency, regulatory separation or an acquisition demands it, and cross-tenant synchronization plus cross-tenant access settings then join them
• Break-glass accounts are cloud-only, excluded from Conditional Access, protected with strong credentials, and monitored, so a policy mistake cannot lock everyone out
• For multicloud, workload identity federation lets an AWS or GCP workload get a Microsoft Entra token without a stored secret

Exam tip: Password hash synchronization is the resilience answer. If a scenario says sign-in must keep working when the on-premises datacentre is unavailable, that is what you recommend.

Microsoft Learn resource: Choose the right authentication method for your Microsoft Entra hybrid identity solution (opens in a new tab)

External identity design is about letting people who are not your employees in, with a lifecycle that ends. The exam distinguishes collaboration with another organization from a customer-facing application, and adds verifiable credentials as the decentralized option.

What you need to know

• B2B collaboration invites an external user as a guest in your tenant, and they authenticate with their own organization's credentials, so you never manage their password
• B2B direct connect creates a mutual trust that powers Teams shared channels, where the external user stays in their own tenant and is not provisioned as a guest in yours
• Cross-tenant access settings control inbound and outbound access per partner tenant, including whether you trust their MFA and device compliance claims, which avoids asking a partner's users to register MFA with you twice
• Microsoft Entra External ID is the customer-facing option, with its own external tenant, self-service sign-up, and identity providers such as Google, Facebook and one-time passcode
• Govern the lifecycle with entitlement management access packages: a sponsor, an expiry date, an approval workflow, and access reviews that remove guests who no longer need access
• Microsoft Entra Verified ID implements decentralized identity with verifiable credentials, where the holder keeps the credential in a wallet and presents proof without the verifier calling the issuer

Exam tip: Trusting a partner tenant's MFA claim in cross-tenant access settings is the expected answer when the scenario complains that partners must register for MFA twice.

Microsoft Learn resource: Introduction to Microsoft Entra External ID (opens in a new tab)

A modern strategy authenticates with something phishing-resistant, authorizes on signals rather than on network location, and can revoke access mid-session. These four capabilities are how Microsoft Entra ID does each part.

What you need to know

• Conditional Access is the policy engine: assignments (who, what resource, which conditions) decide when a policy applies, and access controls (block, grant with MFA, require compliant device, session controls) decide what happens
• Authentication strength in Conditional Access lets you require a specific method rather than just any MFA, which is how you demand phishing-resistant credentials such as FIDO2 security keys, Windows Hello for Business or certificate-based authentication for administrators
• Continuous access evaluation lets a resource provider reject an access token before it expires when a critical event occurs (account disabled, password change, admin revocation) or a policy is violated, instead of waiting up to an hour for token lifetime
• Risk scoring comes from Microsoft Entra ID Protection, which calculates user risk and sign-in risk, and Conditional Access consumes those as conditions to force a password change or MFA
• Protected actions attach Conditional Access requirements to specific high-impact permissions, such as changing Conditional Access policies or cross-tenant access settings, so the check happens at the moment of the action rather than only at sign-in
• Legacy authentication protocols do not support MFA or Conditional Access conditions properly, so blocking them is a baseline recommendation

Exam tip: Protected actions and PIM solve different problems. PIM controls who may hold a role; protected actions control what extra proof is needed to use a specific permission.

Microsoft Learn resource: What is Conditional Access? (opens in a new tab)

Validation means checking a real policy set against the three Zero Trust principles and reporting the gaps, which is a different task from writing a new policy. Look for what the policies do not cover as hard as what they do.

What you need to know

• Verify explicitly: every user and every application should be in scope of at least one policy, MFA should be required for administrators and for risky sign-ins, and device compliance should be a condition where the data warrants it
• Use least privilege: sessions should be limited where risk is higher, with sign-in frequency and persistent browser session controls, and admin access should come through PIM rather than standing assignment
• Assume breach: risk-based policies should respond to Identity Protection signals, continuous access evaluation should be in play, and there should be no blanket location-based trust
• Common gaps to report: policies scoped to a pilot group and never widened, applications excluded and never revisited, legacy authentication still allowed, guests out of scope, and service accounts excluded wholesale
• The Conditional Access gap analyzer workbook and the policy coverage view show sign-ins that no policy applied to, which is the evidence for a validation finding
• Excluded break-glass accounts are correct design, not a gap, as long as they are few, cloud-only and monitored

Exam tip: A sign-in that matched no policy is the finding the exam wants you to spot. Coverage gaps outrank policy tuning in a validation answer.

Microsoft Learn resource: Plan a Conditional Access deployment (opens in a new tab)

Active Directory is still the most attacked system in most enterprises, and hardening it is about removing the paths an attacker uses after the first foothold. Specify requirements as controls, not as products.

What you need to know

• Reduce membership of Tier 0 groups (Domain Admins, Enterprise Admins, Schema Admins, Administrators) to the minimum, and keep those accounts off ordinary workstations
• Protect the credential paths: enable Credential Guard, disable unconstrained delegation, remove reversible encryption, and require SMB signing and LDAP channel binding and signing
• Get rid of legacy protocols and weak configuration: NTLMv1, unconstrained Kerberos delegation, print spooler on domain controllers, and unmanaged service accounts with weak passwords
• Rotate the krbtgt account password on a schedule and after any suspected compromise, because a golden ticket survives everything else
• Deploy Microsoft Defender for Identity sensors on domain controllers and AD FS or AD CS servers, for detection and for its identity posture recommendations
• Protect Active Directory Certificate Services: misconfigured certificate templates that allow requester-supplied subject names are a well-known privilege escalation route

Exam tip: Defender for Identity is the detection and posture answer for AD DS. Group Policy, Windows LAPS and tiering are the hardening answers. A question asking to detect an attack in progress wants the sensor.

Microsoft Learn resource: Microsoft Defender for Identity overview (opens in a new tab)

The goal of this design is that no secret is stored in code, configuration or a pipeline variable. Azure Key Vault holds the material, managed identities remove the bootstrap secret, and the design decides where the key actually lives.

What you need to know

• Use managed identities so an application authenticates to Key Vault with no credential of its own, and use workload identity federation for pipelines and non-Azure workloads
• Key Vault supports two permission models: Azure RBAC, which is the recommended one, and legacy vault access policies
• Soft delete and purge protection stop a deleted vault or key being lost, and purge protection cannot be turned off once enabled
• Turn on automatic rotation for keys and use Key Vault certificate lifecycle management with an integrated certificate authority so certificates renew before they expire
• Customer-managed keys for services such as Azure Storage and Azure SQL live in Key Vault or Managed HSM, and a deleted key makes the encrypted data unreadable, which is why purge protection is a prerequisite for some of those integrations
• Restrict network access with a private endpoint or the Key Vault firewall, and log every access through diagnostic settings to a workspace

Exam tip: Managed identity plus Key Vault is the expected answer whenever a scenario describes a connection string or an API key stored in application configuration.

Microsoft Learn resource: About Azure Key Vault (opens in a new tab)

The enterprise access model replaced the old tier model. It organises access by plane rather than by on-premises tier, and its central rule is that a lower plane must never be able to control a higher one.

What you need to know

• The planes are the control plane (identity systems and the management of everything else), the management plane (IT operations of workloads), the data and workload plane (the applications and data themselves), plus user and app access
• Privilege escalation paths are what the model exists to close: if a workload administrator can reset a Global Administrator's password, the control plane is not actually higher
• The three device security levels that match it are enterprise (standard managed device), specialized (hardened managed device) and privileged (a privileged access workstation)
• Delegate with the least privileged built-in role that fits: Microsoft Entra ID has many task-specific roles, and administrative units scope a role to part of the directory
• Cloud administrative accounts should be separate, cloud-only identities rather than synchronized accounts, so an on-premises compromise does not reach the control plane
• In Azure, scope role assignments at the resource group or resource rather than the subscription, and prefer built-in roles over custom ones

Exam tip: Any answer that lets a workload or management-plane administrator modify identity configuration breaks the enterprise access model, however convenient it looks.

Microsoft Learn resource: Enterprise access model (opens in a new tab)

Evaluating governance means asking whether access is granted deliberately, for a reason, for a limited time, and reviewed. These three features answer those questions in order.

What you need to know

• PIM makes a role assignment eligible instead of active, so the user activates it with MFA, a justification and optionally an approval, and it deactivates automatically after the configured window
• PIM covers Microsoft Entra roles, Azure resource roles and PIM for Groups, which is how you bring group-based access and some third-party applications under the same just-in-time model
• Entitlement management bundles resources into an access package with a policy: who may request, who approves, how long it lasts, and what happens at expiry, including automatic assignment based on user attributes
• Access reviews put a named reviewer in front of an access decision on a schedule, with the option to remove access automatically when a reviewer does not respond
• PIM alerts and the PIM audit history are the evidence for an evaluation: standing Global Administrators, roles activated and never used, and assignments outside PIM
• Report the number of permanent privileged assignments as a finding; Microsoft's guidance is to have very few, with break-glass accounts as the deliberate exception

Exam tip: Eligible versus active is a favourite distinction. Eligible means the user must activate; active means they already have it.

Microsoft Learn resource: What is Microsoft Entra Privileged Identity Management? (opens in a new tab)

An evaluation of AD DS is a hunt for the standard attack paths. Know the named attacks, know which configuration enables each, and know which tool surfaces it.

What you need to know

• Defender for Identity produces identity posture assessments for exactly these conditions, so it is the evidence-gathering tool for this evaluation
• Resilience also means recovery: a tested forest recovery plan, offline domain controller backups, and documented krbtgt and DSRM procedures
• Privileged group membership should be reviewed on a schedule, and Protected Users plus authentication policy silos limit where privileged credentials can be used
• Group Policy delegation is an escalation path people forget: whoever can edit a GPO linked to a domain controller effectively controls it

Microsoft Learn resource: Microsoft Defender for Identity's security posture assessments (opens in a new tab)

Tenant administration is the control plane, so it gets the strongest controls you have. The design applies the same pattern to every tenant and every cloud you administer, not just to Microsoft Entra ID.

What you need to know

• Require phishing-resistant MFA through Conditional Access authentication strength for all administrative roles, and require a compliant or privileged-access device
• Put every privileged role behind PIM with approval and a short activation window, and keep a very small number of monitored break-glass accounts outside the policies
• Separate administrative identities from user identities, cloud-only and not synchronized, and give administrators no mailbox or general internet browsing on the administrative session
• Protected actions add a Conditional Access requirement to the most sensitive operations, so changing Conditional Access or cross-tenant access settings needs fresh, strong authentication
• For SaaS tenants, bring administration into Microsoft Entra ID with single sign-on and provisioning so the account lifecycle is central, and use Defender for Cloud Apps to monitor privileged activity
• For AWS and GCP, federate administrative access to Microsoft Entra ID with workload identity federation or SAML rather than issuing long-lived IAM users and keys

Exam tip: Administration from an unmanaged or personal device is a wrong answer in this skill, no matter how strong the authentication is.

Microsoft Learn resource: Securing privileged access (opens in a new tab)

Cloud infrastructure entitlement management (CIEM) is about permissions that were granted and never used. In a multicloud estate the gap between permissions granted and permissions actually exercised is the real attack surface, and Microsoft now measures and closes that gap inside Microsoft Defender for Cloud.

What you need to know

• CIEM is a capability of the Defender CSPM plan in Microsoft Defender for Cloud, switched on with a Permissions Management toggle in the plan settings, and it covers Microsoft Entra ID, AWS IAM and Google Cloud IAM identities
• Microsoft Entra Permissions Management, the standalone CIEM product, has been retired, so it is not the answer to a current design question; the CIEM capabilities in Defender for Cloud were not affected by that retirement
• The Permission Creep Index is deprecated and no longer appears in recommendations, replaced by activity-based CIEM logic
• Inactive identity detection is based on unused role assignments over a 90-day lookback, and identities younger than 90 days are exempt from it
• Findings surface as identity and access recommendations, through the cloud security explorer for graph queries, and inside attack paths where an over-permissioned identity enables lateral movement
• Azure-native controls do the remediation: narrow Azure RBAC scopes, deny assignments, and Microsoft Entra PIM for Azure resource roles when a workload needs elevation only occasionally

Exam tip: Reach for Defender CSPM rather than a standalone product when a scenario asks how to find and right-size excessive permissions across Azure, AWS and Google Cloud.

Microsoft Learn resource: Cloud infrastructure entitlement management (CIEM) (opens in a new tab)

Evaluating a review solution means checking that reviews exist, that the right people do them, and that the outcome is applied. A review nobody acts on is worse than none, because it creates a record of approval.

What you need to know

• Access reviews in Microsoft Entra ID cover group membership, application assignment, Microsoft Entra and Azure resource roles through PIM, and access package assignments
• Reviewers can be the resource owner, the group owner, selected users, the users themselves (self-review), or the user's manager
• Configure what happens when a reviewer does not respond: no change, remove access, or approve; removing access is the safer default for sensitive resources
• Recurrence, duration and auto-apply are the settings that turn a review into a control: auto-apply removes the manual step where governance usually fails
• Review guests separately and more often than employees, because their access is the most likely to be stale
• The evaluation questions to ask: are privileged roles reviewed, are guests reviewed, is auto-apply on, are decisions made or rubber-stamped, and is there a record for the auditor

Microsoft Learn resource: What are access reviews? (opens in a new tab)

Identity controls cannot compensate for a compromised device: if an attacker controls the workstation, they can steal tokens after MFA, inject into an admin session and replay credentials from memory. So the device sets the upper bound of trust for privileged access.

What you need to know

• A privileged access workstation is a hardened, Intune-managed Windows device used only for administration, isolated from email, general browsing and productivity work
• Its controls are strong authentication (Windows Hello for Business or FIDO2), hardware root of trust, Credential Guard, application control, no local administrator rights for the user, and restricted outbound network access
• Enrol it from first boot with Windows Autopilot and Intune, enforce a compliance policy, and require that compliant device in the Conditional Access policy for administrative roles
• The device security levels map to the enterprise access model: enterprise for standard users, specialized for sensitive operators, privileged for control-plane administrators
• For remote administration of servers, use Azure Bastion so RDP and SSH go through a managed service in the virtual network instead of public IP addresses, and use just-in-time VM access in Defender for Cloud to open ports only on request
• Microsoft Entra Private Access replaces a broad VPN with per-application access governed by Conditional Access, which suits administration of on-premises consoles

Exam tip: Just-in-time VM access and Azure Bastion answer different questions. Bastion removes the public endpoint; just-in-time access opens a port for a limited window. A scenario with no public IP allowed at all wants Bastion.

Microsoft Learn resource: Securing devices as part of the privileged access story (opens in a new tab)

This is the architect's translation job: a regulation says what outcome is required, and you name the technical control that produces it plus the evidence that proves it. The exam tests whether you can go from a requirement sentence to a specific Microsoft capability.

What you need to know

• Work requirement by requirement: identify the obligation, map it to a control family, pick the Microsoft capability, then decide how the control is measured and evidenced
• Microsoft Purview Compliance Manager is the translation tool: assessments for a regulation break it into improvement actions, each with implementation guidance, a score and a test result
• Compliance Manager separates your improvement actions from Microsoft-managed controls, which is the shared responsibility model made auditable
• Residency, retention and deletion requirements land on Purview Data Lifecycle Management and Records Management; access requirements land on Conditional Access, PIM and access reviews; encryption requirements land on customer-managed keys and Key Vault
• MCSB control mappings to NIST, CIS, PCI-DSS, ISO 27001 and SOC 2 let you answer an auditor's control reference with an Azure configuration
• Evidence matters as much as the control: a requirement is not met until you can show the log, the report or the policy compliance state

Exam tip: When the question says translate or map a requirement, reach for Compliance Manager assessments and improvement actions rather than a single product feature.

Microsoft Learn resource: Microsoft Purview Compliance Manager (opens in a new tab)

Purview is the compliance and data governance layer for Microsoft 365 and beyond. A design usually combines classification, protection, retention and monitoring rather than a single solution.

Information protection: sensitive information types, trainable classifiers and exact data match find the data, and sensitivity labels apply encryption, marking and access restriction that travel with the file.

Data loss prevention: DLP policies act on sensitive data in Exchange, SharePoint, OneDrive, Teams, endpoints and, through browser data security, in AI prompts. Policy tips educate, and blocking enforces.

Data lifecycle and records management: retention labels and policies keep what must be kept and delete what must go, and records management adds declaration, disposition review and an immutable audit of disposal.

Insider risk and compliance monitoring: Insider Risk Management scores risky behaviour, Communication Compliance reviews messages against policy, and Audit provides the record.

Data Security Posture Management: reports where sensitive data sits, who can reach it, how it is used and whether policy coverage has gaps, across Microsoft 365, Azure, Fabric and connected third-party SaaS.

Exam tip: Sensitivity labels protect the item wherever it goes; DLP acts on the action at the moment it happens. A requirement that protection must survive the file leaving the tenant is a labelling answer.

Microsoft Learn resource: Learn about Microsoft Purview (opens in a new tab)

Azure Policy is how a compliance requirement becomes something the platform enforces rather than something people are asked to remember. The design decides the effect, the scope and what happens to resources that already exist.

What you need to know

• The effects that matter for security are Deny (block the deployment), Audit (report only), DeployIfNotExists and Modify (remediate), and AuditIfNotExists (report a missing related resource)
• Initiatives group policies into one assignable set, which is how a whole regulatory standard is applied at once
• Assign at a management group so the policy inherits to current and future subscriptions, and use exemptions with an expiry rather than removing the assignment
• Existing non-compliant resources need a remediation task, because DeployIfNotExists and Modify act at deployment time unless you remediate explicitly
• Remediation runs under a managed identity that needs a role assignment, which is the step most often missed in a design
• Typical security policies to name: require diagnostic settings to a central workspace, allowed locations, allowed resource types, require private endpoints, deny public network access on storage, and enforce customer-managed keys

Exam tip: Audit does not stop anything. If the requirement is that a non-compliant resource must never be created, the effect is Deny.

Microsoft Learn resource: Azure Policy definitions effect basics (opens in a new tab)

Defender for Cloud's regulatory compliance dashboard is where you show an auditor how the cloud estate measures against a standard. Evaluating with it means reading the control failures and knowing which are yours to fix.

What you need to know

• The Microsoft cloud security benchmark is applied by default to every Azure subscription, and you add standards such as NIST SP 800-53, PCI DSS, ISO 27001, CIS benchmarks and SOC 2 as needed
• Standards can be assigned at management group or subscription scope, and you can create a custom standard from selected recommendations for an internal policy
• The dashboard shows passed and failed assessments per control, and each failed assessment links to the affected resources and the remediation steps
• Some controls are marked as manual attestation, because no automated assessment can prove them; these need documented evidence rather than a configuration change
• Secure Score measures posture improvement, while the compliance dashboard measures alignment with a named standard; they answer different questions and the exam separates them
• AWS and GCP accounts connected with multicloud connectors get their own applicable standards, so one dashboard covers the estate

Exam tip: Compliance Manager is for Microsoft 365 and organisational compliance; the Defender for Cloud regulatory compliance dashboard is for cloud infrastructure. Pick by what the scenario is measuring.

Microsoft Learn resource: Improve regulatory compliance (opens in a new tab)

Defender for Cloud has two jobs: cloud security posture management, which tells you how well the estate is configured, and cloud workload protection, which detects threats against the running workloads. Posture evaluation is the first job, and the Microsoft cloud security benchmark is the yardstick it uses out of the box.

What you need to know

• The free foundational CSPM tier gives recommendations, Secure Score and asset inventory for every connected subscription; Defender CSPM is the paid plan that adds attack path analysis, the cloud security explorer, agentless scanning and data-aware posture
• MCSB is assigned by default to every Azure subscription, and its controls are what most recommendations derive from
• Recommendations carry severity and a Secure Score impact, and each one lists the affected resources with remediation steps, often with a Fix button for one-click remediation
• Governance rules assign an owner and a due date to a recommendation, which turns a finding into accountable work and reports on overdue items
• Exemptions with a justification and an expiry are the supported way to accept a finding, rather than ignoring it
• Continuous export sends recommendations and alerts to Log Analytics or an event hub so posture data reaches Sentinel

Exam tip: Attack path analysis and the cloud security explorer are Defender CSPM features, not free tier features. A scenario that asks to find exploitable chains across resources needs the paid plan.

Microsoft Learn resource: What is Microsoft Defender for Cloud? (opens in a new tab)

Secure Score turns posture into a single number with a list of actions behind it, which is what makes it useful with leadership. The exam distinguishes two scores that share the name, so read which estate the scenario is talking about.

What you need to know

• Microsoft Secure Score groups improvement actions and tracks them over time, with a comparison against organizations of similar size
• An improvement action can be marked as planned, third party, alternate mitigation, or risk accepted, and the last two remove its points while keeping the record
• In Defender for Cloud, points are awarded per security control and a control only scores when all of its recommendations are healthy for a resource, which is why partial remediation can show no movement
• Score is a relative measure of improvement, not an absolute measure of safety: a high score with an unprotected critical asset is still a bad position
• Microsoft Secure Score now sits inside Exposure management in the Defender portal alongside exposure insights and initiatives

Exam tip: If the scenario names Microsoft 365, identities or mailboxes, it is Microsoft Secure Score. If it names subscriptions, virtual machines or AWS accounts, it is the Defender for Cloud secure score.

Microsoft Learn resource: Microsoft Secure Score (opens in a new tab)

Integrated means one posture view across Azure, other clouds and on-premises, with one set of standards. Defender for Cloud gets there through connectors for the other clouds and Azure Arc for everything else.

What you need to know

• The AWS and GCP connectors onboard accounts, organizations and projects for posture management, and can auto-provision workload protection to their machines, containers and databases
• Connected AWS and GCP resources are assessed against MCSB plus cloud-specific standards such as the CIS benchmarks for that cloud
• Agentless scanning reads disk snapshots for vulnerabilities, secrets and malware without installing anything on the machine, which makes multicloud coverage practical
• Data-aware security posture discovers sensitive data in storage and databases and factors it into risk, so an exposed bucket with sensitive data outranks an exposed empty one
• The cloud security explorer queries the security graph across clouds, for example internet-exposed virtual machines with a high severity vulnerability and access to sensitive data
• Design one management group and policy hierarchy for Azure, and mirror the same standards on the other clouds, so posture is comparable rather than merely present

Microsoft Learn resource: Connect AWS accounts to Microsoft Defender for Cloud (opens in a new tab)

Workload protection is the paid, per-resource-type side of Defender for Cloud. Selecting means matching the plan to what the scenario actually runs, and knowing what each plan detects.

What you need to know

• Plans are enabled per subscription, and some can be enabled per resource, which is how you pilot without a full rollout
• Defender for Servers Plan 1 gives endpoint detection and response through Defender for Endpoint; Plan 2 adds vulnerability assessment at scale, file integrity monitoring, just-in-time VM access and agentless scanning
• Defender for Cloud alerts appear in Defender XDR, so cloud detections correlate with endpoint and identity signals in one incident

Exam tip: A requirement to scan uploaded files for malware in a storage account is Defender for Storage. A requirement to detect a compromised VM is Defender for Servers.

Microsoft Learn resource: Defender for Servers (opens in a new tab)

Azure Arc makes a machine or cluster you do not host behave like an Azure resource. That projection is the prerequisite for nearly every Azure governance and security control reaching outside Azure.

What you need to know

• Arc-enabled servers get an Azure Resource Manager identity, which means Azure Policy, Azure RBAC, tags, Azure Monitor, Update Manager and Defender for Cloud plans all apply to them
• Arc-enabled Kubernetes brings on-premises and other-cloud clusters under GitOps configuration, Azure Policy for Kubernetes and Defender for Containers
• The Connected Machine agent uses outbound HTTPS only, and Azure Arc Private Link Scope keeps that traffic off the public internet
• Each Arc-enabled server gets a system-assigned managed identity, so scripts and extensions on it can authenticate to Azure services without a stored secret
• Arc-enabled data services and Arc-enabled SQL Server extend assessment and Defender coverage to databases outside Azure
• Design the Arc resource layout the way you design Azure: resource groups and management groups that let policy inherit, rather than one flat group per site

Exam tip: If a question asks how to apply Azure Policy or a Defender for Cloud plan to an on-premises or AWS server, the enabling step is Azure Arc.

Microsoft Learn resource: What is Azure Arc-enabled servers? (opens in a new tab)

Defender EASM looks at your organization from the outside, the way an attacker does, and finds the internet-facing assets you did not know you owned. It needs no agent and no access to the assets, because discovery starts from what is publicly observable.

What you need to know

• Discovery starts from seeds you provide (domains, IP blocks, host names, ASNs, contacts) and expands by following observed relationships to build an attack surface inventory
• Discovered assets are classified as approved inventory, candidate, requires investigation, dependency or monitor only, so you confirm ownership rather than accept everything the crawler found
• Dashboards cover attack surface summary, security posture, GDPR compliance and the OWASP Top 10, and inventory findings include expired certificates, weak TLS, exposed administrative ports and known CVEs
• Shadow IT, forgotten marketing sites, acquired-company domains and misconfigured subdomains are exactly what this tool surfaces, and none of them appear in an agent-based inventory
• EASM data integrates with Microsoft Security Exposure Management through the External Attack Surface initiative, which puts external exposure beside internal attack paths
• Export data to Log Analytics or Azure Data Explorer when you want it queried alongside other security data

Exam tip: Defender EASM is the answer for unknown internet-facing assets. Defender Vulnerability Management is the answer for known, managed devices.

Microsoft Learn resource: Microsoft Defender External Attack Surface Management overview (opens in a new tab)

Security Exposure Management is the layer above the individual posture tools: it joins their data into one exposure graph and tells you which handful of fixes actually reduces risk. The skill asks for a process, so think in terms of what gets prioritized and who acts.

What you need to know

• Attack paths are end-to-end chains from an entry point to a critical asset, built from the exposure graph across endpoints, identities and cloud, including hybrid on-premises to cloud paths
• Choke points are the assets that many attack paths run through, and fixing one closes several paths at once, which is the prioritization rule this skill is really testing
• Critical asset management is a prerequisite: until assets are classified as critical, attack paths cannot be ranked by what they threaten
• Initiatives group metrics and recommendations around a security programme, such as ransomware protection, business email compromise, endpoint security or the external attack surface, each with its own score to track over time
• Security insights and the attack surface map give the exploratory view: explore resources and connections, then drill into a specific asset
• A workable process: classify critical assets, pick the initiatives that match the business risks, remediate choke points first, then track initiative scores as the reported metric

Exam tip: Prioritize choke points over individual recommendations. Closing one choke point beats remediating several unconnected findings, and that is the answer the exam wants.

Microsoft Learn resource: What is Microsoft Security Exposure Management? (opens in a new tab)

Server requirements have to hold across Windows, Linux, Azure, other clouds and the datacentre, so specify them as outcomes and then name the mechanism per platform. A requirement that only works on Windows in Azure is not a requirement, it is a configuration.

What you need to know

• Endpoint detection and response on every server, delivered by Microsoft Defender for Endpoint through Defender for Servers, on Windows and Linux alike
• A defined security baseline per operating system, applied by Azure Machine Configuration for Arc and Azure machines or by Group Policy and Intune where those apply
• No management ports open to the internet: use Azure Bastion, just-in-time VM access, or a private path through Microsoft Entra Private Access
• Disk encryption at rest, with Azure Disk Encryption or encryption at host, and customer-managed keys where policy requires it
• Vulnerability assessment and a patching mechanism with reporting, through Defender Vulnerability Management and Azure Update Manager
• Identity-based administration: Microsoft Entra ID sign-in for Azure VMs, no shared local accounts, and Windows LAPS where local administrator accounts must exist

Microsoft Learn resource: Microsoft Defender for Endpoint overview (opens in a new tab)

Client requirements split by who owns the device. A corporate device can be fully managed; a personal device can only be asked to protect the organization's data inside the app, and the exam tests whether you pick the right one.

What you need to know

• Compliance policies define what healthy means (encryption, OS version, no jailbreak, Defender risk level), and Conditional Access uses the compliance state as a grant control, which is the join between Intune and Microsoft Entra ID
• App protection policies can require a PIN, block copy and paste to unmanaged apps, prevent save-as to personal storage and selectively wipe organizational data, all without managing the device
• Mobile threat defence integration feeds a device risk level from Defender for Endpoint on iOS and Android into the compliance policy
• Configuration profiles carry the hardening: BitLocker, firewall, attack surface reduction rules, Credential Guard, LAPS and Windows Update rings on Windows; platform equivalents elsewhere
• Windows Autopilot provisions a device into the managed state from first boot, which removes the window where a new device is unmanaged
• Security baselines in Intune give a Microsoft-recommended starting configuration that you then tune rather than build from nothing

Exam tip: BYOD plus "we cannot manage the device" always points to app protection policies, not to enrolment.

Microsoft Learn resource: Device compliance policies in Microsoft Intune (opens in a new tab)

IoT devices usually cannot run an agent, often cannot be patched on your schedule, and frequently ship with default credentials. So the requirements move to identity, network position and monitoring rather than endpoint software.

What you need to know

• Give every device a unique identity with certificate-based or TPM-based attestation through the Device Provisioning Service, never a shared symmetric key across a fleet
• Segment devices onto their own network with no path to corporate resources, and allow only outbound connections to the IoT hub or gateway
• Require signed firmware and a secure boot chain, with a supported over-the-air update mechanism, because a device you cannot update is a permanent vulnerability
• Encrypt in transit with TLS and at rest on the device where the hardware allows it, and keep no more data on the device than the function needs
• Microsoft Defender for IoT provides agentless network monitoring for device discovery and threat detection, and there are micro-agents for the devices that can run one
• Design the device lifecycle: provisioning, credential rotation, decommissioning and revocation, because a retired device with valid credentials is an open door

Microsoft Learn resource: Secure your IoT solutions (opens in a new tab)

OT networks run protocols and equipment that IT tools do not understand, and cannot tolerate active scanning. Defender for IoT is built for that constraint: it listens rather than probes.

What you need to know

• Defender for IoT uses passive network monitoring through a SPAN port or a network TAP, so it discovers and monitors without sending traffic that could disturb a control system
• It performs deep packet inspection of industrial protocols such as Modbus, DNP3, BACnet, OPC UA, S7 and Profinet, producing an asset inventory with vendor, model, firmware and protocol
• Behavioural analytics learn the normal process baseline and alert on deviations, which is how unauthorised commands and configuration changes are caught
• Detections map to the MITRE ATT&CK for ICS matrix, which is why the exam names that matrix in Domain 2
• Deployment is a network sensor per site, optionally with an on-premises management console for air-gapped environments, and cloud-connected sensors feed Defender XDR and Sentinel
• The Purdue model levels are how you place sensors and explain segmentation to an OT team, and the IT to OT boundary is the control point that matters most

Exam tip: Passive monitoring is the point. Any answer that involves installing an agent on a PLC or actively scanning an OT network is wrong.

Microsoft Learn resource: What is Microsoft Defender for IoT? (opens in a new tab)

A baseline is the agreed secure configuration, written once and enforced everywhere, so drift becomes visible. The design question is which delivery mechanism owns which estate.

What you need to know

• Microsoft security baselines ship as pre-configured groups of settings for Windows, Microsoft Edge, Microsoft 365 Apps and Defender for Endpoint, based on Microsoft's recommendations
• Intune security baselines deliver them to enrolled devices, and Intune reports per-setting compliance and conflicts between profiles
• The Security Compliance Toolkit and Group Policy deliver baselines to domain-joined machines that Intune does not manage
• Azure Machine Configuration (formerly guest configuration) audits and enforces in-guest settings on Azure and Arc-enabled machines through Azure Policy
• Defender for Cloud assesses machines against the MCSB compute baseline and raises recommendations for the settings that fail
• CIS and STIG benchmarks are the external baselines you map to when a regulator names one, and Azure Marketplace offers hardened images built to them

Exam tip: Assign a baseline, then measure against it. A design with no reporting mechanism cannot answer whether the baseline is actually applied.

Microsoft Learn resource: Learn about Intune security baselines for Windows devices (opens in a new tab)

A shared local administrator password is the single most reliable lateral movement path in a Windows estate. Windows LAPS removes it by giving every machine a different password that rotates automatically, and storing it somewhere only authorised people can read.

What you need to know

• Windows LAPS is built into supported versions of Windows and Windows Server, so it needs no separate client install, unlike the legacy LAPS product
• It can store passwords in Microsoft Entra ID or in Active Directory, which is the main design decision: Entra ID suits cloud-managed and Entra-joined devices, AD suits domain-joined estates
• Passwords rotate on a schedule, and post-authentication actions rotate the password automatically after an authorised use, which shortens the window a retrieved password is valid for
• Retrieval is permissioned: in Microsoft Entra ID it is a directory role and can be audited, and in Active Directory it is a delegated read on the confidential attribute
• Password encryption in Active Directory requires a Windows Server 2016 domain functional level or higher, so evaluate the domain before promising it
• Retrieval events are auditable, which is what turns LAPS from a password tool into an accountable break-glass mechanism

Exam tip: Where the password is stored is the exam's question. Entra-joined and Intune-managed devices point to Microsoft Entra ID; domain-joined servers point to Active Directory.

Microsoft Learn resource: What is Windows LAPS? (opens in a new tab)

Baselines for services are the configuration you require before a service is allowed in production. Microsoft publishes them per Azure service as MCSB service baselines, and the requirement set changes with the service model.

What you need to know

• Azure security baselines for services map MCSB controls onto one named service, saying which controls apply, which do not and how to implement each, which is the document a design points to
• For SaaS, the baseline is identity and data: single sign-on with Microsoft Entra ID, automated provisioning and deprovisioning, Conditional Access, tenant restrictions, and Defender for Cloud Apps for app governance and session control
• For PaaS, the baseline is identity plus network plus data: managed identity instead of keys, private endpoints with public access disabled, TLS minimum version, diagnostic logging on, and customer-managed keys where required
• For IaaS, the baseline adds the operating system, the image, endpoint protection, patching and no public management ports
• The shared responsibility model sets where your baseline stops: you always own identity, data and configuration, and gain the OS and network as you move down the stack
• Enforce baselines with Azure Policy initiatives so a non-compliant deployment is denied or remediated rather than reviewed later

Microsoft Learn resource: Security baselines for Azure overview (opens in a new tab)

An IoT workload is more than the devices: it is the ingestion, processing, storage and management layers behind them. Requirements have to follow the data from the device through the cloud.

What you need to know

• Per-device identity and per-device authorization at the hub, so a compromised device can publish only its own telemetry and never read another device's
• Device Provisioning Service with X.509 certificates or TPM attestation for zero-touch provisioning, plus an enrolment revocation path
• TLS for all device-to-cloud and cloud-to-device traffic, and private endpoints for the hub so the back end is not reachable from the internet
• Least-privilege shared access policies or, better, Microsoft Entra ID authentication for the back-end services that read the hub
• Defender for IoT monitoring for the device estate, with alerts flowing into Defender XDR or Sentinel like any other signal
• Secure the update path end to end: Device Update for IoT Hub with signed update manifests, staged rollouts and rollback

Microsoft Learn resource: Specify security requirements for IoT workloads (opens in a new tab)

Web workloads are the internet-facing surface, so the requirements are about what reaches the application, what the application trusts, and what it stores. Layer them rather than relying on one control.

What you need to know

• Terminate at an edge with Azure Front Door or Application Gateway, both of which can carry Azure Web Application Firewall with the OWASP managed rule set and bot protection
• Azure DDoS Protection for network-layer volumetric attacks, with WAF covering the application layer; they are different layers and a design usually needs both
• TLS 1.2 as a minimum with modern cipher suites, HTTP to HTTPS redirection, HSTS, and certificates managed in Key Vault with automatic renewal
• Restrict the origin so it accepts traffic only from the edge, using private endpoints, service tags or an access restriction, otherwise the WAF is trivially bypassed
• Authenticate with Microsoft Entra ID rather than application-local accounts, use managed identity for back-end access, and keep no secrets in configuration
• Defender for App Service and Defender for APIs give runtime detection, and API Management adds throttling, validation and subscription keys in front of APIs

Exam tip: Front Door is global and suits multi-region and CDN scenarios; Application Gateway is regional and suits a single-region, in-VNet deployment. The WAF is available with both.

Microsoft Learn resource: What is Azure Web Application Firewall? (opens in a new tab)

Container security starts before anything runs: what is in the image, where it came from, and whether the running container can do more than it needs. Requirements attach to the supply chain as much as to the runtime.

What you need to know

• Build from trusted, minimal base images, pin versions rather than using latest, and rebuild to patch rather than updating inside a running container
• Scan images in the registry and in the pipeline, and fail the build on a severity threshold rather than reporting and shipping anyway
• Use a private registry such as Azure Container Registry with Microsoft Entra ID authentication, private endpoints, and content trust or image signing so only approved images deploy
• Run as a non-root user, with a read-only root filesystem, no privileged containers, and dropped Linux capabilities
• Keep secrets out of images and environment variables: mount them from Key Vault with a workload identity instead
• Defender for Containers covers registry image scanning, runtime threat detection through the Defender sensor, and container posture recommendations

Microsoft Learn resource: Introduction to Microsoft Defender for Containers (opens in a new tab)

The orchestrator is a control plane, so it needs the same treatment as any other control plane: authenticated access, least privilege, network isolation and audit. For Azure Kubernetes Service, most of the requirements have a named feature.

What you need to know

• Authenticate with Microsoft Entra ID integration and authorize with Kubernetes RBAC or Azure RBAC for Kubernetes, so cluster access follows the same identity lifecycle as everything else, and disable local accounts
• Use a private cluster so the API server has no public endpoint, or restrict authorized IP ranges where a private cluster is not possible
• Use workload identity so pods get Microsoft Entra tokens without stored secrets, rather than a shared cluster service principal
• Enforce policy in the cluster with Azure Policy for Kubernetes, which uses Gatekeeper and OPA to deny non-compliant workloads, for example privileged pods or images from unapproved registries
• Apply network policies for pod-to-pod segmentation, and keep node pools on private subnets with egress control through Azure Firewall
• Keep the cluster and node images patched with automatic upgrade channels and node image upgrades, and enable the Defender sensor for runtime detection

Exam tip: Azure Policy for Kubernetes is the admission control answer. A requirement that a non-compliant workload must never be scheduled needs a deny policy, not a recommendation.

Microsoft Learn resource: Security concepts for applications and clusters in Azure Kubernetes Service (AKS) (opens in a new tab)

AI services take the same controls as any other PaaS service, plus controls specific to the model and the prompt. Evaluate both layers, because a perfectly networked AI endpoint can still leak data through its responses.

What you need to know

• Identity first: Microsoft Entra ID authentication with managed identities instead of API keys, and Azure RBAC roles scoped to the resource; if keys must exist, keep them in Key Vault and rotate them
• Network: private endpoints with public network access disabled, and a custom subdomain, which is a prerequisite for Entra ID authentication and private endpoints on Azure AI services
• Model layer: content filters, prompt shields against jailbreak and indirect prompt injection, and abuse monitoring, configured as part of the deployment rather than added later
• Grounding data is the real exposure: the security of a retrieval-augmented application is the security of the index and the permissions behind it
• Defender for Cloud supplies AI security posture management for discovery and recommendations, and AI threat protection for runtime detections
• Microsoft Purview covers auditing, classification and data security posture for prompts and responses, including through the Purview SDK for custom AI applications

Exam tip: Managed identity with a custom subdomain and a private endpoint is the expected baseline. An answer that keeps a regenerated API key is weaker, not merely different.

Microsoft Learn resource: Security for Foundry Tools (opens in a new tab)

Evaluating a network design means checking segmentation, the ingress and egress paths, and whether anything is reachable that should not be. Microsoft's reference patterns give you the yardstick.

What you need to know

• Hub and spoke with a shared services hub, or Azure Virtual WAN for a global estate, is the expected topology, with the firewall in the hub and forced tunnelling of spoke egress through it
• Deny by default and allow by exception, with service tags and application security groups instead of hard-coded address lists, so the rules stay readable as the estate grows
• Public IP addresses are the finding to look for in an evaluation: on management interfaces, on storage accounts, on database servers and on Kubernetes API servers
• Network is a layer of the design, not the trust boundary: under Zero Trust, being on the network grants nothing on its own
• NSG flow logs and traffic analytics, plus Azure Firewall logs into a central workspace, are how you prove what the design actually permits

Microsoft Learn resource: Azure best practices for network security (opens in a new tab)

Microsoft Entra Internet Access is the secure web gateway half of Microsoft's Security Service Edge, and Global Secure Access is the umbrella term for it plus Microsoft Entra Private Access. Its advantage over a traditional gateway is that policy is written against identity.

What you need to know

• It is an identity-centric secure web gateway for SaaS and general internet traffic, enforced at Microsoft's network edge rather than on the device
• Web content filtering works on web categories and fully qualified domain names; for unencrypted HTTP it matches on the URL, and for TLS traffic it matches on the Server Name Indication
• Filtering policies group into security profiles, and a security profile is linked to a Conditional Access policy, which is how user, device, location and risk conditions reach network filtering
• The Internet Access licence adds TLS inspection, threat intelligence, data loss prevention on network traffic, prompt injection protection and shadow AI discovery
• Traffic is acquired either by the Global Secure Access client on the device or from a remote network such as a branch, through the internet access forwarding profile
• Traffic logs and dashboards give per-user visibility of destinations and the policy that applied, which a device-based filter cannot do for unmanaged networks

Exam tip: Universal Conditional Access for any internet destination, even applications not federated with Microsoft Entra ID, is the capability that separates this from an ordinary web filter.

Microsoft Learn resource: Learn about Microsoft Entra Internet Access for all apps (opens in a new tab)

Microsoft Entra Internet Access for Microsoft services uses the Microsoft traffic forwarding profile to route traffic to Microsoft 365 and other Microsoft services through Microsoft's own edge. The security value is the signals that come back, not just the path.

What you need to know

• Compliant Network check is a Conditional Access condition satisfied only when the user's traffic arrives through Global Secure Access, which proves the session came through your enforced path without maintaining IP allow lists
• Universal Tenant Restrictions (tenant restrictions v2) block sign-in to tenants you have not approved and stop anonymous access to Microsoft services, which is the cross-tenant data exfiltration control
• Tenant restrictions v2 enforced at the network edge cover the case a header-based or proxy-based implementation misses, including personal accounts on managed devices
• Source IP restoration puts the user's original IP back into the Microsoft Entra ID sign-in logs, so location-based policies and detections stay accurate behind the service
• The Microsoft traffic forwarding profile works with Microsoft Entra ID P1 or P2; the internet access and private access profiles need their own licences, which are included in Microsoft Entra Suite
• Cross-tenant access settings still govern which external tenants your users may reach and which of their claims you trust; tenant restrictions enforce it on the traffic

Exam tip: If a scenario wants to stop users signing in to an unapproved tenant from a corporate device, the answer is Universal Tenant Restrictions, not a Conditional Access location condition.

Microsoft Learn resource: What is Global Secure Access? (opens in a new tab)

Microsoft Entra Private Access gives per-application access to private resources without a VPN, which is Zero Trust network access in practice. Evaluating it means comparing it with the VPN it replaces on granularity and on what a compromised device can reach.

What you need to know

• It builds on Microsoft Entra application proxy and extends it to any private resource, port and protocol, including TCP and UDP applications rather than web only
• Quick Access publishes a primary group of fully qualified domain names and IP ranges, and a Global Secure Access app publishes a specific subset for per-app access, which is the more granular design
• Access is governed by Conditional Access per application, so MFA, device compliance and risk conditions apply to a private application the way they do to a SaaS one
• Private network connectors sit beside the resources and make outbound connections only, so there is no inbound firewall rule and no public listener
• A VPN grants network reach and then relies on internal controls; Private Access grants one application, which shrinks what a compromised endpoint can move to
• Extras that matter in an evaluation: private DNS name resolution, Kerberos single sign-on for legacy Windows applications, and application discovery to find what people actually use before you publish

Exam tip: The exam's phrase for the benefit is per-app access. Any answer that gives broad network reach, including a conditional VPN, is the weaker design.

Microsoft Learn resource: Learn about Microsoft Entra Private Access (opens in a new tab)

Evaluating productivity workloads means putting a number on a posture that is otherwise a matter of opinion. Microsoft Secure Score is the headline metric, and several supporting metrics answer questions it does not.

What you need to know

• Microsoft Secure Score covers identity, devices, apps and data across Microsoft 365, and each improvement action carries points, an implementation cost and a user impact note
• Score history and the comparison against similar organizations are what make it a metric rather than a checklist, because the trend is the argument you take to leadership
• Identity Secure Score in the Microsoft Entra admin center is the identity-specific view, and it is the one to cite for authentication and privileged access posture
• Compliance Manager's compliance score answers a different question: alignment with a regulation, not hardening
• Supporting metrics worth naming: MFA registration and coverage, legacy authentication usage, unmanaged device sign-ins, external sharing volume, and the count of standing privileged assignments
• Treat risk-accepted improvement actions as a reporting category, not as a way to inflate the score: they remove points and leave a documented decision

Exam tip: Secure Score measures hardening. Compliance Manager measures regulatory alignment. A question about an audit wants the second one.

Microsoft Learn resource: Microsoft Secure Score (opens in a new tab)

These two cover the two ways data leaves or attackers arrive in a productivity estate: email and collaboration on one side, and SaaS applications on the other. Know what each plan adds.

Microsoft Defender for Office 365: Plan 1 covers protection, with Safe Links, Safe Attachments, anti-phishing with impersonation protection, and real-time detections. Plan 2 adds the investigation and hunting side: Threat Explorer, automated investigation and response, attack simulation training, and campaign views. Preset security policies (Standard and Strict) apply Microsoft's recommended configuration and are the fastest defensible answer for a scenario that says the current settings are unknown.

Microsoft Defender for Cloud Apps: the cloud access security broker. Cloud Discovery finds shadow IT from firewall and proxy logs or from Defender for Endpoint, and the Cloud App Catalog risk-scores what it finds. App connectors give API-level visibility and control over sanctioned apps, and app governance covers OAuth applications and their consented permissions. Conditional Access App Control proxies a session so you can block download, restrict cut and paste, or apply a label in real time.

What ties them together: both feed Defender XDR incidents, so a phishing email, a token theft and an unusual SaaS download correlate into one case rather than three alerts.

Exam tip: A scenario about risky OAuth applications consented by users is app governance in Defender for Cloud Apps, not a Conditional Access policy.

Microsoft Learn resource: Microsoft Defender for Office 365 overview (opens in a new tab)

Intune is where device trust is established, and device trust is what Conditional Access consumes. Evaluating it means checking that the policies exist, that they are enforced, and that non-compliance actually costs the user access.

What you need to know

• Compliance policies define healthy, and Conditional Access turns compliance into an access decision; without the Conditional Access policy, compliance reporting changes nothing
• Configuration profiles and security baselines carry the hardening settings, and settings catalog profiles are the current way to build them
• App protection policies protect organizational data in apps on unmanaged devices, which is the BYOD answer
• Endpoint privilege management removes standing local administrator rights while still allowing approved elevation, which closes a long-standing gap
• Intune manages Windows, macOS, iOS, Android and Linux, so evaluate coverage per platform rather than assuming one policy set covers the estate
• Reporting to check: enrolled versus known devices, compliance rate by policy, profile conflicts, and devices that have not checked in

Exam tip: A compliance policy with no matching Conditional Access policy is the classic evaluation finding. It reports, it does not protect.

Microsoft Learn resource: Device compliance policies in Microsoft Intune (opens in a new tab)

Data security in Microsoft 365 is a chain: find the data, label it, act on the label, and watch what people do with it. A gap anywhere in that chain makes the rest ornamental.

What you need to know

• Discovery and classification: sensitive information types, trainable classifiers, exact data match and named entities find the data; content explorer and activity explorer show where it is and what is happening to it
• Sensitivity labels apply encryption, content marking, container settings for sites and Teams, and rights that travel with the file outside the tenant; auto-labelling applies them at scale without the user
• Data loss prevention acts at the moment of an action across Exchange, SharePoint, OneDrive, Teams, endpoints, Defender for Cloud Apps and the browser, with policy tips, override with justification, or block
• Data lifecycle and records management handle retention and deletion, including disposition review and the immutable record of disposal
• Data Security Posture Management reports where sensitive data is exposed and where policy coverage has gaps, which is the evaluation view
• Evaluate coverage honestly: labels published to a pilot group, DLP in test mode, endpoints not onboarded, and unlabelled legacy content are the usual holes

Exam tip: The order matters. Classification comes before protection, because a label you cannot apply automatically only protects what someone remembered to mark.

Microsoft Learn resource: Learn about sensitivity labels (opens in a new tab)

Copilot inherits the permissions of the user asking, so it does not create new access, it reveals the access that was already there. That single fact drives every control in this skill.

What you need to know

• Copilot respects existing permissions, sensitivity labels and DLP: a user cannot get content through Copilot that they could not open directly, and a response inherits the most restrictive label of its sources
• Your tenant data is not used to train the foundation models, and prompts and responses stay within the Microsoft 365 service boundary
• Oversharing is the risk to design against, not exfiltration by the model: SharePoint Advanced Management, site access reviews, restricted content discovery and the removal of broad sharing links are the levers
• Purview DSPM for AI reports Copilot and agent usage, sensitive interactions and policy gaps, with data risk assessments that name the oversharing
• Copilot interactions are recorded in Purview Audit, and are discoverable through eDiscovery and covered by retention and communication compliance policies
• DLP policies can stop labelled content being used to ground a Copilot response, and Insider Risk Management has a risky AI template

Exam tip: When a scenario says a user saw something in Copilot that they should not have, the finding is a permissions or oversharing problem, and the answer is a SharePoint and Purview control, not a Copilot setting.

Microsoft Learn resource: Microsoft Purview data security and compliance protections for generative AI apps (opens in a new tab)

Before you can secure a portfolio you have to know what is in it, who owns it, what it holds and how exposed it is. Most organizations discover during this exercise that the inventory is incomplete, which is itself the first finding.

What you need to know

• Build the inventory from several sources, because none is complete on its own: Microsoft Entra ID enterprise applications and app registrations, Defender for Cloud Apps discovery, Defender EASM for internet-facing assets, and the CMDB
• Rank applications by business criticality and data sensitivity first, then by exposure, so remediation effort follows risk rather than discovery order
• For each application record the authentication method, whether it uses modern authentication, its data classification, its internet exposure, its owner and its support status
• Legacy authentication, applications with no named owner and applications past end of support are the three findings that appear in nearly every portfolio review
• Microsoft Entra ID reporting shows which applications still use legacy protocols, and app governance shows over-permissioned OAuth applications and unused consents
• Output a prioritized remediation plan, not a list: which applications get modern authentication first, which get retired, and which get a compensating control

Microsoft Learn resource: What is app governance in Microsoft Defender for Cloud Apps? (opens in a new tab)

Threat modeling is a structured argument about how an application could be attacked, done at design time when a change is still cheap. The exam expects the method and the vocabulary, not a tool demonstration.

The four threat modeling questions:

1. What are we building? A data flow diagram with processes, data stores, data flows, external entities and trust boundaries
2. What can go wrong? Threats enumerated against each element, commonly with STRIDE
3. What are we going to do about it? A mitigation per threat, recorded as a work item with an owner
4. Did we do a good enough job? Validation that the mitigations were built and tested

• STRIDE is Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege, and each maps to a property: authentication, integrity, non-repudiation, confidentiality, availability and authorization
• Trust boundaries are where most real threats live, because that is where data crosses from one level of trust to another
• The Microsoft Threat Modeling Tool draws the diagram and generates a threat list from the stencil types you use
• Threat modeling belongs in the design phase of the SDL and is repeated when the architecture changes, not once at project start
• Rank the findings so the output is a prioritized backlog: a threat with no mitigation on a business-critical application outranks a theoretical one elsewhere

Exam tip: Match the STRIDE letter to the control. Elevation of privilege maps to authorization, repudiation maps to logging and non-repudiation, and information disclosure maps to encryption and access control.

Microsoft Learn resource: Microsoft Threat Modeling Tool (opens in a new tab)

A lifecycle strategy means security is present at every phase rather than as a test before release. Microsoft's Security Development Lifecycle is the reference, and it runs from training to incident response.

What you need to know

• The lifecycle phases are training and requirements, design and threat modeling, implementation with secure coding and approved components, verification with static and dynamic testing, release with a final review and a response plan, and operation with monitoring and incident response
• Security requirements and a bug bar are defined at the start, so what counts as a blocking defect is agreed before anyone argues about a specific one
• Shift left, but do not shift everything left: runtime protection such as WAF, Defender for App Service and Defender for APIs covers what testing cannot
• Feed production findings back to the owning repository so the same class of defect does not ship again, which is the loop that makes the lifecycle a cycle
• Include third-party and open-source components: software composition analysis, a software bill of materials, and a defined response when a dependency has a vulnerability
• Include retirement: decommissioning an application means removing its identities, secrets, DNS records and data, and forgotten applications are an attack surface

Microsoft Learn resource: Develop secure applications on Azure (opens in a new tab)

This skill is about the process rather than the product: what developers are required to do, and what the platform enforces so the requirement is not optional. Standards that rely on remembering are not standards.

What you need to know

• Branch protection with required reviews, required status checks and signed commits, so nothing reaches the main branch unreviewed
• Secret scanning with push protection blocks a credential at commit time, which is better than detecting it after it is in the history, and code scanning with CodeQL finds vulnerable patterns
• Dependency management: an approved internal feed, automated dependency updates, and a policy for how fast a vulnerable dependency must be replaced
• Separate the build and deploy identities from developer identities, use workload identity federation for pipelines, and keep production deployment behind an approval
• Infrastructure as code goes through the same review and scanning as application code, because a misconfigured template is a production vulnerability
• Defender for Cloud DevOps security connects Azure DevOps and GitHub so repository and pipeline findings appear beside cloud findings, with the owning repository named

Exam tip: A control that runs in the pipeline and can fail the build beats a control that produces a report. When both are offered, pick the enforcing one.

Microsoft Learn resource: Overview of Microsoft Defender for Cloud DevOps security (opens in a new tab)

This is the translation skill for applications: a requirement sentence goes in, a named Microsoft capability comes out. Practising the mapping is the fastest way to answer this group's scenario questions.

What you need to know

• The mapping fails most often on identity: a design that reaches for a key or a connection string when a managed identity exists is the answer to avoid
• Some requirements need two technologies at different layers, for example DDoS Protection at the network layer plus WAF at the application layer
• Say what the control does not cover: a WAF does not fix a broken authorization check inside the application

Microsoft Learn resource: Azure security best practices and patterns (opens in a new tab)

A workload identity belongs to an application, a service or a script rather than a person, and the design goal is that none of them holds a long-lived secret. Microsoft gives you three options and a governance layer.

What you need to know

• Microsoft Entra Workload ID adds governance for these identities: Conditional Access for workload identities, risk detection through Identity Protection, and access reviews for their privileged role assignments
• Grant application permissions to the narrowest scope that works, prefer delegated over application permissions where a user is present, and review consented Microsoft Graph permissions
• Assign Azure RBAC at the resource or resource group scope, and use PIM for Azure resource roles when a workload needs elevation only occasionally
• Monitor for orphaned identities: a service principal for a decommissioned application with standing permissions is a common finding
• Federated credentials are scoped by issuer, subject and audience, which is what stops another repository or cluster using the same trust

Exam tip: Workload identity federation is the answer whenever the scenario involves a pipeline or a non-Azure workload and mentions stored secrets or rotation burden.

Microsoft Learn resource: What are workload identities? (opens in a new tab)

APIs carry the data, and they are frequently more exposed than the applications in front of them. The design puts a gateway between the consumer and the back end, then protects the back end from everything that is not the gateway.

What you need to know

• Azure API Management fronts the API with subscription keys, OAuth 2.0 and JWT validation, rate limiting and quotas, request and response validation against the schema, IP filtering and response masking
• Validation policies matter as much as authentication: validate the JWT, validate the request body against the OpenAPI definition, and strip headers that reveal back-end detail
• Protect the back end so it accepts only the gateway: private endpoints, a VNet-integrated API Management instance, or mutual TLS between gateway and back end
• Put a WAF in front of the gateway with Application Gateway or Front Door for the layer 7 attack surface, since API Management is not a WAF
• Defender for APIs inventories APIs published in API Management, flags those exposing sensitive data, unauthenticated or unused APIs, and detects runtime attacks
• Version and deprecate deliberately: an old version left running is the one that still has the vulnerability

Exam tip: API Management handles authentication, throttling and validation. It does not replace a WAF, and the exam tests whether you know you need both.

Microsoft Learn resource: What is Azure API Management? (opens in a new tab)

The WAF inspects HTTP and HTTPS traffic and blocks the common web attacks before they reach the application. The design decisions are where it runs, which rules it uses, and how you get from detection to prevention without breaking the site.

What you need to know

• WAF runs on Azure Front Door (global, at the edge, for multi-region and CDN scenarios) or Application Gateway (regional, inside a virtual network, for a single-region back end)
• The Default Rule Set is Microsoft's managed rule set built on the OWASP Core Rule Set, and it is updated by Microsoft rather than by you
• The Bot Manager managed rule set classifies good, bad and unknown bots so you can block the bad ones without blocking search engines
• Custom rules run before managed rules and handle rate limiting, geo-filtering, IP allow and deny lists, and application-specific matches
• Start in Detection mode, review the logs, write exclusions for the legitimate traffic that trips a rule, then switch to Prevention mode; going straight to prevention is how you take an application down
• WAF only helps if the origin cannot be bypassed: lock the back end to the WAF path, otherwise the protection is optional for an attacker

Exam tip: Detection mode logs and does nothing else. If the requirement is to block, the policy has to be in Prevention mode, and the exam likes that distinction.

Microsoft Learn resource: What is Azure Web Application Firewall? (opens in a new tab)

You cannot protect data you cannot find, so discovery and classification are the first step of every data design. Microsoft splits the job between Purview for data in Microsoft 365 and connected sources, and Defender for Cloud for data in Azure resources.

What you need to know

• Sensitive information types match patterns with regular expressions, keywords, checksums and confidence levels, and there are hundreds built in for identifiers such as credit cards and national numbers
• Trainable classifiers recognise content by category rather than by pattern, which is how you find things like source code, resumes or contracts; they can be pre-trained or trained on your own samples
• Exact data match matches against a hashed copy of your own data, which removes the false positives a generic pattern produces on, for example, customer numbers
• Content explorer shows where classified content currently sits, and activity explorer shows what has been done with it
• Defender for Cloud data-aware security posture discovers sensitive data in Azure storage accounts and databases without an agent, and feeds it into attack path analysis
• Evaluate on coverage and accuracy: which repositories are actually scanned, what proportion of content is classified, and how many matches are false

Exam tip: Exact data match is the answer when a scenario complains about false positives from a generic sensitive information type.

Microsoft Learn resource: Classifiers overview (opens in a new tab)

Threats to data are not equal, and the exam asks you to order the work. Prioritize by what the data is worth, how exposed it is, and how likely the threat path is to be used.

What you need to know

• The threat classes to name are external compromise, malicious insiders, accidental oversharing, ransomware and destructive attack, and third-party or supply chain exposure
• Accidental oversharing is the highest-volume threat in most Microsoft 365 estates, and it is also the cheapest to reduce, which usually puts it first
• Rank by sensitivity and exposure together: sensitive data reachable from the internet or shared with anyone links outranks sensitive data in a tightly permissioned site
• Defender for Cloud data-aware posture and Security Exposure Management attack paths do this ranking for cloud data, by showing which sensitive stores sit at the end of a real attack path
• Availability is a data threat too: ransomware and deletion are mitigated with immutable backup and retention, not with access controls
• Sequence the mitigations: discover and classify, fix the worst exposure, apply protection that travels with the data, then monitor and respond

Microsoft Learn resource: Overview - About data security posture management (opens in a new tab)

Encryption questions on this exam are almost always about key ownership rather than about algorithms. Know who holds the key in each option and what that buys.

What you need to know

• Azure encrypts data at rest by default on storage, managed disks, SQL and most PaaS services, so the design question is whether the default key custody is acceptable
• Customer-managed keys give you revocation: deleting or disabling the key makes the data unreadable, which is powerful and dangerous, so purge protection and soft delete are prerequisites
• Infrastructure encryption adds a second, platform-managed layer beneath your layer, and on storage it must be enabled at account creation
• In transit, require TLS 1.2 as a minimum, enforce HTTPS-only on storage and web services, and use encryption in transit between Azure services where the option exists
• Azure Managed HSM is the answer when a regulator requires a single-tenant, FIPS 140 Level 3 validated hardware security module
• Confidential computing protects data in use, which is the third state the exam occasionally names alongside at rest and in transit

Exam tip: Customer-managed keys are about control and revocation, not about stronger cryptography. Do not recommend them for a scenario that only asks that data be encrypted at rest.

Microsoft Learn resource: Azure Data Encryption at rest (opens in a new tab)

An AI application is a new way to reach old data, so the security of the workload is mostly the security of what it is grounded on. Design the data side first and the model side second.

What you need to know

• Permissions are the control: a retrieval-augmented application returns what the calling identity may see, so fix oversharing in the source before connecting it
• Classify and label the grounding data, and use DLP to keep labelled content out of prompts and responses where policy requires it
• Keep the index and the vector store as sensitive as the source: they hold extracted content, so they need the same access control, private networking and encryption
• Purview DSPM for AI gives visibility into prompts, responses and sensitive interactions, with data risk assessments for oversharing; the Purview SDK extends that to custom AI applications
• Defender for Cloud AI security posture management discovers AI workloads and their dependencies, and AI threat protection detects jailbreak and prompt injection attempts at runtime
• Model-layer controls cover what data controls cannot: content filters, prompt shields against direct and indirect prompt injection, and abuse monitoring

Exam tip: Prompt injection is a model-layer threat answered by prompt shields and grounding hygiene. Data leakage is an identity and permissions threat answered by Purview and access controls. The exam pairs each threat with its layer.

Microsoft Learn resource: Overview - AI security posture management (opens in a new tab)

Data platform security follows the same four layers every time: identity, network, data protection and monitoring. What changes per service is the name of the feature.

What you need to know

• Azure SQL Database: Microsoft Entra ID authentication with an Entra admin instead of SQL logins, private endpoint with public access disabled, Transparent Data Encryption with a customer-managed key where required, Always Encrypted for column-level protection from the database administrator, dynamic data masking, row-level security, and auditing to a workspace
• Azure Synapse Analytics: the same Entra ID and private endpoint pattern, plus a managed virtual network with data exfiltration protection, workspace-level firewall rules, and column-level and row-level security in the dedicated SQL pool
• Azure Cosmos DB: Microsoft Entra ID authentication with RBAC instead of account keys, disabling key-based authentication where possible, private endpoints, customer-managed keys, and Always Encrypted for client-side column protection
• Disable local and key-based authentication wherever the service supports it, so identity is the only way in and every access is attributable
• Classify the data in the platform: SQL data discovery and classification labels columns, which then flows into auditing and Defender findings
• Enable Microsoft Defender for Databases on all of them for SQL injection, anomalous access and brute-force detections

Exam tip: Always Encrypted is the answer when the requirement is that database administrators must not see the data. Transparent Data Encryption does not protect against a privileged user inside the database.

Microsoft Learn resource: An overview of Azure SQL Database and SQL Managed Instance security capabilities (opens in a new tab)

Storage accounts hold a lot of the sensitive data in an Azure estate, and they are the resource most often left open. The design removes the shared key, removes the public path, and adds detection.

What you need to know

• Authorize with Microsoft Entra ID and Azure RBAC, and disable shared key authorization so account keys cannot be used at all; this is the single biggest improvement in most storage designs
• If a shared access signature is unavoidable, prefer a user delegation SAS signed with Entra ID credentials, keep it short-lived and narrowly scoped, and use a stored access policy so it can be revoked
• Disable public blob access at the account level, use a private endpoint, and set the network default action to deny with explicit exceptions
• Encryption at rest is on by default; add a customer-managed key for control, and enable infrastructure encryption at account creation when two layers are required
• Protect against deletion with soft delete for blobs and containers, versioning, and immutable storage with time-based or legal hold policies for data that must not change
• Turn on Defender for Storage for malware scanning on upload, sensitive data threat detection and activity anomaly alerts, and log data plane operations with diagnostic settings

Exam tip: Disabling shared key authorization and using a private endpoint are the two answers that appear most often. A firewall rule allowing a range of public IP addresses is the weaker option.

Microsoft Learn resource: Security recommendations for Blob storage (opens in a new tab)

These two plans are the detection layer over the data platform. Posture controls stop the obvious mistakes; these tell you when something is happening anyway.

What you need to know

• Defender for Storage detects unusual access patterns, access from suspicious IP addresses and Tor exit nodes, anomalous extraction, and publicly accessible containers; it also adds on-upload malware scanning and sensitive data threat detection
• Malware scanning is near real-time on upload, can be capped per account per month, and can be configured to move or delete an infected blob through an event-driven response
• Sensitive data threat detection uses the data sensitivity discovered by Defender CSPM to raise the severity of alerts on storage that holds sensitive data
• Defender for Databases covers Azure SQL Database, SQL Server on machines (including Arc-enabled), open-source relational databases and Azure Cosmos DB
• Its detections include SQL injection attempts, brute force, access from an unusual location or principal, and suspicious use of database privileges
• Pair detection with response: an automation rule or playbook that isolates or revokes on a high-confidence alert is what makes the detection useful at three in the morning

Exam tip: Malware scanning of uploaded files is Defender for Storage, not Defender for Endpoint and not a WAF. It is a common distractor pairing.

Microsoft Learn resource: What is Microsoft Defender for Storage (opens in a new tab)