How to Read an Azure Design Question: Finding the Constraint That Decides It

Read the four options before you read the scenario. A design question usually offers several services that would all run the workload, plus one sentence that makes most of them impossible. Knowing what separates the options tells you which sentence you are hunting for — and the set of things that separate them is small.

Why the options come first

It feels wrong. Every reading habit you have says start at the beginning.

But the paragraph is mostly furniture. It names a company, an industry, a headcount, a region, a deadline and a budget, and most of that settles nothing. If you read it cold you absorb all of it and weight none of it.

The options tell you what the question is actually about. Four options that differ in how fast a service recovers are asking a recovery question. Four that differ in who can read the data are asking a residency or access question. Once you know which, you can go back to the paragraph looking for one line instead of re-reading six.

The small set of axes

Microsoft publishes five pillars in the Azure Well-Architected Framework, and each names a different way a design can be asked to be good:

Pillar	What it worries about
Reliability	resiliency, availability, recovery
Security	data protection, and detecting and mitigating threats
Cost Optimization	cost modelling, budgets, and reducing waste
Operational Excellence	observability across the whole workload, and DevOps practice
Performance Efficiency	scalability, and load testing

We use them as a vocabulary rather than as a topic. No AZ-305 skill statement says "know the Well-Architected Framework" — but a scenario that hands you a monthly ceiling is asking a Cost Optimization question whatever service it names, and one that says a small team has to run the result is asking an Operational Excellence question.

Naming the pillar is the step that repays practice, because the axes repeat. Once "these two options differ only in how fast the service comes back" reliably makes you think recovery objective, you stop re-deriving each scenario from scratch.

The five-step read

This is our method rather than Microsoft's, derived from the shape of the exam's own verbs. Every skill statement in the study guide opens with Recommend, Specify or Evaluate, and those are three different tasks.

1. Read the last line. It names the decision being asked for. A recommendation, a specification, and an evaluation of somebody else's plan are not the same job.
2. Read the four options and ask how they differ. Not which is right. What axis separates them — layer, scope, region, service tier, managed against self-run, cost model.
3. Name the pillar that axis belongs to. This is the step most people skip, and it is the one that turns a long paragraph into a short search.
4. Go back and find the sentence about that pillar. You now know what you are looking for, and it is usually one line.
5. Check the survivors against the constraint you have not used yet. Most items carry a second limit, and it is what eliminates the runner-up.

Step five is worth dwelling on. When two options survive step four, the temptation is to pick the better-sounding one. There is almost always a second stated fact that settles it properly.

Four ways a correct answer is still wrong

The hardest items do not offer a wrong answer. They offer four workable ones and let you disqualify yourself. In our experience writing and reviewing design items, four patterns account for most of it.

Over-engineering. The option is more available, more redundant or more global than anything the scenario asked for — and the scenario named a budget. Look for a spend ceiling stated early and then apparently forgotten.

Wrong scope. The mechanism is right and the level is wrong: a control applied per resource when the requirement said every subscription, including ones created later. Watch for the words future, new, or at scale.

Right tool, wrong workload. The service genuinely does that job, but for a different resource type or protocol than the one in front of you. This one catches people who know Azure well, because the association is strong and nearly right.

Ignoring the stated prohibition. The scenario says no code changes, or no inbound ports, or the data must not leave the country. The option is otherwise ideal. The prohibition usually appears once, in a subordinate clause.

All four share a shape: the option is a better design and a worse answer. If you catch yourself justifying a choice on grounds the scenario never raised — it scales further, it is more resilient — stop and look for the limit you are stepping over.

Worked example

A logistics company runs a nightly route-optimisation job. It is idle for twenty hours a day, then runs hard for about four. Runs occasionally exceed four hours. The finance director has capped monthly spend on this workload and will not approve an increase. The platform team is two people. Which compute recommendation fits?

Step one: the task is a recommendation, and the subject is compute.

Step two: the options will differ on hosting model — always-on machines, a scale-out service, a serverless option, a batch service.

Step three: that axis is Cost Optimization and Performance Efficiency, with Operational Excellence in play because the team is two people.

Step four: the sentences about those pillars are the capped spend and the twenty idle hours. So anything billed around the clock is out.

Step five: the elastic options survive, and the second constraint separates them — runs occasionally exceed four hours eliminates any option with a shorter execution ceiling, and a two-person team argues against the most hands-on of what is left.

Notice where the work happened. In the options, and in two sentences. The company, the industry and the purpose of the job never mattered at all.

Practising it

The method only becomes fast if step three stops feeling like a step, and that takes repetition against items that state their constraints honestly.

Two things we would look for in whatever you practise with. First, does the explanation name which sentence eliminated each wrong option — not merely that it was wrong? Second, does it say which pillar the distractor confuses? An answer key that only tells you the letter has taught you nothing you can reuse on the next question.