Examworthyexamworthy.comMicrosoft Cybersecurity Architect (SC-100) cheat sheet
Microsoft
Free to share. Examworthy is not affiliated with or endorsed by Microsoft; SC-100 and related marks belong to their respective owners.
At a glance
Format: Multiple choice, multiple response, and case studies, at a Pearson VUE testing center or online proctored
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
SC-100 is a design-the-strategy exam: almost every question is a scenario with resilience, identity, compliance, infrastructure, or data constraints, and the right answer is the Microsoft capability or reference-architecture pattern that satisfies all of them at the architectural level with the least standing risk.
Spot the trap
Tempting wrong answers, and why they failTempting but wrong
Tightening Conditional Access sign-in frequency to a short interval delivers near-real-time revocation of access mid-session.
Why it fails
A short sign-in frequency only reapplies policy at the next scheduled prompt, not at the moment access is revoked. It feels responsive but still leaves a window where a live token works. Continuous access evaluation is what enforces revocation and critical events in near real time.
Design Security Operations, Identity, and Compliance Capabilities
Tempting but wrong
Microsoft Entra Privileged Identity Management can randomise and rotate each Windows device's built-in local administrator password.
Why it fails
Privileged Identity Management brokers just-in-time, time-bound activation of directory and Azure roles. It does not randomise or rotate the per-device built-in local administrator password stored on each machine, which is what Windows LAPS handles.
Design Security Solutions for Infrastructure
Tempting but wrong
Replicating backups to a second Azure region protects restore points from a compromised Global Administrator.
Why it fails
Geo-replication only defends against a datacentre or regional outage. A privileged attacker can issue deletion commands against the replicated copies just as easily as the primary, so it does nothing against a malicious admin-level identity. Immutable, retention-locked storage is what blocks deletion.
Design Solutions that Align with Security Best Practices and Priorities
Tempting but wrong
Dynamic application security testing against a staging build can catch design-level trust-boundary flaws before code is written.
Why it fails
Dynamic testing runs against built, deployed code, so it can only find exploitable issues in software that already exists. It cannot surface design-level trust-boundary or missing-authorisation flaws before code is written; that is the role of threat modelling during the design phase.
Design Security Solutions for Applications and Data
Tempting but wrong
Microsoft Entra ID Protection risk policies terminate an access token that has already been issued when a user is flagged high risk.
Why it fails
Risk policies score the identity and gate the next authentication, so they only act at sign-in. They do not invalidate a token already issued, so an active session continues. Continuous access evaluation is needed to kill the live token near real time.
Design Security Operations, Identity, and Compliance Capabilities
Tempting but wrong
Microsoft Entra Conditional Access with device-compliance policies fixes a shared local administrator password problem.
Why it fails
Conditional Access gates sign-in to cloud and federated resources by device posture. It does not randomise or rotate the local administrator password stored on each Windows device, so it cannot remove the shared-credential lateral-movement risk. Windows LAPS does that.
Design Security Solutions for Infrastructure
Tempting but wrong
Encrypting backups at rest with customer-managed keys stops a compromised admin from destroying them.
Why it fails
Encryption at rest protects backup confidentiality, not availability. It does nothing to stop a Global Administrator from deleting the backups outright. Surviving a privileged ransomware actor requires immutable, time-locked storage that no role can delete until retention expires.
Design Solutions that Align with Security Best Practices and Priorities
Tempting but wrong
Static application security testing in the build pipeline is the earliest control and catches design flaws before code exists.
Why it fails
Static analysis operates on committed source and flags insecure coding patterns, but it reads code rather than architecture. Design flaws such as missing authorisation boundaries exist before any code and cannot be read from a diagram by a scanner. Threat modelling during design is what catches them earliest.
Design Security Solutions for Applications and Data
Key terms
Exam-day rules
- Read the scenario for its constraint first. The resilience, identity, compliance, infrastructure, or data requirement named in the question is what picks the design, so find it before you judge the options.
- Apply assume-breach to every resilience and identity question. When the scenario names a compromised admin or privileged identity, choose the control the attacker cannot defeat with the access they hold, such as immutable backups or continuous access evaluation, not one that relies on the access they already have.
- Prefer preventive enforcement over detection. A grant-time separation-of-duties rule, a scoped role assignment, or platform-enforced immutability beats an option that only notices, reviews, or limits the problem after it has formed.
- Match the framework to the requirement. MCRA for reference patterns, MCSB for control baselines, CAF for the operating model and DevSecOps, WAF for the security pillar and trade-offs, and the Rapid Modernization Plan when the scenario asks where to start.
- Separate posture from runtime and match protection to the surface. Configuration posture management does not detect active threats; pick the Defender workload plan built for the exact surface, from endpoints and servers to passive IoT sensors and the device builder micro-agent for shipped hardware.
Revision schedule
- Day 1Map the blueprint and book a date
- Week 1Internalise the Zero Trust assume-breach lens
- Weeks 1 to 2Go deep on operations, identity, and compliance (Domain 2)
- Weeks 2 to 3Lock infrastructure protection by surface (Domain 3)
- Weeks 3 to 4Cover application and data design (Domains 1 and 4)