The Well-Architected and Cloud Adoption Frameworks: The Design Frame AZ-305 Assumes

Neither framework appears as a topic on the AZ-305 outline, and both are named in the audience profile. Microsoft describes the role as translating business requirements into Azure designs that line up with the Azure Well-Architected Framework and the Cloud Adoption Framework for Azure. That makes them the vocabulary your answers are argued in, not a chapter to revise.

Two frameworks, two scopes

The quickest way to stop confusing them is to notice that they answer different questions.

The Well-Architected Framework judges one workload. Is this design reliable enough, secure enough, affordable enough, operable enough, fast enough — and what did it give up to get there?

The Cloud Adoption Framework covers the organisation. Microsoft describes it as a structured roadmap for adopting Azure and fitting it into the IT estate an organisation already has (overview).

So a question about whether to use zone-redundant storage is a Well-Architected question. A question about how an enterprise should structure subscriptions before any workload arrives is closer to the Cloud Adoption Framework's territory. Both turn up on a design exam, because an architect works at both scales.

The five pillars, and why the trade-offs matter more than the list

Microsoft publishes five pillars, each with a workload concern of its own (pillars):

• Performance Efficiency — scalability, and testing under load.
• Operational Excellence — observability across the whole workload, and DevOps practice.
• Cost Optimization — cost modelling, budgets, and cutting waste.
• Security — protecting data, and detecting and mitigating threats.
• Reliability — resiliency, availability and recovery.

Learning that list takes ten minutes. It is also the least useful thing on the page.

What earns its place on a design exam is the second half of what Microsoft publishes for every pillar: alongside the design principles sits a set of trade-offs. That word is the whole reason the framework helps you here.

You cannot have all five at their maximum. Raising reliability usually means redundancy you pay for all year. Absorbing a demand spike means capacity that sits idle between spikes. Every additional security control is one more thing to configure and get wrong. Organisations differ in which of those costs they will accept — which is precisely why a design question can offer four workable options and still have one correct answer.

This is the connection worth carrying into the exam. When a scenario states a limit, it is telling you which pillar this organisation will not compromise on. The stated limit is the deciding constraint, and the pillar it belongs to tells you what kind of sentence to look for. We wrote that method up separately in how to read an Azure design question.

What the Cloud Adoption Framework contributes

The Cloud Adoption Framework organises Azure guidance into seven methodologies. The shape is more useful than the names.

Four of them run in order, and they are about getting an organisation into Azure at all: settling strategy, planning, readying the environment, and then adopting. Three more describe life once workloads are running: governing, securing and managing.

For a design decision, the useful question is which of those two situations the scenario is in. A company that has not moved yet has different correct answers from one that has forty workloads running and a compliance problem. The framework's sequencing is also why "we will sort out governance later" is a recognisable wrong answer — governance is an operational methodology that runs continuously, not a phase you finish.

How this shows up in practice

A worked shape, rather than a rule.

A scenario gives you a workload that must survive a regional outage, and a finance director who has capped monthly spend. Two pillars are now in direct tension: reliability wants a second region, cost optimization does not want to pay for one all year.

Nothing about Azure resolves that. The scenario resolves it, by telling you which limit is hard. If the spend ceiling is stated as immovable and the outage requirement is stated as "should", the answer sits lower on the redundancy ladder than your instincts want. If the outage requirement is a regulatory obligation and the budget is described as a target, it goes the other way.

An architect who never gives anything up has not made a decision. That sentence is the framework's actual content, and it is what the exam's verbs — recommend, specify, evaluate — are asking you to demonstrate.

What we would and would not spend time on

Our opinion, marked as ours.

Worth your time: the trade-off pages. Read the pillar you are weakest on and pay attention to what Microsoft says it costs you. That reading maps directly onto the sentences a scenario will state.

Worth knowing by shape: the Cloud Adoption Framework's sequence, and which methodologies are continuous rather than one-off.

Not worth memorising: the pillar list in order, or the seven methodology names as a recitation. No AZ-305 skill statement asks you to reproduce either. They are there so that when a scenario says "the platform team is two people", you recognise it as an Operational Excellence sentence and go looking for what that rules out.