SC-100 - Design Solutions that Align with Security Best Practices and Priorities (23% of the exam) - Section 1.3

Design solutions that align with the Microsoft Cloud Adoption Framework for Azure (CAF) and the Azure Well-Architected Framework (WAF).

Describe how the Microsoft Cloud Adoption Framework for Azure (CAF) and Azure Well-Architected Framework (WAF) provide complementary guidance for embedding security governance into cloud strategy and workload design. Recognise how Azure landing zones and DevSecOps practices operationalise these frameworks across an organisation's adoption journey.

Microsoft Cloud Adoption Framework for Azure (CAF)Azure Well-Architected Framework (WAF)Azure landing zonesDevSecOpssecurity governance

Practice question for this objective

Free sampleDesign Solutions that Align with Security Best Practices and Prioritiesmedium

An enterprise is starting a large Azure migration and wants a single source of guidance for sequencing the whole cloud journey, including how security governance is established as the estate grows. A separate body of guidance is needed to assess whether each individual workload is designed soundly against security, reliability and cost. Which framing correctly assigns the Microsoft Cloud Adoption Framework for Azure and the Azure Well-Architected Framework to these two needs?

AThe Cloud Adoption Framework guides the end-to-end adoption journey including security governance as the estate scales, while the Well-Architected Framework assesses an individual workload against pillars such as security and reliability. Correct
BThe Cloud Adoption Framework evaluates an individual workload against the security and reliability pillars, while the Well-Architected Framework sequences the overall organisational adoption journey and governance.
CBoth frameworks assess an individual workload against design pillars, so the architect should pick whichever one the chosen Azure landing zone accelerator happens to reference first.
DBoth frameworks describe the same adoption journey, so the architect should follow only the Well-Architected Framework and treat the Cloud Adoption Framework as an optional summary of it.

Use the Cloud Adoption Framework for the organisation-wide adoption journey and governance, and the Well-Architected Framework to assess individual workload design. The Microsoft Cloud Adoption Framework for Azure spans strategy, plan, ready, govern and secure across the whole estate, establishing governance as adoption scales, while the Azure Well-Architected Framework evaluates a single workload against its five pillars including security. Matching each need to the right framework avoids applying workload-level pillar reviews to organisation-level governance decisions.

Why A is correct: This is the correct division of responsibility because the Cloud Adoption Framework sequences strategy, governance and platform readiness across the organisation, whereas the Well-Architected Framework reviews a specific workload against its security and reliability pillars.

Why B is wrong: This reverses the two frameworks and is tempting because both mention security, but the Cloud Adoption Framework drives the organisation-wide journey and the Well-Architected Framework assesses individual workloads, so the assignment is inverted.

Why C is wrong: Treating both as workload assessments is appealing because they share pillar vocabulary, but only the Well-Architected Framework reviews a single workload while the Cloud Adoption Framework governs the broader journey, so this conflates two distinct purposes.

Why D is wrong: Collapsing the two into one journey is tempting for simplicity, but the frameworks operate at different altitudes and the Cloud Adoption Framework is not a summary of the Well-Architected Framework, so discarding it loses the organisation-wide governance guidance.

See more SC-100 practice questions, answers explained.

Exam traps in Design Solutions that Align with Security Best Practices and Priorities

Answers that look right on this material and are not. Each one is a distractor from a different question in the SC-100 bank for this domain.

Each cloud needs its own provider-specific baseline because the MCSB expresses controls only for Azure resources and cannot be assessed against Amazon Web Services or Google Cloud workloads.
Why it is wrong: This is tempting because the benchmark originated in an Azure context, but the MCSB is explicitly designed as a cloud-agnostic control set and Defender for Cloud assesses it across the other major clouds, so separate provider baselines are not required.
Expand the central security team and add a second mandatory review board so that two independent approvals are required before any release reaches production.
Why it is wrong: Adding review boards strengthens oversight and is tempting because it looks rigorous, but it deepens the late-stage gate and keeps ownership outside the delivery teams, which is the opposite of the shared-responsibility model DevSecOps calls for.
Rely on the management group Azure Policy deny assignments to reject non-compliant resources at deployment time, and treat the failed deployment as the security validation for each release.
Why it is wrong: Inherited deny policies are genuine guardrails and tempting because they do block bad resources, but they fire only when the deployment reaches Azure, so the failure surfaces late and after merge rather than catching the definition before deployment as the requirement demands.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.