SC-100: Architecting for Resilience

A manufacturer discovers suspicious activity in an identity that administers both its cloud subscriptions and its backup platform. Security monitoring reports a possible compromise, but operations management asks a more pressing question: can the production systems be restored without trusting the identity that may have been stolen? This is an architecture problem. A security design succeeds not only when it blocks an attack, but also when an organization can contain damage, preserve evidence, and recover critical services under compromised conditions.

The SC-100 exam assesses the decisions of a Microsoft cybersecurity architect. In the July 2026 blueprint, the four major areas are security priorities and best practices, operations and identity and compliance, infrastructure, and applications and data. The work is explicitly cross-functional. It requires an architect to connect Zero Trust principles, business resiliency, and technology controls rather than treat them as disconnected product configurations.

Start with the business consequence of failure

A useful security architecture begins with the systems the business cannot afford to lose. A payment service, production-control environment, logistics workflow, and public web portal do not have identical recovery requirements. Map the transactions they support, their dependencies, who owns them, and what happens if they are unavailable or untrustworthy. Only then is it possible to make an informed trade-off between stronger isolation, higher availability, and the cost of operating redundant infrastructure.

Recovery time objective and recovery point objective are useful only when tied to actual business assumptions. A service whose data cannot be reconstructed may need frequent protected backups even if downtime is tolerable. Another service may demand high availability but recover from an older data snapshot without major loss. An architect should test those distinctions with business owners and document the implications of each choice. “Mission critical” is not a technical requirement until someone specifies what loss and interruption mean.

Dependencies make recovery more complex than rebuilding a virtual machine. A workload may rely on a managed identity, secrets repository, DNS service, network route, device trust, and external supplier. An attacker who controls the administration plane may block recovery even when application data remains intact. A restoration design must identify which dependencies can be rebuilt from trusted infrastructure and how the organization will regain administrative control safely.

Treat privileged access as part of the recovery system

Ransomware planning often concentrates on endpoint protection and backup immutability, but a compromised privileged account can alter policy, disable monitoring, or change retention settings. This is why identity architecture belongs inside resiliency strategy. Separate routine user access from privileged administration, minimize standing access, and ensure that the accounts responsible for recovering the environment are protected differently from accounts used for everyday changes.

Emergency-access arrangements require careful thought. A break-glass identity should not be an ordinary convenience account. Its use must be governed, monitored, and periodically tested under conditions where normal identity services or authentication routes are impaired. The organization also needs to know who can authorize its use, how credentials are protected, and how access will be rotated after an incident. These are operational responsibilities, not just settings in a portal.

Microsoft Entra Privileged Identity Management and related governance capabilities help organizations constrain privileged activity, but the design problem comes before feature selection. Decide what elevation should require, how long it can last, and how sensitive changes are detected. A team responsible for implementing those controls may work closer to the detailed identity skills associated with SC-300; the SC-100 architect must establish why the access model serves the business’s overall security and recovery objectives.

Apply Zero Trust to the whole attack path

Zero Trust is frequently reduced to multi-factor authentication. Authentication is important, but a system can have strong sign-in controls and still allow excessive lateral movement, overly broad workload permissions, or uninspected data transfer. An architect should work through the likely attack paths: entry through a phishing campaign, misuse of an application identity, privilege escalation, movement between workloads, access to sensitive data, and disruption of recovery infrastructure.

The design should ask what would prevent or expose progress at each stage. Identity-based access policies may limit the use of compromised credentials; network segmentation can constrain reachability; workload and endpoint defenses can detect suspicious behavior; logging can establish the sequence of events. No single control is expected to stop everything. Good architecture balances preventive controls with detection, containment, and recoverability.

Consider a contractor connecting to a restricted operational application. The system may need to evaluate the user’s identity, device state, session risk, application authorization, and the network route. A successful login alone should not grant access to every associated system. The design’s strength lies in enforcing narrow decisions as close as practical to the protected resource and revisiting them when risk changes.

Use reference architectures as tests of completeness

Microsoft’s Cybersecurity Reference Architectures and Cloud Security Benchmark provide patterns and control categories that help an architect examine a design systematically. They are not substitutes for threat modeling. A standard pattern may show where identity, data protection, monitoring, and infrastructure controls usually belong; the organization must still decide which risks are material, how systems are connected, and what operational capabilities exist to maintain the controls.

For instance, a cloud landing-zone design can provide subscription organization, policy guardrails, logging expectations, identity management, and networking foundations. The architect should ask whether the controls will apply to newly created workloads and whether exceptions are visible. A policy that works for the initial deployment but can be bypassed by a secondary subscription has not established a stable security boundary. Consistency matters more than a visually impressive diagram.

Reference guidance is especially useful when teams use different platforms. A shared security objective—such as retaining evidence, protecting privileged activity, or encrypting sensitive information—may require different technical implementations in Azure, another cloud, and on-premises systems. The architect defines an outcome and verification method that are comparable, rather than claiming that one product provides identical guarantees everywhere.

Design for a breach, not only for normal operations

Ask what happens when an attacker already has access. Can a compromised workload read secrets for unrelated applications? Can a backup repository be deleted with ordinary administrative credentials? Can incident responders trust telemetry from the systems under investigation? These questions reveal structural weaknesses that baseline compliance checks often miss. Recovery design should assume some controls will fail at the worst possible moment.

A resilient environment needs independent restoration capabilities where feasible. That may include protected backups, tested alternate administrative paths, documented rebuild procedures, and controlled access to essential keys. Testing must include the business process, not merely successful file restoration. Restoring a database is insufficient if dependent applications cannot authenticate or if the recovered information cannot be reconciled with external transactions.

Security incidents introduce decision pressure. If operations leadership wants to reconnect systems immediately, incident responders may want to preserve volatile evidence and verify containment first. The architecture should make those trade-offs visible beforehand through response plans, clear ownership, and practiced exercises. Technical controls are easier to use under stress when the organization has already agreed who makes the difficult calls.

Make security operations part of the original design

Monitoring requirements should be developed with the architecture, not bolted on after implementation. Identify which changes, access events, and data movements need to be observable, where relevant logs originate, how they reach the detection platform, and who is responsible when collection fails. A security system that creates enormous telemetry without usable context can exhaust analysts while leaving important attack paths invisible.

Incident response also needs a credible authority model. Investigators must be able to isolate workloads, revoke credentials, preserve evidence, and communicate with business owners. Designing those permissions only after a compromise leads to delays or overly broad standing access. The hands-on detection and response activities associated with SC-200 inform this work; SC-100 asks whether the overall architecture makes those activities possible at the required scale.

Measure outcomes rather than installation. Relevant evidence includes tested recovery success, the time needed to contain a simulated compromise, the percentage of critical workloads with validated logging, and whether privileged access exceptions are reviewed. Each metric needs a definition. A dashboard showing green status for hundreds of configured controls cannot prove that the company could recover from a stolen tenant administrator identity.

Turn architecture decisions into accountable trade-offs

There is no meaningful “most secure” design without a business context. A highly isolated application may be impossible for a remote workforce to operate, while a low-friction design may expose sensitive data beyond acceptable limits. The architect’s job is to document options, explain residual risk, and obtain the right acceptance or funding decision. The best design often improves safety and operability together by removing unnecessary privileges, narrowing dependencies, and simplifying recovery paths.

For SC-100 preparation, take the manufacturer scenario and draft a design decision record. State the critical services, main attack assumptions, identity and backup trust boundaries, monitoring responsibilities, and recovery evidence that would demonstrate success. Then ask what changes when the environment spans more than one cloud or when administrators cannot reach the primary identity provider. The exercise reflects the architecture-level reasoning the exam expects without repeating general certification tips.

Cybersecurity architecture earns its place when it gives the business choices it can defend before a crisis and systems it can rely on during one. Resilience is not a backup feature or a slogan. It is the result of deliberate decisions about access, dependency, visibility, and recovery under conditions where trust has already been damaged.