4 of the 10 questions we have for this objective, shown with the answer and the reasoning.
Design solutions that align with the Microsoft Cybersecurity Reference Architectures (MCRA) and Microsoft Cloud Security Benchmark (MCSB)
Ironvale Bank runs a customer-facing assistant built on Azure OpenAI with retrieval-augmented generation over Azure AI Search, published to customers through an Azure API Management instance. Identity, network, and encryption controls already align to the Microsoft Cloud Security Benchmark. An internal review found a gap against the MCSB logging and threat detection controls: there is no runtime detection of prompt injection, jailbreak attempts, or sensitive data leaking in model responses, and such detections must appear as alerts and incidents in Microsoft Defender XDR alongside the bank's other alerts.
What should you recommend to close the gap?
- AEnable Microsoft Defender for AI Services in Microsoft Defender for Cloud on the subscription and turn on user prompt evidence so that the alerts surface in Defender XDRDefender for AI Services is the Defender for Cloud plan that analyzes prompts and responses at runtime, using Azure AI Content Safety Prompt Shields and Microsoft threat intelligence, for jailbreak, prompt injection, data leakage, and other AI-specific attacks, and its alerts flow into Defender for Cloud and Defender XDR for correlation; it is the MCSB LT threat-detection control applied to generative AI workloads.
- BEnable Microsoft Defender for APIs on the Azure API Management instance that fronts the assistantDefender for APIs detects API-level anomalies on the API Management instance, such as unauthenticated access and data exfiltration patterns, but it does not inspect prompt or completion content, so it cannot detect jailbreaks or injected instructions.
- CSend Azure OpenAI diagnostic logs to Microsoft Sentinel and write KQL analytics rules that search prompts for suspicious phrasesAzure OpenAI diagnostic logs record request metadata, not full prompt and completion content, and hand-written phrase lists are brittle compared to the purpose-built detection the platform provides.
- DEnable Microsoft Purview Data Security Posture Management for AI to monitor the assistant's interactionsPurview DSPM for AI provides posture and data-risk insights for AI interactions and sensitive data, but it is not the threat-detection control that generates runtime attack alerts in Defender XDR.
Why: The MCSB logging and threat detection domain expects native threat detection for each Azure service, and for generative AI workloads that control is Microsoft Defender for AI Services in Defender for Cloud, which inspects prompts and responses for AI-specific attacks and routes alerts into Defender XDR for correlation with the rest of the estate. The deciding constraints are runtime detection of prompt-level attacks and integration into Defender XDR incidents. The traps are adjacent products: Defender for APIs secures the API surface but is blind to prompt semantics, Sentinel can only see what is logged and Azure OpenAI diagnostic logs omit prompt content, and Purview DSPM for AI governs data posture rather than detecting attacks.
Design solutions that align with the Microsoft Cybersecurity Reference Architectures (MCRA) and Microsoft Cloud Security Benchmark (MCSB)
Oakhurst Logistics depends on three outsourcing partners whose engineers hold Microsoft Entra B2B guest accounts, on 40 third-party OAuth applications that users have consented to in Microsoft 365, and on open-source packages pulled into its build pipelines in GitHub. A supply chain compromise at a peer company has prompted the board to require that a compromise of any partner, consented application, or upstream package must be detected or blocked by a technical control rather than by contract alone.
Which three controls should you recommend? Each correct answer presents part of the solution.
- AEnable app governance in Microsoft Defender for Cloud Apps to monitor OAuth application permissions and anomalous data access, and restrict user consent to verified publishersApp governance gives visibility into which OAuth apps hold which permissions and alerts on overprivileged or anomalous apps, while consent restrictions stop users from granting new high-privilege access to unverified publishers.
- BEnable GitHub Advanced Security dependency scanning and secret scanning on the repositories, and require signed, reviewed pull requests for pipeline definitionsDependency scanning detects vulnerable or malicious upstream packages, secret scanning stops leaked credentials, and protected pipeline definitions prevent a compromised package or contributor from altering the build itself.
- CConfigure cross-tenant access settings and Conditional Access so that partner guest accounts must satisfy multifactor authentication and device compliance and are scoped only to the applications they needCross-tenant access settings let you trust or require MFA and compliant-device claims for partner identities, and least-privilege application assignment limits what a compromised partner account can reach.
- DDisable Microsoft Entra B2B collaboration entirely and issue partner engineers internal employee accountsIssuing internal accounts to partner staff increases risk: the accounts are no longer governed by the partner's identity lifecycle, are harder to deprovision when a partner engineer leaves, and bypass the cross-tenant controls designed for this case.
- ERequire each partner to provide an annual SOC 2 Type II report in place of technical controls on their accountsAssurance reports describe a partner's controls at a point in time; they do not detect or block a live compromise, which the board explicitly required a technical control to do.
Why: Supply chain attacks arrive through trusted paths, so the defense is to put technical controls on each trust relationship: partner identities, consented applications, and software dependencies. Cross-tenant access settings and Conditional Access govern what partner guests must prove and can reach, app governance in Defender for Cloud Apps monitors the OAuth applications that already hold permissions, and GitHub Advanced Security guards the software supply chain. The deciding constraint is that the control must be technical rather than contractual. The traps are the two extremes: abandoning B2B, which removes governance rather than adding it, and relying on audit reports, which is exactly the contract-only posture the board rejected.
Design solutions that align with the Microsoft Cybersecurity Reference Architectures (MCRA) and Microsoft Cloud Security Benchmark (MCSB)
Bexley Retail has a new CISO who wants to begin a Zero Trust program by immediately deploying Conditional Access policies to all 12,000 users next month. Previous security programs at the company failed because business units refused to adopt controls they had not agreed to. The CISO asks the architect to shape the program so that it follows the Zero Trust adoption framework and avoids repeating that failure.
What should you recommend as the starting point?
- AStart with the Define strategy phase: agree business outcomes and executive sponsorship for a chosen business scenario, then move to Plan, Ready, Adopt, and Govern and manageThe framework's lifecycle begins with defining strategy, where business and technical leaders align on outcomes and ownership for a business scenario, which is the step that secures the business-unit buy-in the previous programs lacked.
- BStart with the Adopt phase by deploying Conditional Access to all users and refine the strategy afterward based on help-desk ticketsDeploying controls before strategy and planning is what caused the earlier failures; the framework places Adopt after Define strategy, Plan, and Ready.
- CStart with the Govern and manage phase by publishing a Zero Trust policy and measuring Secure Score monthlyGovernance and measurement are the final, ongoing phase of the lifecycle; publishing a policy before stakeholders agree on outcomes does not create adoption.
- DStart by assessing all subscriptions against the Microsoft Cloud Security Benchmark and remediating the failed controlsMCSB is a control framework for cloud resources; it is useful inside the program but it is not the Zero Trust adoption framework lifecycle and does not address the organizational alignment problem.
Why: The Zero Trust adoption framework is a lifecycle, Define strategy, Plan, Ready, Adopt, Govern and manage, applied to a business scenario, and its first phase exists to align leaders on outcomes and ownership before any technology is deployed. The deciding constraint is the history of business units rejecting controls, which is an alignment failure that only the strategy phase addresses. The trap is the CISO's instinct to jump straight to Adopt with Conditional Access; the framework does not forbid quick wins, but it insists that strategy and planning come first so the controls have sponsors who will defend them.
Design solutions that align with the Microsoft Cybersecurity Reference Architectures (MCRA) and Microsoft Cloud Security Benchmark (MCSB)
Saltmarsh Utilities is adopting Zero Trust using the Microsoft Zero Trust adoption framework. The first initiative funded by the board is to make sure that if an attacker compromises one workstation or one account, the attacker cannot move freely across the network to the SCADA management systems and the finance servers. The architect must map this initiative to the correct business scenario in the framework so that the right guidance and stakeholders are used.
Which Zero Trust adoption framework business scenario applies?
- APrevent or reduce business damage from a breachThis business scenario covers assume-breach controls such as network segmentation, limiting lateral movement, and protecting privileged access so that a single compromise cannot spread, which is exactly the funded initiative.
- BSecure remote and hybrid workThis scenario focuses on identity, device, and application access for users working from anywhere, not on containing an attacker who is already inside.
- CIdentify and protect sensitive business dataThis scenario is about discovering, classifying, and protecting data with Microsoft Purview; it does not address lateral movement across network segments.
- DMeet regulatory and compliance requirementsThis scenario maps controls to regulations and reporting; segmentation might support compliance, but containment of a breach is not its primary objective.
Why: The Zero Trust adoption framework organizes work into business scenarios so that technical controls are tied to business outcomes and the right stakeholders. The initiative described, containing an attacker so a single compromise cannot reach critical systems, is the assume-breach outcome that the framework places under preventing or reducing business damage from a breach, which includes segmentation, privileged access, and threat protection. The deciding factor is the stated goal of stopping lateral movement rather than enabling remote users or classifying data. The trap is secure remote and hybrid work, which many teams pick first because it is where Conditional Access lives, but that scenario is about access, not containment.