These are original illustrative architecture questions for Microsoft SC-100 preparation, not copied or recalled exam items. They test whether the reader can identify the control that meets a particular requirement and explain why alternatives fail. Microsoft revised the English SC-100 objectives effective October 21, 2026; consult the issuer’s dated guide for the complete assessed scope.

Question 1 — Protect recovery from a compromised administrator

An organization has multiple backups of a business-critical Azure workload, but the same privileged identity controls the live environment and all backup deletion operations. Leadership requires recovery after an attacker captures that identity. What is the most defensible design change?

A. Make more backups under the same administrative account. B. Separate and protect recovery administration, test restoration dependencies, and validate the integrity of recovery data. C. Disable monitoring to speed backup operations. D. Replicate the affected workload without changing privileged access.

The strongest answer is B. Backups controlled by the same compromised permission boundary share the vulnerability. Replication can faithfully reproduce compromised information. A useful recovery design includes access separation, protected recovery assets where available, clear restore order, and evidence that a recovered service can be safely returned to production.

Question 2 — Design cross-tenant access after an acquisition

A firm has acquired another company. Teams need limited document collaboration, but sensitive resources must not become available to all accounts across both organizations. Should the architect establish full reciprocal trust by default, require one shared administrator, or define narrowly scoped collaboration rules?

The defensible starting point is scoped cross-tenant collaboration with explicit inbound and outbound trust, resource assignment, logging, lifecycle expiration and approved exceptions. A partner user’s authentication does not itself grant access to every resource tenant application. The design should also distinguish normal staff access from privileged roles and emergency access.

This is an exercise in Zero Trust architecture. A VPN does not substitute for application authorization; an identity federation connection does not replace resource-tenant policy. The question is which trust is necessary for a particular business operation and how that trust can be revoked.

Question 3 — Secure an application migration

An application is moving to Azure and must read sensitive data. Engineers want to avoid a broadly accessible public database endpoint and permanent credentials in source code. Would a private endpoint alone solve both requirements, would a workload identity alone do so, or are network and identity controls complementary?

They are complementary. A private access path can reduce unwanted exposure where the particular service supports it, but it does not by itself authorize a database request. A managed or other suitable workload identity can improve credential handling, yet the application must receive narrow resource permissions and the network path must be verified.

The architect must verify actual product support and deployment constraints. A private connection that reaches an overly privileged application is still an unacceptable data-access design. Logging, key management, application error handling and incident ownership are part of the same decision.

Question 4 — Build actionable security operations

An enterprise forwards alerts from identity, endpoints and Azure resources to several separate queues. A privileged-token theft goes undetected because no one correlates the evidence or owns containment. Is the next architecture decision to ingest everything indiscriminately or to define threat-specific detection and response coverage?

Define required telemetry, correlation rules, triage ownership, investigation and approved containment first. Microsoft Defender XDR and Microsoft Sentinel can support different pieces of this architecture, but a product deployment does not create a functioning incident workflow on its own. Set evidence retention and escalation expectations appropriate to the threat.

The SC-100 architectural decision examples can deepen the comparison. Explain which log or signal demonstrates the behavior and who may execute containment. An alert without an accountable action is incomplete, as is an automated response that can disrupt critical infrastructure without proportionate safeguards.

Question 5 — Govern AI-assisted access to classified information

A proposed AI search assistant will summarize internal documents for employees. It must not disclose documents the requesting employee cannot ordinarily access. The simplest configuration gives the agent a broad repository-level account and relies on the user interface to hide sensitive results. Is that sufficient?

No. The architecture must enforce the caller’s authorization at retrieval and use, apply classification and policy to source data, constrain the workload or agent identity, and log sensitive access. A warning banner does not constrain an API. Consider how the system responds to a role change, external guest identity, malicious prompt content or document reclassification.

Microsoft Purview, Entra and application controls may contribute to the design depending on available features and data source support. The architect must check the actual permissions and document the trust boundary rather than assuming an AI product implements perfect user-specific enforcement by default.

Question 6 — Control hybrid infrastructure without assuming one provider

An organization operates Azure resources alongside servers in its own data center and a second cloud. Executives want comparable policy reporting, but the proposal claims that enabling one central Microsoft dashboard will automatically enforce the same configuration on all systems. Is that a sound architecture?

No. Central visibility may help identify drift, but workload onboarding, permissions, supported security benchmarks and policy mechanisms differ by environment. A design should map each control to the specific provider or operating system where it can be enforced, identify exceptions and confirm that findings reach an accountable remediation process.

For example, a cloud posture assessment may report a risky public service exposure while an on-premises server requires different configuration management and network controls. The architect must specify which control changes the exposed resource and what evidence proves the finding was resolved, rather than treating a consolidated score as automatic protection.

Question 7 — Distinguish classification from enforceable data access

A firm labels documents containing sensitive customer information and assumes this is sufficient to prevent inappropriate disclosure through collaboration tools. A new external guest can authenticate and has a broad group assignment. What missing requirements should the security architect investigate?

Identify where the label is enforced, the guest’s authorization to access each repository, the permitted sharing workflow, applicable DLP or session controls and audit visibility. Labels can guide information protection, but a label alone does not prove that the right identities and applications are scoped. The architect should design access reviews and an exit process for the guest as well.

When assessing the solution, ask how a restricted document travels into an email attachment or an AI retrieval system and whether the protection follows it through each supported workflow. Also define who approves an exception, what evidence is retained and how a mistake is detected. This turns the classification concept into a testable architecture.

One useful extension is to document the evidence that would confirm each design after deployment. For protected backups, that means a tested restoration under separated privileges. For identity trust, it means an access log and demonstrated revocation at contract end. For private connectivity, it means confirming the expected DNS resolution and effective authorization. For data protection, it means testing permitted and rejected retrievals with distinct user identities. These tests convert an architecture recommendation into a verifiable security requirement.

How to learn from the solutions

For each scenario, identify the exact requirement an alternative fails. More backups do not repair an administrative trust boundary. Successful authentication does not grant every application entitlement. A private network does not remove the need for API authorization. A dashboard does not guarantee response ownership. Recognizing these failure modes is the central practice.

The original material used Azure SQL Managed Instance as a key-rotation example. For a modern design, distinguish encryption at rest from control of the encryption key. Transparent Data Encryption can protect stored data, and customer-managed keys may be supported through an appropriate key service configuration. A required rotation period must be checked against supported service, key-vault and organizational procedures; it is not safe to promise that every platform automatically enforces an arbitrary two-month schedule.

When an organization acquires another Azure estate, begin by understanding asset inventory, access boundaries and business risk. Microsoft Defender for Cloud can help provide supported posture visibility across subscriptions, but the architect still has to define the management scope, roles, benchmark expectations and remediation ownership. Onboarding alone does not establish compliant governance or an approved Zero Trust design.

For a workload migrating to Azure, private endpoints may reduce exposure of supported platform services by providing private access through a virtual network. The precise connectivity and DNS configuration must be designed for the target service. Private connectivity does not replace authentication and resource authorization, and it should not be described as eliminating every external attack possibility.

The original copy recommended a specific legacy adaptive application-control feature in Defender for Cloud as though it were universally available. The enduring design requirement is application execution control on supported hosts, with software inventory, approved publisher or hash policies where applicable, and measured detection of unauthorized execution. Modern choices must be checked for current support before making a product-specific recommendation.

Cross-check each architecture problem against the current SC-100 scope. A careful learner can construct variations—different recovery objectives, an external provider, or an additional data-residency requirement—and determine when a preferred choice changes. The scenarios are meant for reasoning, not memorization of answer letters.