Nordlicht Reisen GmbH, a fictional travel agency that you know from AZ-900 and AZ-104, ran a booking portal in Azure there. Now it is growing: the booking system, the database in its own data center, the partners and the sales team's wish for reports are to end up in an Azure solution that fits the company's requirements. Nobody sets up a service for that. Somebody has to recommend which service in which tier fits which requirement, and say why the alternatives are not chosen.
This is exactly how the AZ-305 exam is built, and exactly how this course is built. This lesson shows the form before the services come.
Prior knowledge. How you create a test account, keep an eye on costs and clean up is shown in "AZ-104, lesson 0.1"; that does not apply here, because this course deploys nothing. How to weigh a decision and write it down as an ADR is taught in "K4, lesson 4.1.3"; the Well-Architected Framework is covered in detail in "K4, lesson 4.7.1", quality goals in "K4, lesson 4.1.2". Here you read only as much of that as the exam's questions and this course's exercises need. Nothing of it is reprinted.
How a "Recommend" task is built
The study guide that Microsoft publishes for the exam names its skills in almost every line with the same word: Recommend a logging solution, Recommend an authentication solution, Recommend a high availability solution for compute. We read the list on the day of the source check; if Microsoft changes it, the assignment of the lessons changes. The profile of the role also says what it is about: architects advise stakeholders and translate business requirements into designs that fit the Well-Architected Framework and the Cloud Adoption Framework.
In the exam and on the job, such a task has five parts:
| Part | Question | Example from Nordlicht Reisen (for the form only) |
|---|---|---|
| Requirement | What must the solution deliver, and how do we measure it? | "Logs of the booking servers stay queryable for one year." (assumption of the task) |
| Constraint | What is given and not negotiable? | "Data stays in the EU." |
| Options | Which two or three services or tiers come into question? | Option A, option B |
| Tipping limit | Which property of a service rules out an option? | "Option B can't do that." |
| Justification and counter-question | Why this choice, and when would it tip? | "What if the requirement were twice as strict?" |
What matters is not the number of service names, but finding in a requirement the one sentence that rules out an option. In this course that sentence is called the tipping limit: a property by which a service doesn't meet a requirement, or meets it only from a certain tier. It always appears in the text with a source on Microsoft Learn.
An example of the form: diagnostic data is to go into a storage account. According to Microsoft, premium storage accounts are not supported as the destination of a diagnostic setting, standard storage accounts are. Whoever recommends a premium account because it is "faster" has not read the requirement. Lesson 1.1 works this out with the sources.
Where the yardsticks come from: WAF and CAF
Two Microsoft frameworks supply the yardsticks by which decisions are measured. Each has its own purpose.
The Azure Well-Architected Framework (WAF) is meant to improve the quality of a workload, that is, of a system like the booking portal. It rests on five pillars: Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency. Each pillar has design principles, checklists, tradeoffs and design patterns. Microsoft writes two sentences about it that hold for the whole course: Design decisions must be weighed across all pillars, measured against the business requirements. And: The architecture of a workload is not its implementation; the choice of implementation depends on the requirements and constraints of the organization.
The Cloud Adoption Framework (CAF), by contrast, addresses decision makers who adopt Azure across the whole organization. It arranges its advice in seven phases: Strategy, Plan, Ready, Adopt, Govern, Secure and Manage. The result is a landing zone (a prepared environment for workloads) with shared standards. For central controls across many workloads, the WAF itself points to the CAF.
In short: If it is about this one system, the WAF applies first (for example: must the portal survive the failure of a data center?). If it is about subscriptions, policies and tags for all systems of the group, the CAF applies first (lesson 1.5 and module A5).
Microsoft also advises a pragmatic approach: Every practice has a price in money, effort and complexity, and the maturity model with five levels is expressly a guideline, not a strict rule. A recommendation that ticks off every checklist is therefore not automatically good; it is good when it carries the requirements and names the tradeoff.
The course's method in six steps
Every lesson from A1 on takes the same path. You should take it with an exam task too.
- Read the requirements sheet. Lesson 0.2 sets the template. Every requirement has a number, a type, a measure and a weight.
- Pull out the must requirements. What is not negotiable decides first. Everything else sorts what is left.
- Name two or three options. A decision between one option and nothing is not a decision.
- Check the tipping limits. For each option: Which property fails a must requirement? That is where the source goes.
- Decide and answer the counter-question. "What if ...?" shows how stable the choice is.
- Name cost drivers and a trigger for review. What does the service bill by, and how do we notice that the decision has to be made again?
Step 4 demands sources. If you can't back a limit up, don't write "about" and don't write it from memory, but "Microsoft names no fixed limit for this" or "not verified".
Cost: cost drivers instead of prices
This course names no prices and no amounts. Prices change, depend on region, contract and volume, and a number in a lesson would be wrong the next day. Instead, every lesson names the cost drivers of a service: what it bills by. That can be time (per hour), volume (per gigabyte), instances, requests or provisioned throughput. The current amounts are on the service's pricing page and in the Azure pricing calculator. A cost frame in the requirements sheet therefore has no currency but a ranking, such as "costs fall before response time" (lesson 0.2).
The decision record and the Bicep sketch
A recommendation that exists only in your head is none. This course records it in the decision record (ADR, Architecture Decision Record), in the form from K4: context, options, decision, tradeoffs, consequences and "Review when". Microsoft's guidance advises using the same template, staying short and factual, and linking more justification instead of building it in. An accepted ADR is not rewritten; if the decision changes, a new one is created that replaces the old one (K4, lesson 4.1.3).
Where the decision is a resource (a workspace, a diagnostic setting, a role assignment), the solution includes a Bicep sketch: a few lines that show only what the decision fixes. It is the bridge from the record to the code. A tiny example for ADR-0001 of Nordlicht Reisen, which records the region of the task:
// ADR-0001: primary region germanywestcentral, data stays in the EU
@allowed([
'germanywestcentral'
])
param location string = 'germanywestcentral'
// The region is a parameter, not text in every resource.
// Any other value would not be an allowed value of this parameter.
resource decision 'Microsoft.Resources/tags@2021-04-01' = {
name: 'default'
properties: {
tags: {
adr: '0001'
region: location
}
}
}
Not deployed; translated locally with bicep build. That checks syntax and types, not whether a subscription allows the size, the name or the region.
If you want to translate the sketch yourself, do it locally and without any Azure call with bicep build adr-0001-region.bicep. That is a pointer for you; we ran the call when writing and show no output.
How you work with the exercises
All exercises of this course run on paper: in a Markdown file for the decision record and, where it fits, in a .bicep file. There are no costs, and no command runs against Azure.
Every exercise has a requirements sheet (all numbers are assumptions of the task, never measured values), a task and a How to check your result: list that you tick off yourself: no examiner, no points, no feedback from us. The solution is an example; read it only when your version is done. A different choice is right if its reasons carry the requirements.
Typical mistakes
- Naming the service instead of justifying it. "Azure SQL" is not an answer, "Azure SQL, because requirement X demands it and option Y doesn't meet it" is one. Check: Does your recommendation contain a "because" that points to a numbered requirement?
- The biggest or most expensive is the safest. A higher tier without a requirement is waste and violates the Cost Optimization pillar. Check: Which must requirement demands the higher tier?
- The requirement is not measurable. "Fast" and "secure" can't be decided. Check: Is there a measure, and is it marked as an assumption or a measured value?
- Framework as a checklist. The WAF expressly demands naming tradeoffs. Check: Which pillar pays for your choice?
- New means better. The study guide says that most questions concern generally available features and preview features appear only when they are widely used. Check: Is the feature your recommendation builds on generally available?
Exercise 1
You get five sentences as they come up in conversations about Nordlicht Reisen. All numbers are assumptions of the task.
Requirements sheet (excerpt)
| No. | Sentence |
|---|---|
| S-1 | "We'll take Azure SQL, everybody does." |
| S-2 | "The portal has to stay fast even in the summer wave." |
| S-3 | "Booking data must not leave the EU." |
| S-4 | "It mustn't get too expensive." |
| S-5 | "After an outage, the portal should be running again within 30 minutes." |
Task. Create a table. For each sentence: (a) requirement, constraint or solution? (b) Which WAF pillar does it affect most? (c) What is missing for a decision to be possible: measure, weight, source? (d) Which follow-up question do you ask?
How to check your result:
- Every sentence has exactly one of the three classifications, and S-1 is under "solution".
- For every sentence a pillar is named that carries its Microsoft designation.
- For every sentence with a missing measure there is a concrete follow-up question that asks for a number or a comparison.
- You did not recommend a service: This exercise decides nothing yet.
Solution 1
An example; a different assignment is right if your reasons carry it.
| No. | Classification | Pillar | What is missing | Follow-up question |
|---|---|---|---|---|
| S-1 | Solution (a service, not a requirement) | none to assign | the requirement that justifies the service | "Which requirement is Azure SQL supposed to meet, and which alternative was checked?" |
| S-2 | Requirement (quality) | Performance Efficiency | measure, load | "What response time at what number of concurrent users counts as fast?" |
| S-3 | Constraint | Security (data protection, rules of the organization) | source of the rule | "Does the rule apply to copies and logs too?" |
| S-4 | Requirement (cost frame) | Cost Optimization | ranking instead of amount | "What falls first when costs rise: availability, response time or scope of functions?" |
| S-5 | Requirement (quality) | Reliability | scope, weight | "Does the time apply to every outage or to the outage of one data center? Is it a must?" |
S-1 is the exam classic: A solution is passed off as a requirement. S-4 needs no currency, because the course keeps cost frames as a ranking.
Exercise 2
Write the first ADR of Nordlicht Reisen: Where do the new workloads run? The task fixes the answer, you justify it.
Requirements sheet
| No. | Requirement | Type | Measure (assumption of the task) | Weight |
|---|---|---|---|---|
| A-1 | Personal data stays in the EU. | Constraint | no processing outside the EU | Must |
| A-2 | The portal should be able to survive the failure of a data center in the same region. | Quality | failure of one zone, not of the whole region | Should |
| A-3 | A second region should be possible later. | Quality | region with a paired region in the geography | Could |
| A-4 | The data center in Hamburg stays in place for now. | Constraint | transition period | Must |
Options you weigh: A the region germanywestcentral (Frankfurt); B another region in the EU of your choice; C everything stays in the data center in Hamburg.
On Microsoft Learn, read the pages "Azure regions list" and "Azure region pairs and nonpaired regions". What counts is what they say for germanywestcentral.
Task. Write the ADR (context, options, decision, tradeoffs, consequences, review when). Add the Bicep sketch of the region that fixes the parameter.
How to check your result:
- Every statement about the region carries a source from Microsoft Learn: the number of availability zones, the paired region and its access status.
- For A-1 to A-4, the context or tradeoffs say whether the option meets them, doesn't meet them or leaves them open.
- Option C is in the ADR and has a justification that is not "the cloud is better".
- The decision names what stays open (the second region) instead of inventing it.
- There is no price and no invented number in the text.
Solution 2
An example; a different choice is right if its reasons carry the requirements.
ADR
# 0001: New workloads run in germanywestcentral
- Status: proposed
- Confidence: medium
## Context
Nordlicht Reisen processes booking data with personal data (A-1, Must: in the EU only). The portal should be able to survive the
failure of a data center in a region (A-2, Should). A second region should be possible later (A-3, Could). The Hamburg
data center stays in place during the transition period (A-4, Must).
## Options
### Option A: germanywestcentral (Frankfurt)
According to Microsoft's region list, the region has three availability zones; its paired region is Germany North (Berlin).
According to the legend, Germany North has restricted access and requires a request under Microsoft's procedure.
### Option B: another region in the EU
Meets A-1 just as well; the paired region of the chosen region would have to be checked first. No reason from the requirements speaks for it.
### Option C: everything stays in Hamburg
Meets A-1 and A-4 without change, A-2 and A-3 only with additional infrastructure of its own, which the task does not provide for.
## Decision
We take option A. It meets A-1 (EU), offers three availability zones for A-2 and leaves the data center in Hamburg untouched for A-4.
## Tradeoffs
We give up complete independence from one region. Whoever wants to cover outages of a whole region (A-3) has to clarify the
paired region: Germany North cannot be chosen freely, access is restricted. That is open and stays open in this ADR.
## Consequences
All resources of the task are in germanywestcentral. The region is a parameter in Bicep. The decision about a second
region becomes an ADR of its own (module A3).
## Review when
- A-3 goes from Could to Must,
- Microsoft changes the access rules for the paired region,
- the data center in Hamburg is to be shut down.
Bicep sketch
The sketch is further up in this lesson: It fixes the region as a parameter with exactly one allowed value and writes the number of the ADR as a tag on the group.
Not deployed; translated locally with bicep build. That checks syntax and types, not whether a subscription allows the size, the name or the region.
The ADR names the gap instead of filling it.
What you can do now
You break a task down into requirement, constraint, options, tipping limit and justification. You assign a decision to the Well-Architected Framework (quality of a workload) or to the Cloud Adoption Framework (adoption in the organization) and name the five pillars. You record a recommendation as an ADR, add a short Bicep sketch where it makes sense, and know what "not deployed" means. You name cost drivers instead of prices and use limits only with a source.
Further reading
- Study guide for Exam AZ-305:
https://learn.microsoft.com/credentials/certifications/resources/study-guides/az-305 - What is the Azure Well-Architected Framework?:
https://learn.microsoft.com/azure/well-architected/what-is-well-architected-framework - About the Well-Architected Framework pillars:
https://learn.microsoft.com/azure/well-architected/pillars - What is the Cloud Adoption Framework?:
https://learn.microsoft.com/azure/cloud-adoption-framework/overview - Architecture decision record:
https://learn.microsoft.com/azure/well-architected/architect-role/architecture-decision-record - Azure regions list:
https://learn.microsoft.com/azure/reliability/regions-list - Azure region pairs and nonpaired regions:
https://learn.microsoft.com/azure/reliability/regions-paired - Diagnostic settings in Azure Monitor (destinations and their limits):
https://learn.microsoft.com/azure/azure-monitor/platform/diagnostic-settings