Microsoft SC-100: Designing Security Across the Whole Estate

SC-100, Microsoft Cybersecurity Architect, is a current expert-level exam for professionals who translate cybersecurity strategy into implementable capabilities across identity, devices, data, applications, infrastructure, operations, governance, and AI. Microsoft’s active blueprint is the July 28, 2026 version; an English update is already published for October 21 and should be treated as an upcoming change rather than the currently tested scope.

The exam is part of the Cybersecurity Architect Expert path. It assumes depth in at least one implementation area and expects the architect to connect several specialist domains. Security operations, identity and access, information security, and cloud and AI security controls are therefore adjacent capabilities rather than isolated certificates.

A useful preparation lab is an architecture review for a fictional organization with Azure, Microsoft 365, on-premises workloads, SaaS applications, sensitive data, and a small security operations center. Build the target security model, then challenge it with incidents, identity compromise, application risk, data leakage, and cloud posture weaknesses. Architecture skill appears when those controls reinforce one another instead of becoming a collection of products.

Cybersecurity strategy should begin with business priorities and threat assumptions

An architect needs to know which business services matter, what data is sensitive, what regulations apply, which adversaries are plausible, what failure the organization can tolerate, and how much operational complexity it can support. Frameworks and reference architectures are useful because they organize decisions, not because every organization should implement every control identically.

For the lab organization, identify five critical business assets and rank likely attack paths against them. Then map each risk to preventative, detective, responsive, and recovery controls. This prevents the architecture from becoming product-first. A security service is justified because it reduces a defined risk or improves evidence, not because it appears on a Microsoft diagram.

Zero Trust turns identity, device, network, application, and data signals into policy

Zero Trust is often summarized as “verify explicitly, use least privilege, assume breach,” but SC-100 expects candidates to design how those principles become controls. Identity strength, device health, session risk, network context, workload identity, application sensitivity, and data classification should influence access decisions continuously rather than only at initial sign-in.

Build a policy path for an administrator accessing a sensitive cloud application from a managed device and then compare it with access from an unmanaged device at unusual risk. The Zero Trust architecture is stronger when policy decisions can be explained from signals and business impact rather than from blanket restrictions.

Security operations architecture should connect telemetry, detection, response, and recovery

Defender XDR, Microsoft Sentinel, Defender for Cloud, Microsoft Entra, Microsoft Purview, and other sources can all contribute evidence. The architect should define what telemetry is required, where it is retained, how detections are engineered, how incidents are correlated, which response actions can be automated, and what must be escalated.

Trace one multi-stage attack from phishing through identity compromise, endpoint execution, lateral movement, and data access. Identify which product detects each stage and where the incident is correlated. Then ask what happens if one telemetry source is unavailable. A resilient security-operations design should degrade visibly rather than silently lose coverage.

Identity architecture is the control plane for human and non-human access

Entra ID, Conditional Access, identity protection, privileged access, workload identities, app registrations, external identities, and governance determine who or what can reach resources. The architect has to balance usability, assurance, administrative separation, lifecycle management, and emergency access.

Design administrative access with just-in-time elevation, strong authentication, protected actions, break-glass accounts, and monitoring. Then add a service principal that needs application access without interactive sign-in. Human identity and workload identity need different lifecycle and credential strategies, even though both can become high-impact attack paths.

Infrastructure security should assume hybrid and multicloud dependencies

Modern organizations rarely protect only one Azure subscription. They may have on-premises servers, multiple Azure tenants, other clouds, containers, network appliances, and SaaS systems. Posture management, network segmentation, secrets, workload protection, patching, configuration baselines, logging, and asset inventory have to work across that mixed estate.

Create an architecture view that shows trust boundaries around workloads rather than provider logos. Mark administrative paths, east-west traffic, internet exposure, secret stores, and monitoring points. Then introduce an unmanaged server or shadow cloud account and decide how the architecture discovers and governs it. Unknown assets are architectural risk even when core Azure resources are well configured.

Application security should be designed through the delivery lifecycle

Applications create risk through identity, secrets, dependencies, APIs, code, deployment pipelines, data access, and runtime configuration. Secure architecture therefore includes threat modeling, workload identity, secret management, dependency governance, pipeline controls, testing, runtime protection, and incident visibility.

Take a small web application and identify where each security decision belongs: developer workflow, CI/CD, cloud configuration, application code, API gateway, data store, or monitoring system. The goal is to avoid concentrating all controls at the perimeter. Secure-by-design practices reduce the number of mistakes that operations teams must detect later.

Data security should follow classification and business use, including AI use

Data moves through files, email, collaboration sites, databases, analytics systems, applications, endpoints, and AI experiences. Encryption and access control are necessary but not sufficient. Classification, retention, DLP, insider-risk signals, audit, eDiscovery, and AI data controls help govern how sensitive information is used after access is granted.

Choose one sensitive data type and trace its allowed lifecycle from creation through collaboration, analysis, AI use, archival, and disposal. Identify where a control prevents misuse, where a control only detects it, and where human review is required. This creates a data-centric architecture rather than assuming application permissions solve every information-risk problem.

Governance and posture management should turn policy into measurable security debt

Regulatory obligations, Microsoft Cloud Security Benchmark practices, Azure Policy, security recommendations, secure score concepts, risk registers, and exception processes help organizations compare desired state with actual state. An architect should decide how deviations are prioritized, accepted, remediated, and reported.

Build a posture backlog with severity, business impact, affected assets, compensating controls, remediation owner, and due date. Include one accepted exception and define when it expires. Security posture management is valuable when it creates accountable decisions rather than an endless list of recommendations that no team owns.

Architecture decisions should expose tradeoffs and operating ownership

A technically strong control can fail if the organization cannot operate it. False-positive volume, staffing, license cost, administrative overhead, user friction, integration complexity, and recovery skill all influence design. SC-100 questions often reward the option that achieves the objective with the right scope and operational fit rather than the most feature-rich stack.

Finish with a design review in which each major control has a threat or requirement, implementation owner, monitoring source, exception process, and recovery plan. Compare the result with broader security architecture patterns and the Microsoft security role paths. If the architecture can explain why controls exist and who operates them, it is much closer to the level SC-100 measures.

Architects also need a method for deciding where security responsibility sits between platform provider, central security teams, product teams, and business owners. Shared responsibility becomes complicated in SaaS and multicloud environments because the provider may secure the underlying service while customers remain responsible for identities, data classification, configuration, and response. Make ownership explicit for every critical control so that two teams do not assume the other is monitoring it.

Threat modeling is a useful bridge between application teams and architecture. Pick one business service, map entry points and trust boundaries, identify likely abuse cases, and then connect mitigations to design controls. The exercise can reveal that a broad network control does little against an over-privileged workload identity, or that strong identity controls do not solve insecure data export. Architecture improves when controls are tied to specific attack paths.

Resilience belongs in security design as well. Consider what happens if Entra authentication is degraded, Sentinel ingestion is delayed, a key management service is unavailable, or a security automation playbook fails. The organization may need break-glass access, alternate monitoring, manual response procedures, or controlled service degradation. Security architecture that cannot tolerate failure can become an availability risk during the incident it is trying to contain.

Use continuous-verification patterns to review whether trust is reassessed after initial access. Session risk, device state, workload behavior, data sensitivity, and privilege changes can all alter the appropriate control. A one-time login decision is not enough for high-value systems that operate for hours or days.

End the capstone with an executive communication exercise. Summarize the top three cyber risks, the architecture decisions that reduce them, the residual risk that remains, and the investment or operating change still required. SC-100 architects must communicate with both technical implementers and leaders who decide priorities. If the architecture cannot be explained in business terms, it will be difficult to fund, govern, or operate consistently.

Architecture review should explicitly model control failure. Pick a high-value business service and assume one protective layer is unavailable or bypassed: a device is unmanaged, a privileged credential is compromised, a network control is misconfigured, or a logging pipeline stops. Then trace which remaining controls limit blast radius and which evidence still supports detection and recovery. This exercise exposes hidden single points of trust and turns defense in depth from a diagram into a testable property of the architecture.

The architect also needs a method for prioritizing security investment. Combine business impact, exploitability, control coverage, exposure duration, and recovery difficulty instead of treating every finding as equal. A severe technical weakness on an isolated test system may create less enterprise risk than a moderate identity-control gap affecting every administrator. Translating those differences into a defensible remediation sequence is part of the role because security architecture must help the organization spend limited engineering capacity where it changes risk most.