Security Foundations

SC-500 is written for a security engineer, not an architect and not an analyst. The verbs in the skills measured are telling: implement, configure, enable, deploy, manage. You are not asked to justify a design; you are asked to know which blade, which role, which effect and which order. Almost every wrong answer on this exam is a control that would work but sits at the wrong scope, in the wrong portal, or one layer too late in the request path.

Zero Trust in three sentences

Zero Trust is not an exam objective by name, but it is the organising idea behind almost every recommended answer. Microsoft states it as three principles:

Verify explicitly

Authenticate and authorise on every available signal — identity, device health, location, workload, data sensitivity, risk — on every request. In SC-500 terms: Conditional Access, ID Protection, device compliance, authentication strength.

Use least-privileged access

Just-in-time and just-enough access, risk-based adaptive policy, data protection. In SC-500 terms: PIM, time-bound role assignments, JIT VM access, custom roles scoped tightly, access reviews.

Assume breach

Segment, encrypt end to end, verify continuously, and drive detection and response from telemetry. In SC-500 terms: NSGs and security admin rules, private endpoints, Defender workload plans, Sentinel.

When a question offers four technically valid controls, the one that reduces standing privilege or removes a public path is almost always the keyed answer.

The product map: who owns what

Microsoft's security portfolio overlaps heavily, and the exam exploits that. Learn the one-sentence boundary for each product and a surprising number of questions answer themselves.

Where things are configured

Hotspot and drag-and-drop items love portal navigation. The consolidation into the Defender portal is real but incomplete, and knowing what has not moved is worth marks.

flowchart LR
  subgraph AZP["portal.azure.com — the Azure control plane"]
    A1["Azure Policy · RBAC · resource locks · Key Vault · storage · Azure SQL · networking"]
    A2["Microsoft Defender for Cloud — plans, connectors, recommendations and secure score"]
  end

  subgraph DEF["security.microsoft.com — the Microsoft Defender portal"]
    D1["Defender XDR incidents and advanced hunting · Microsoft Sentinel · Exposure Management"]
    D2["Security for AI — agent inventory and real-time protection policies"]
  end

  subgraph OTH["Three you still have to leave the Defender portal for"]
    O1["entra.microsoft.com — Conditional Access, PIM, authentication methods, Agent ID"]
    O2["purview.microsoft.com — DSPM, DLP, sensitivity labels and Audit"]
    O3["securitycopilot.microsoft.com — workspaces, capacity, plugins and agents"]
  end

The scope hierarchy, and what inherits down it

flowchart TB
  subgraph TEN["Microsoft Entra tenant — one identity boundary for the organisation"]
    subgraph MGT["Azure RBAC, Azure Policy and resource locks all inherit downwards"]
      direction TB
      ROOT["Root management group — one per tenant, created automatically"]
      MG["Child management groups — up to six levels below the root"]
      SUB["Subscription — billing, quota and policy boundary"]
      RG["Resource group — lifecycle boundary"]
      RES["Resource — the VM, storage account or key vault you harden"]
      ROOT --> MG
      MG --> SUB
      SUB --> RG
      RG --> RES
    end
  end

Two role systems, one exam

The single most common source of confusion on this exam is that Azure has two entirely separate authorisation systems that happen to share a directory. Get this decision right and a long tail of questions becomes trivial.

flowchart TB
  Q["You need to grant somebody a permission"] --> A{"What is being administered?"}
  A -->|"An Azure resource"| AZ["Azure RBAC role — a VM, storage account, key vault or workspace<br/>Scoped to a management group, subscription, resource group or resource<br/>Assigned on the Access control (IAM) blade"]
  A -->|"The tenant itself"| EN["Microsoft Entra role — users, apps, Conditional Access, Defender XDR<br/>Scoped tenant-wide or to an administrative unit<br/>Assigned under Roles and administrators"]
  AZ --> PIM["Either way, do not make it permanent — Privileged Identity Management<br/>makes both kinds eligible, time-bound, approval-gated and audited"]
  EN --> PIM

Shared responsibility, and why it decides answers

Responsibility shifts as you move up the service models, and SC-500 uses that to rule answers in and out. If the question is about an Azure SQL Database, patching the operating system is not your job and is therefore not the answer; if it is about a VM, it is.

Information and data, and devices and accounts, are always yours. That is why "encrypt the data", "restrict who can sign in" and "classify the content" are almost never wrong answers regardless of service model.

The Microsoft cloud security benchmark

The Microsoft cloud security benchmark (MCSB) is Microsoft's own set of security control recommendations, mapped to CIS, NIST SP 800-53 and PCI DSS. It matters for the exam because it is not a document you read and file away — it is wired into the products:

• It is the default security standard applied to every subscription in Defender for Cloud, and it cannot be removed.
• Defender for Cloud's secure score is calculated from the recommendations that MCSB generates.
• Defender for Servers Plan 2's OS configuration assessment measures machines against MCSB compute baselines.
• Adding PCI DSS, ISO 27001, NIST or a sovereign standard to the regulatory compliance dashboard layers extra standards on top of MCSB; it never replaces it.

Control plane versus data plane

This distinction runs through the whole exam and explains a startling number of "why did that not work?" scenarios.

What to carry forward

With that in hand, go to Skill 1, which takes the identity and governance layer apart control by control.