SC-100 is an architecture exam, so “hands-on” preparation should not become a checklist of portal clicks. The practical goal is to make architectural relationships visible: how identity signals influence access, how posture findings become remediation priorities, how security operations consume telemetry, how applications and data are protected, and how governance constrains the design. The current SC-100 scope remains the July 28, 2026 blueprint as of October 4, with a minor Microsoft update already scheduled for October 21.
A strong lab uses one hybrid enterprise throughout: on-premises AD DS, Microsoft Entra ID, Microsoft 365, Azure workloads, one non-Azure environment, remote users, containers, a sensitive data store and a SOC. You do not need to build every service. Some exercises can be diagrams or tabletop designs when cost, permissions or licensing make deployment impractical.
Lab one: draw a Zero Trust reference architecture
Start with identities, devices, workloads, applications and data. Mark trust boundaries and identify where explicit verification, least privilege and “assume breach” principles should influence access. Add Conditional Access, PIM, endpoint posture, network/SSE controls and logging only after the trust relationships are clear.
A Zero Trust architecture becomes useful when it explains decisions rather than serving as a slogan. Your diagram should show why a user with valid credentials can still be denied because the device is risky or the action is privileged.
Lab two: design Conditional Access around business risk
Use a sandbox tenant or a policy worksheet. Define one policy for ordinary workforce access, one for privileged administrators and one for a sensitive application. Record target identities, applications, conditions, authentication strength and any exclusions or emergency-access needs.
Then create a failure scenario: a legitimate admin is traveling, a service account is misclassified, or an agent identity needs restricted access. A Conditional Access exercise is strongest when you can explain the business and security consequence of each condition.
Lab three: build a privileged-access design
Separate normal and privileged identities, define eligible rather than permanent role assignment through PIM where appropriate, add approval or time limits, require stronger authentication and identify how privileged sessions are monitored. Include emergency-access accounts and the recovery process if Entra becomes partially unavailable.
Document which roles are truly business-critical. The objective is to minimize standing privilege and blast radius, not to create an administrative workflow so complex that teams bypass it.
Lab four: map security telemetry into operations
Create a telemetry matrix with sources such as Entra, Defender for Endpoint, Defender for Cloud, Microsoft 365, Azure activity logs and one third-party cloud. Map each to Microsoft Sentinel, Defender XDR, hunting, alert correlation, automation and retention.
Then select one attack scenario—credential theft followed by cloud workload access—and show which signals arrive first, which platform correlates them and what action a SOAR playbook could take safely.
Lab five: prioritize Defender for Cloud findings by attack path
Use an available lab or screenshots to examine Secure Score, recommendations and attack-path style findings. Compare one isolated high-severity recommendation with a lower-severity weakness that completes a path to a critical asset. Record why business context changes priority.
A Defender for Cloud lab should teach posture management, not point chasing. The design objective is reducing meaningful exposure across Azure, hybrid and multicloud resources.
Lab six: connect Azure Arc and external attack surface to governance
Model one non-Azure server onboarded through Azure Arc and one internet-exposed asset discovered outside the expected inventory. Define ownership, policy, logging, vulnerability/posture management and remediation routes for both.
The exercise shows two different visibility problems: known hybrid resources that need centralized governance and unknown or unmanaged external assets that need discovery and ownership validation.
Lab seven: threat-model an application before adding products
Choose an API-backed web application. Identify assets, trust boundaries, entry points and threats. Then select secure-development standards, workload identity, secret handling, API controls, WAF, logging and incident signals that address the threats.
The architect should reduce design weaknesses early. Runtime protection is valuable, but it cannot fully compensate for an application that grants excessive access or stores secrets unsafely by design.
Lab eight: follow sensitive data across Microsoft 365 and Azure
Create a synthetic sensitive-data classification and trace it through SharePoint/Teams, Azure Storage, a database and an AI/Copilot workflow. Decide classification, access, encryption/key management, retention, DLP or Purview controls and monitoring for each location.
This exercise exposes an important SC-100 principle: data security follows the information, not the product boundary. An AI assistant can make already-overexposed data easier to discover, so permissions and classification must be sound upstream.
Lab nine: run a resilience and ransomware tabletop
Assume a destructive attack compromises endpoints and one privileged identity while encrypting a production workload. Decide how isolated administration, protected backups, recovery credentials, identity resilience, segmentation, communications and SOC operations preserve the ability to recover.
Measure success by restoration of a critical business service, not merely by rebuilding a VM. This aligns the best-practices domain with the architect’s business-resiliency responsibility.
Lab ten: present the architecture to three audiences
Explain the same design to an executive, a SOC lead and an application owner. The executive version should emphasize business risk, resilience and investment; the SOC version should emphasize telemetry and response; the application version should emphasize identity, secure development and data controls.
Add a Microsoft Cybersecurity Reference Architecture exercise before building product-specific labs. Take the reference enterprise and place identity, endpoint, network, application, data, security-operations and governance capabilities on one page. Then annotate which business-critical assets each capability protects. This creates a stable architecture vocabulary for every later exercise.
Add a Microsoft Cloud Security Benchmark mapping. Select a small set of benchmark control families—identity, privileged access, network, logging, data protection—and map them to your environment. Record which Microsoft services could implement or assess the requirement, but keep the control objective separate from the tool.
Add a landing-zone security tabletop. Define management groups, subscriptions, identity boundaries, Azure Policy, logging, network connectivity and shared security services for a new cloud environment. Then introduce a second business unit and test whether the governance design scales without cloning every control manually.
Add a DevSecOps architecture exercise. Create a simple path from source control through build, IaC validation, secrets handling, dependency/container scanning, approval and deployment. Identify where a policy violation should stop the release and which telemetry should reach security operations afterward.
Add an AI-agent identity exercise. Give a fictional enterprise agent a narrow business task and decide whether it should use delegated user access, application permissions or another managed identity pattern. Limit tools, data and actions, then define how Conditional Access-style controls, logging and approval protect high-impact operations.
Add a continuous-access scenario. A user signs in successfully, but risk later increases because the device becomes noncompliant or credentials are suspected. Explain how continuous access evaluation and session controls can reduce the time between changed context and access enforcement.
Add an external-identity lifecycle exercise. Invite a partner user to a synthetic application, define sponsor/owner, authentication requirements, access package or role, expiration and review. Then simulate the partner leaving and verify how stale access is removed. Collaboration is secure only when lifecycle is governed.
Add a cloud entitlement review across two clouds. List high-impact permissions and identify standing access that is broader than needed. Decide which privileges should become time-bound, approval-based or removed. The point is architectural least privilege, not reproducing one vendor’s CIEM interface.
Add a Microsoft 365 posture exercise around phishing and data exfiltration. Trace the event from malicious message to user identity, endpoint, cloud application and sensitive document. Assign Defender for Office 365, Defender for Cloud Apps, Intune, Purview and Sentinel/XDR roles in the investigation and remediation.
Add an OT/IoT security tabletop. Choose a manufacturing controller or embedded device that cannot run a normal endpoint agent. Define segmentation, passive monitoring, identity, remote administration, patch constraints and incident isolation. This demonstrates why SC-100 architecture has to adapt control patterns to the workload type.
Add a Security Service Edge exercise. Trace one remote user to a public internet service and to a private line-of-business application. Show where Entra identity, device posture, Entra Internet Access and Entra Private Access make policy decisions. Compare with a traditional VPN-only design and note which trust assumptions change.
Add a key-management tabletop. Store a fictional application’s secret or encryption key in Key Vault, define workload identity and rotation ownership, then simulate accidental key deletion or revoked access. Availability and recoverability are part of secure key architecture just as much as confidentiality.
Add a threat-hunting feedback loop. Start with a hunt hypothesis about credential abuse, identify required telemetry, run the hunt conceptually, then translate a confirmed pattern into improved detection or prevention. Architecture should evolve from operational evidence rather than stay frozen after the design workshop.
Add a compliance-evidence package. For one fictional requirement, collect a policy statement, Azure Policy state, Defender for Cloud posture evidence, Purview evidence and audit logs. Then explain which item proves configuration, which proves data governance and which proves activity. This prevents compliance architecture from becoming a vague collection of screenshots.
Close the lab series with a design review rather than a configuration quiz. Ask whether each control has an owner, dependency, logging path, failure mode and recovery process. A security capability that works only when one engineer remembers an undocumented step is not mature architecture.
Add one final attack-path review after all labs. Starting from an external user or compromised endpoint, trace identity, privilege, network access, workload permissions, data exposure and SOC evidence. Mark which control would prevent movement, which would detect it and which team owns remediation. This exercise tests whether the individual labs have become one security architecture rather than a collection of Microsoft product demonstrations.
The Cybersecurity Architect role is partly about translating security architecture across teams. If the design only makes sense as a portal walkthrough, it is not yet strong SC-100 practice.