SC-500 sample questions — 25 answered and explained

Named locations: trusted IP ranges reused across Conditional Access policies.

Named locations are defined once and then referenced by any Conditional Access policy. For known static office egress IPs, an IP ranges location marked as trusted is the right object: policies can exclude it, and Microsoft Entra ID Protection takes trusted locations into account when it scores sign-in risk. A country location is too broad, a device filter is not about network origin, and the Global Secure Access compliant network depends on traffic routed through that service.

1. Identify what defines the exception: known static public IP ranges.
2. Recall that named locations are reusable objects and can be marked trusted.
3. Prefer IP ranges over countries when the requirement is specific sites.

Exam tip: Office IP ranges become a trusted IP ranges named location that every policy can reuse.

Authentication strengths: built-in strengths vs a custom strength that lists exact methods.

Two facts combine here. First, the 'Require multifactor authentication' grant accepts any MFA method, so only an authentication strength can restrict methods. Second, the built-in strengths are fixed sets: Phishing-resistant MFA contains Windows Hello for Business or platform credential, Passkeys (FIDO2) and multifactor certificate-based authentication, and Passwordless MFA adds Authenticator phone sign-in. The built-in Phishing-resistant MFA strength is the tempting choice, but it also lets administrators in with certificate-based authentication, which the requirement excludes. Only a custom authentication strength that selects the two combinations matches.

1. Note that the requirement restricts which methods are allowed, not how often.
2. Recall that only an authentication strength can restrict methods in Conditional Access.
3. Check the built-in strengths' contents against the two allowed methods.
4. Choose a custom strength when no built-in strength matches exactly.

Exam tip: When a requirement names exact methods, build a custom authentication strength; built-in strengths include more.

Session controls: sign-in frequency vs persistent browser session vs continuous access evaluation.

The requirement is a fixed reauthentication interval on a subset of devices. Sign-in frequency is the session control that sets that interval. Persistent browser session is its near-twin, but it only decides whether a session survives closing the browser. Continuous access evaluation reacts to events rather than time.

1. Translate the requirement: reauthenticate every 4 hours.
2. Match it to the session control that sets an interval: sign-in frequency.
3. Rule out persistence and event-driven controls.

Exam tip: Sign-in frequency sets how often users reauthenticate; persistent browser session only controls browser closure.

Temporary Access Pass bootstraps passwordless onboarding.

Passwordless onboarding has a chicken-and-egg problem: registering a passkey requires a strong sign-in. A Temporary Access Pass, issued by an administrator and enabled in the Authentication methods policy, is a time-limited (optionally one-time) passcode that solves it. The other methods either rely on a password or on methods the user has not registered yet.

1. Note that the user has no password and no registered methods.
2. Recall the method designed for first sign-in and registration.
3. Rule out methods that depend on an existing credential.

Exam tip: Temporary Access Pass gets a passwordless user through first sign-in and passkey registration.

The Authentication methods policy enables methods per group for sign-in and SSPR.

Microsoft Entra ID manages authentication methods in the Authentication methods policy: each method is enabled for all users or for specific groups, and the policy applies to both sign-in and SSPR. Since 30 September 2025, methods can no longer be managed in the legacy MFA and SSPR policies. Authentication strengths and Conditional Access build on the methods that this policy enables; they cannot enable one themselves.

1. Note the two needs: per-group enablement and one place for sign-in and SSPR.
2. Recall that the Authentication methods policy is the current place to manage methods.
3. Distinguish enabling a method (methods policy) from requiring one (Conditional Access).

Exam tip: Enable methods in the Authentication methods policy; require them with Conditional Access.

Phishing-resistant passwordless methods and which are bound to a device.

Two properties must hold together. Phishing resistance rules out Authenticator phone sign-in and SMS. Portability across shared PCs rules out Windows Hello for Business, whose credential is bound to one device's TPM. Passkeys on a FIDO2 security key and passkeys in Microsoft Authenticator satisfy both.

1. Filter by phishing resistance first: passkeys, Windows Hello for Business, multifactor CBA.
2. Then filter by portability across shared workstations.
3. Windows Hello for Business fails the second filter because it is device-bound.

Exam tip: Windows Hello for Business is phishing-resistant but device-bound; passkeys on a key or phone travel with the user.

A virtual network rule references a specific subnet; deleting the subnet removes the rule, and a same-named replacement must be authorized again.

Storage firewall rules are tied to the subnet resource, not its name. When snet-api was deleted, its rule went with it, so the new subnet needs the Microsoft.Storage service endpoint and an explicit virtual network rule. Waiting doesn't help, private ranges can't be IP rules, and the trusted services exception doesn't apply to your own workloads.

1. Note that the subnet was deleted and recreated.
2. Recall that deleting a subnet removes its virtual network rule.
3. Re-enable the service endpoint on the new subnet.
4. Add the new subnet to the account's virtual network rules.

Exam tip: Recreated subnet = new subnet: re-add the service endpoint and the virtual network rule.

Storage IP rules take public IPv4 addresses (individual IPs or ranges shorter than /31) and don't apply to same-region clients; same-region Azure workloads are admitted with virtual network rules.

Two separate limits decide this. For the office, a single address must be added as an individual IP, because /31 and /32 ranges aren't supported. For the web app, the account and app are in the same region, so its requests use private Azure addresses and IP rules have no effect; the supported path is a virtual network rule for the integration subnet with the service endpoint. Private ranges can never be IP rules.

1. Handle the office: one public address, entered as an individual IP.
2. Remember /31 and /32 ranges aren't accepted.
3. Handle the web app: same region, so IP rules won't match.
4. Admit it through its integration subnet with a virtual network rule.

Exam tip: Same-region clients: virtual network rules. Single public IP: individual address, not /32.

Storage IP rules apply to the public address the account sees; private (RFC 1918) ranges are rejected.

The firewall never sees 192.168.40.0/24, because the NAT device translates it to 198.51.100.40. Private ranges are rejected in IP rules anyway. The fix is an IP rule for the public NAT address, entered as an individual IP since /32 ranges aren't supported. Virtual network rules and resource instance rules only identify Azure subnets and Azure resources.

1. Work out which address reaches the account: the NAT's public IP.
2. Recall that private ranges can't be IP rules.
3. Enter a single address as an individual IP, not /32.
4. Rule out rule types meant for Azure resources.

Exam tip: IP rules see the public egress address; add it as an individual IP.

Resource instance rules let one specific Azure resource instance through the storage firewall; RBAC still decides what its identity can do.

Network access and authorization are separate layers. A resource instance rule names the resource type and the exact instance, so only that search service gets through the firewall, and a data-plane role for its managed identity lets it read. The trusted services exception is the near-twin but is broader than one instance. IP rules don't fit same-region Azure services, and the service has no subnet in your network.

1. Note the requirement: one specific instance, no others.
2. Choose the firewall feature that names an instance: resource instance rules.
3. Remember that the firewall decides reachability and RBAC decides permission.
4. Reject the broader trusted services exception.

Exam tip: One named Azure resource through the firewall: resource instance rule + RBAC for its identity.

Trusted access takes precedence: resource instance rules and trusted service exceptions remain effective even after public network access is set to Disabled.

Microsoft documents that if you move from selected networks to Disabled, any resource instances and exceptions you configured, including the trusted services exception, remain in effect. That's why the Data Factory instance still gets through. Removing them closes the path. IP rules are the tempting near-twin, but they stop working when public access is disabled. The defaultAction mismatch only affects how Defender and Advisor report the account, and keys don't govern network access.

1. Note the order: selected networks with exceptions first, then Disabled.
2. Recall that trusted access takes the highest precedence.
3. Identify the leftover path: the resource instance rule and exception.
4. Remove them rather than changing keys or IP rules.

Exam tip: Disabling public network access doesn't clear resource instance rules or the trusted services exception.

Defender for Storage malware scanning can soft-delete malicious blobs itself; Event Grid and Logic Apps are for custom responses.

Defender for Storage offers built-in automated remediation: it soft-deletes blobs that malware scanning flags. That removes them from the container while keeping them recoverable, with nothing to build or run. An Event Grid-triggered function that quarantines blobs is a valid pattern but is custom code to maintain. Versioning keeps history but leaves the malicious blob current, and an ABAC condition only blocks reads and leaves the file in place.

1. Note the requirements: removed automatically, recoverable, least ongoing effort.
2. Recall the built-in soft delete remediation in malware scanning.
3. Rank the Event Grid function as workable but higher effort.
4. Reject options that block or version the blob without removing it.

Exam tip: No-code malware response: the built-in soft delete for malicious blobs.

Scan results arrive as blob index tags, Defender for Cloud alerts, Event Grid events and Log Analytics records; each fits a different job.

Two facts decide it. Blob index tags aren't tamper-resistant, so a user who can write tags could set the clean value; tags therefore can't be the only control. Defender for Cloud alerts fire only on malicious detections, so they can't signal a clean file. Event Grid gives near real-time results for every scan, and a function that moves clean files to a separate container gives a gate users can't spoof. Log Analytics suits audits, not instant decisions.

1. List the result channels: tags, alerts, Event Grid, Log Analytics.
2. Rule out tags for a security decision, since they can be rewritten.
3. Rule out alerts, which cover only malicious files.
4. Choose Event Grid for low latency and quarantine-by-default.

Exam tip: Gate on Event Grid scan results, not on blob index tags that tag writers can change.

Defender security for AI agents uses the Microsoft 365 connector for investigation; real-time blocking works without it, but alerting doesn't.

Blocking happens at runtime through the Copilot Studio connection, which is clearly working. The Defender documentation notes that if the Microsoft 365 connector isn't connected, real-time protection continues to block suspicious activity, but the alerts and incidents for those actions don't show in the Defender portal. Connecting the Microsoft 365 connector, with Entra ID management events and Microsoft 365 activities, fixes the SOC's view.

1. Blocking works, so the runtime connection is fine.
2. Only alerting is missing.
3. Alerts and incidents depend on the Microsoft 365 connector.
4. Connect it from Settings > Security for AI > Get started.

Exam tip: Copilot Studio real-time protection blocks without the Microsoft 365 connector, but you need the connector to get alerts and incidents.

Defender real-time protection has a built-in Default rule that audits all agents, plus custom rules that block chosen detection types for scoped agents.

The Default rule records matching activity as behaviours for all agents without stopping actions, which gives the SOC visibility. Custom rules block matching actions before they run and can be scoped to specific agents and detection types such as Secret exfiltration. Keeping the Default rule and adding a scoped custom block rule meets both requirements. Disabling the Default rule removes visibility for every other agent; Block the query is a Copilot Studio error-behavior setting, and Conditional Access acts on token issuance, not on individual runtime actions.

1. List the two needs: audit everything, block one detection for one group.
2. The Default rule already audits every agent.
3. A custom rule blocks a detection type for scoped agents.
4. Combine both rather than replacing one with the other.

Exam tip: Defender agent protection: the Default rule audits all agents; custom rules block specific detections for specific agents.

Conditional Access evaluates the token's subject; for autonomous (app-only) agents the subject is the agent identity.

With no signed-in user, the agent requests tokens with its own agent identity, and that identity is the token subject. Conditional Access therefore has to target the agent identity, or the agent identity blueprint to cover every agent created from it, under Users, agents or workload identities > Agents. Policies on the sponsor or developer only apply to their own sign-ins.

1. Identify the access pattern: no user, app-only.
2. Find the token subject: the agent identity.
3. Target that subject under Agents.
4. Use the blueprint to cover a whole class of agents.

Exam tip: Autonomous agent = agent identity is the token subject, so target the agent identity or its blueprint.

In the on-behalf-of (delegated) flow, Conditional Access evaluates policies assigned to the signed-in user, not the agent identity.

Two facts combine here. The agent acts on behalf of a signed-in user, so the OBO token's subject is the user, even though the token also identifies the calling agent. And a policy that targets an agent identity, directly or through its blueprint, doesn't cover requests made on behalf of a user. The device control must be in a policy assigned to the users (or groups) who use the agent. Agent user accounts are a separate pattern, and the risk condition doesn't change the subject.

1. Identify the pattern: the agent acts for a signed-in user (OBO).
2. In OBO the token subject is the user.
3. Agent-identity and blueprint policies don't apply to delegated tokens.
4. Assign the device policy to the users.

Exam tip: Agent acting for a user (OBO)? Conditional Access follows the user. Targeting the agent identity only covers app-only tokens.

Custom security attributes let a Conditional Access policy include or exclude agent identities by label, so new agents are covered automatically.

Microsoft's recommended pattern is a block policy for all agent identities that excludes approved agents. Excluding by a custom security attribute (for example AgentApprovalStatus) means the board only tags an agent to approve it; the policy itself never changes, and new untagged agents are blocked. Picking agents in the object picker works but requires edits, blueprint exclusion is too coarse when approval is per agent, and group-based scoping of agent users isn't supported.

1. Note the constraint: no policy edits as agents are approved.
2. Approval is per agent, not per blueprint.
3. Use a custom security attribute as the approval tag.
4. Include all agent identities, exclude by attribute, grant Block.

Exam tip: Approve agents without editing the policy: block all agent identities and exclude by a custom security attribute.

Conditional Access for agents has its own Agent risk condition, fed by ID Protection for agents.

To block risky agents, include all agent identities, target all resources, set Conditions > Agent risk to High, grant Block, and start with Enable policy set to Report-only. Microsoft recommends report-only first so you can check sign-in logs before turning the policy On. Sign-in risk is a user signal, and service principal risk applies to workload identities rather than agent identities.

1. Pick the subject: all agent identities.
2. Pick the signal: Agent risk, not user or service principal risk.
3. Grant: Block.
4. Start in Report-only, then switch to On.

Exam tip: Block risky agents: Agent risk condition + Block, rolled out in Report-only first.

Audit reports in the Regulatory compliance dashboard give access to Microsoft's own third-party audit and certification reports for its cloud services.

The auditor wants evidence about the platform, not about your resources. That is a Microsoft certification, which Defender for Cloud exposes through Audit reports. Download report, the Microsoft Actions tab and attestations all relate to your own assessment of the standard.

1. Separate the two subjects: Microsoft's platform vs your workloads.
2. The request is about the platform.
3. Microsoft certifications are under Audit reports.
4. Download the ISO report from the relevant tab.

Exam tip: Need Microsoft's certificate for Azure? Use Audit reports, not Download report.

Regulatory compliance controls contain automated assessments (evaluated from resource data) and manual assessments, which the customer attests to with supporting evidence.

A process control such as an incident response plan can't be evaluated from resource configuration. Defender for Cloud therefore lists it as a manual assessment, and you record compliance by attesting for the relevant subscriptions and attaching evidence. Policy exemptions, custom recommendations and the Microsoft Actions tab don't capture customer evidence.

1. Recognise a process control that can't be checked automatically.
2. Find it under Manual attestation and evidence.
3. Select the subscription and choose Attest.
4. Enter the details and attach the plan and test results.

Exam tip: Process controls are proven by manual attestation with evidence in the Regulatory compliance dashboard.

Regulatory compliance data comes from policy compliance state. Reader can read that data; Security Reader, despite its name, can't.

The analyst sees other Defender for Cloud data, so the gap is specific to policy compliance data. Defender for Cloud documents that Reader has access to that data and Security Reader doesn't, so Reader is the least-privilege fix. Security Admin grants write access to security settings. Managing standards needs a role that can write policy (Owner or Policy Contributor, or Resource Policy Contributor plus Security Admin), which is more than viewing the dashboard requires. Security Assessment Contributor writes assessments, and Monitoring Reader covers monitoring data.

1. Note what's missing: only regulatory compliance data.
2. Recall that this data is policy compliance state.
3. Security Reader can't read it; Reader can.
4. Separate viewing (Reader) from managing standards (a role that can write policy).

Exam tip: Security Reader doesn't see regulatory compliance data; add Reader for read-only access.

Default standards per cloud: Azure gets MCSB; AWS gets MCSB plus AWS Foundational Security Best Practices; GCP gets MCSB plus GCP Default. Other standards are added on demand.

When a connector is created, Defender for Cloud assigns MCSB and the cloud's own default standard. For AWS that is AWS Foundational Security Best Practices. CIS AWS Foundations and PCI DSS are available for AWS too (the CIS GCP benchmark isn't), but they only appear after you assign them.

1. Recall that MCSB is the default everywhere.
2. Recall the cloud-specific default: AWS FSBP for AWS.
3. Treat every other framework as opt-in.
4. Assign optional standards from the connector's security policies.

Exam tip: Every connected cloud gets MCSB; AWS also gets AWS Foundational Security Best Practices by default.

Most Defender plans are subscription-level. Defender for Storage, Defender for SQL, Defender for open-source relational databases and Defender for Servers Plan 1 can also be enabled per resource; Plan 2 can only be disabled per resource.

Only some plans support resource-level enablement. Defender for Storage and Defender for Servers Plan 1 do. Plan 2 is the classic trap: you can exclude a server from it, but you can't switch it on for one server. Defender for Key Vault and App Service apply to the whole subscription.

1. Recall the default: plans are enabled per subscription.
2. List the exceptions: Storage, SQL, open-source DBs, Servers Plan 1.
3. Remember Plan 2 can be disabled, not enabled, per resource.
4. Choose Storage and Servers Plan 1.

Exam tip: Resource-level enablement: Storage, SQL, open-source DBs and Servers Plan 1; Plan 2 can only be turned off per resource.

Defender for Servers Plan 2 adds agentless malware scanning and premium Defender Vulnerability Management. Plan 2 can be enabled only for a subscription, but it can be disabled per resource.

Two facts decide this. First, only Plan 2 has the required features (Defender CSPM's agentless scanning has no malware scanning, and Plan 1 has no agentless scanning). Second, Plan 2 can't be switched on for single VMs, but it can be switched off for them. So you enable Plan 2 for Prod and disable it on the VMs outside RG-Payments, which keeps them unbilled without moving them.

1. Map the features to a plan: malware scanning and premium MDVM need Plan 2.
2. Check scope rules: Plan 2 can't be enabled per resource.
3. Check the reverse: Plan 2 can be disabled per resource.
4. Enable at the subscription and disable on the excluded VMs.

Exam tip: Plan 2 is subscription-on, resource-off; Plan 1 is the only Defender for Servers plan you can turn on for a single VM.