Entscheiden statt einrichten: wie dieser Kurs und die Prüfung fragen

Die Nordlicht Reisen GmbH, die Sie aus AZ-900 und AZ-104 kennen, hat dort ein Buchungsportal in Azure betrieben. Jetzt wächst sie: Das Buchungssystem, die Datenbank im eigenen Rechenzentrum, die Partner und der Wunsch des Vertriebs nach Auswertungen sollen in eine Azure-Lösung münden, die zu den Anforderungen des Unternehmens passt. Dafür richtet niemand einen Dienst ein. Jemand muss empfehlen, welcher Dienst in welcher Stufe zu welcher Anforderung passt, und sagen, warum die Alternativen nicht gewählt werden.

Genau so ist die Prüfung AZ-305 gebaut, und genau so ist dieser Kurs gebaut. Diese Lektion zeigt die Form, bevor die Dienste kommen.

Vorwissen. Wie Sie ein Testkonto anlegen, Kosten im Blick behalten und aufräumen, zeigt „AZ-104, Lektion 0.1“; das gilt hier nicht, denn dieser Kurs stellt nichts bereit. Wie man eine Entscheidung abwägt und als ADR aufschreibt, lehrt „K4, Lektion 4.1.3“; das Well-Architected Framework steht ausführlich in „K4, Lektion 4.7.1“, Qualitätsziele in „K4, Lektion 4.1.2“. Hier lesen Sie davon nur das, was die Fragen der Prüfung und die Übungen dieses Kurses brauchen. Nichts davon wird nachgedruckt.

Wie eine „Recommend“-Aufgabe gebaut ist

Der Study guide, den Microsoft zur Prüfung veröffentlicht, nennt seine Fähigkeiten in fast jeder Zeile mit demselben Wort: Recommend a logging solution, Recommend an authentication solution, Recommend a high availability solution for compute. Wir haben die Liste am Tag der Quellenprüfung gelesen; ändert Microsoft sie, ändert sich die Zuordnung der Lektionen. Auch das Profil der Rolle sagt, worum es geht: Architektinnen und Architekten beraten Beteiligte und übersetzen fachliche Anforderungen in Entwürfe, die zum Well-Architected Framework und zum Cloud Adoption Framework passen.

Eine solche Aufgabe hat in der Prüfung und im Beruf fünf Teile:

Es kommt nicht auf die Zahl der Dienstnamen an, sondern darauf, aus einer Anforderung den einen Satz zu finden, der eine Option ausschließt. Dieser Satz heißt in diesem Kurs kippende Grenze: eine Eigenschaft, nach der ein Dienst eine Anforderung nicht oder erst ab einer Stufe erfüllt. Sie steht immer mit einer Quelle auf Microsoft Learn im Text.

Ein Beispiel für die Form: Diagnosedaten sollen in ein Speicherkonto. Nach Microsoft sind Premium-Speicherkonten als Ziel einer Diagnoseeinstellung nicht unterstützt, Standard-Speicherkonten schon. Wer ein Premium-Konto empfiehlt, weil es „schneller“ ist, hat die Anforderung nicht gelesen. Lektion 1.1 führt das mit den Quellen aus.

Wo die Maßstäbe herkommen: WAF und CAF

Zwei Rahmenwerke von Microsoft liefern die Maßstäbe, an denen Entscheidungen gemessen werden. Beide haben ihren eigenen Zweck.

Das Azure Well-Architected Framework (WAF) soll die Qualität einer Arbeitslast verbessern, also eines Systems wie des Buchungsportals. Es beruht auf fünf Säulen: Reliability (Zuverlässigkeit), Security (Sicherheit), Cost Optimization (Kostenoptimierung), Operational Excellence (betriebliche Exzellenz) und Performance Efficiency (Leistungseffizienz). Jede Säule hat Entwurfsprinzipien, Prüflisten, Zielkonflikte und Entwurfsmuster. Microsoft schreibt dazu zwei Sätze, die für den ganzen Kurs gelten: Entwurfsentscheidungen müssen über alle Säulen hinweg abgewogen werden, gemessen an den fachlichen Anforderungen. Und: Die Architektur einer Arbeitslast ist nicht ihre Umsetzung; die Wahl der Umsetzung hängt von den Anforderungen und Randbedingungen der Organisation ab.

Das Cloud Adoption Framework (CAF) richtet sich dagegen an Entscheiderinnen und Entscheider, die Azure in der ganzen Organisation einführen. Es ordnet seinen Rat in sieben Phasen: Strategy, Plan, Ready, Adopt, Govern, Secure und Manage. Das Ergebnis ist eine Landing Zone (eine vorbereitete Umgebung für Arbeitslasten) mit gemeinsamen Standards. Das WAF selbst verweist für zentrale Kontrollen über viele Arbeitslasten auf das CAF.

Kurz: Geht es um dieses eine System, gilt zuerst das WAF (etwa: muss das Portal den Ausfall eines Rechenzentrums überstehen?). Geht es um Abonnements, Richtlinien und Tags für alle Systeme der Gruppe, gilt zuerst das CAF (Lektion 1.5 und Modul A5).

Microsoft rät außerdem zu einem pragmatischen Vorgehen: Jede Praxis hat einen Preis in Geld, Aufwand und Komplexität, und das Reifegradmodell mit fünf Stufen ist ausdrücklich eine Richtschnur, keine strenge Regel. Eine Empfehlung, die jede Prüfliste abhakt, ist deshalb nicht automatisch gut; sie ist gut, wenn sie die Anforderungen trägt und den Zielkonflikt benennt.

Die Methode des Kurses in sechs Schritten

Jede Lektion ab A1 geht denselben Weg. Sie sollten ihn auch bei einer Aufgabe in der Prüfung gehen.

1. Das Anforderungsblatt lesen. Lektion 0.2 legt die Vorlage fest. Jede Anforderung hat eine Nummer, eine Art, eine Messgröße und ein Gewicht.
2. Die Muss-Anforderungen herausziehen. Was nicht verhandelbar ist, entscheidet zuerst. Alles andere sortiert, was übrig bleibt.
3. Zwei bis drei Optionen nennen. Eine Entscheidung zwischen einer Option und nichts ist keine Entscheidung.
4. Die kippenden Grenzen prüfen. Für jede Option: Welche Eigenschaft erfüllt eine Muss-Anforderung nicht? Dort steht die Quelle.
5. Entscheiden und die Gegenfrage beantworten. „Was wäre, wenn …?“ zeigt, wie stabil die Wahl ist.
6. Kostentreiber und Überprüfungsanlass nennen. Wonach rechnet der Dienst ab, und woran merken wir, dass die Entscheidung neu zu treffen ist?

Schritt 4 verlangt Quellen. Können Sie eine Grenze nicht belegen, schreiben Sie nicht „ungefähr“ und nicht aus dem Gedächtnis, sondern „Microsoft nennt dazu keine feste Grenze“ oder „nicht geprüft“.

Kosten: Kostentreiber statt Preise

Dieser Kurs nennt keine Preise und keine Beträge. Preise ändern sich, hängen von Region, Vertrag und Menge ab, und eine Zahl in einer Lektion wäre am nächsten Tag falsch. Stattdessen nennt jede Lektion die Kostentreiber eines Dienstes: wonach er abrechnet. Das können Zeit (je Stunde), Menge (je Gigabyte), Instanzen, Anfragen oder bereitgestellter Durchsatz sein. Die aktuellen Beträge stehen auf der Preisseite des Dienstes und im Preisrechner von Azure. Ein Kostenrahmen im Anforderungsblatt hat deshalb keine Währungsangabe, sondern eine Rangfolge, etwa „Kosten sinken vor Reaktionszeit“ (Lektion 0.2).

Die Entscheidungsnotiz und die Bicep-Skizze

Eine Empfehlung, die nur im Kopf steht, ist keine. Dieser Kurs hält sie in der Entscheidungsnotiz (ADR, Architecture Decision Record) fest, in der Form aus K4: Kontext, Optionen, Entscheidung, Abwägungen, Folgen und „Überprüfen, wenn“. Microsofts Leitfaden rät, dieselbe Vorlage zu nehmen, kurz und sachlich zu bleiben und mehr Begründung zu verlinken statt einzubauen. Ein angenommenes ADR wird nicht umgeschrieben; ändert sich die Entscheidung, entsteht ein neues, das das alte ersetzt (K4, Lektion 4.1.3).

Wo die Entscheidung eine Ressource ist (ein Arbeitsbereich, eine Diagnoseeinstellung, eine Rollenzuweisung), gehört zur Lösung eine Bicep-Skizze: wenige Zeilen, die nur zeigen, was die Entscheidung festlegt. Sie ist die Brücke von der Notiz zum Code. Ein winziges Beispiel für ADR-0001 der Nordlicht Reisen, das die Region der Aufgabe festhält:

// ADR-0001: Primärregion germanywestcentral, Daten bleiben in der EU
@allowed([
  'germanywestcentral'
])
param location string = 'germanywestcentral'

// Die Region steht als Parameter, nicht als Text in jeder Ressource.
// Jeder andere Wert wäre kein erlaubter Wert dieses Parameters.
resource decision 'Microsoft.Resources/tags@2021-04-01' = {
  name: 'default'
  properties: {
    tags: {
      adr: '0001'
      region: location
    }
  }
}

Nicht bereitgestellt; lokal mit bicep build übersetzt. Das prüft Syntax und Typen, nicht, ob ein Abonnement die Größe, den Namen oder die Region zulässt.

Wer die Skizze selbst übersetzen will, tut das lokal und ohne Azure-Aufruf mit bicep build adr-0001-region.bicep. Das ist ein Verweis für Sie; wir haben den Aufruf beim Schreiben ausgeführt und zeigen keine Ausgabe.

So arbeiten Sie mit den Übungen

Alle Übungen dieses Kurses laufen auf Papier: in einer Markdown-Datei für die Entscheidungsnotiz und, wo es passt, in einer .bicep-Datei. Es entstehen keine Kosten, und kein Befehl läuft gegen Azure.

Jede Übung hat ein Anforderungsblatt (alle Zahlen sind Annahmen der Aufgabe, nie Messwerte), eine Aufgabe und eine Liste So prüfen Sie es, gegen die Sie selbst abhaken: kein Prüfer, keine Punkte, keine Rückmeldung von uns. Die Lösung ist ein Beispiel; lesen Sie sie erst, wenn Ihre Fassung steht. Eine andere Wahl ist richtig, wenn ihre Gründe die Anforderungen tragen.

Typische Denkfehler

• Den Dienst nennen, statt zu begründen. „Azure SQL“ ist keine Antwort, „Azure SQL, weil die Anforderung X verlangt und die Option Y sie nicht erfüllt“ ist eine. Prüfen Sie: Steht in Ihrer Empfehlung ein „weil“, das auf eine nummerierte Anforderung zeigt?
• Das Größte oder Teuerste ist das Sicherste. Eine höhere Stufe ohne Anforderung ist Verschwendung und verletzt die Säule Cost Optimization. Prüfen Sie: Welche Muss-Anforderung verlangt die höhere Stufe?
• Die Anforderung ist nicht messbar. „Schnell“ und „sicher“ lassen sich nicht entscheiden. Prüfen Sie: Gibt es eine Messgröße, und ist sie als Annahme oder als Messwert gekennzeichnet?
• Rahmenwerk als Abhakliste. Das WAF verlangt ausdrücklich, Zielkonflikte zu benennen. Prüfen Sie: Welche Säule bezahlt für Ihre Wahl?
• Neu heißt besser. Der Study guide sagt, dass die meisten Fragen allgemein verfügbare Funktionen betreffen und Vorschaufunktionen nur vorkommen, wenn sie weit verbreitet sind. Prüfen Sie: Ist die Funktion, auf die Ihre Empfehlung baut, allgemein verfügbar?

# 0001: Neue Arbeitslasten laufen in germanywestcentral

- Status: vorgeschlagen
- Zuversicht: mittel

## Kontext

Die Nordlicht Reisen verarbeitet Buchungsdaten mit Personenbezug (A-1, Muss: nur in der EU). Das Portal soll den Ausfall eines
Rechenzentrums einer Region überstehen können (A-2, Soll). Eine zweite Region soll später möglich sein (A-3, Kann). Das Hamburger
Rechenzentrum bleibt in der Übergangszeit bestehen (A-4, Muss).

## Optionen

### Option A: germanywestcentral (Frankfurt)

Nach der Regionenliste von Microsoft hat die Region drei Verfügbarkeitszonen; ihre Partnerregion ist Germany North (Berlin).
Germany North ist laut Legende für den Zugang eingeschränkt und braucht eine Anfrage nach dem Verfahren von Microsoft.

### Option B: eine andere Region der EU

Erfüllt A-1 ebenso; die Partnerregion der gewählten Region wäre erst zu prüfen. Kein Grund aus den Anforderungen spricht dafür.

### Option C: alles bleibt in Hamburg

Erfüllt A-1 und A-4 ohne Änderung, A-2 und A-3 nur mit eigener zusätzlicher Infrastruktur, die die Aufgabe nicht vorsieht.

## Entscheidung

Wir nehmen Option A. Sie erfüllt A-1 (EU), bietet drei Verfügbarkeitszonen für A-2 und lässt das Rechenzentrum in Hamburg für A-4
unberührt.

## Abwägungen

Wir geben die vollständige Unabhängigkeit von einer Region auf. Wer Ausfälle einer ganzen Region abdecken will (A-3), muss die
Partnerregion klären: Germany North ist nicht frei wählbar, der Zugang ist eingeschränkt. Das ist offen und bleibt es in diesem ADR.

## Folgen

Alle Ressourcen der Aufgabe stehen in germanywestcentral. Die Region steht als Parameter in Bicep. Die Entscheidung über eine zweite
Region wird ein eigenes ADR (Modul A3).

## Überprüfen, wenn

- A-3 vom Kann zum Muss wird,
- Microsoft die Zugangsregeln für die Partnerregion ändert,
- das Rechenzentrum in Hamburg abgeschaltet werden soll.

Was Sie jetzt können

Sie zerlegen eine Aufgabe in Anforderung, Randbedingung, Optionen, kippende Grenze und Begründung. Sie ordnen eine Entscheidung dem Well-Architected Framework (Qualität einer Arbeitslast) oder dem Cloud Adoption Framework (Einführung in der Organisation) zu und nennen die fünf Säulen. Sie halten eine Empfehlung als ADR fest, schreiben dazu, wo sinnvoll, eine kurze Bicep-Skizze und wissen, was „nicht bereitgestellt“ heißt. Sie nennen Kostentreiber statt Preise und verwenden Grenzen nur mit Quelle.

Weiterlesen

• 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 (Ziele und ihre Grenzen): https://learn.microsoft.com/azure/azure-monitor/platform/diagnostic-settings