Wie Sie Ihre Azure-Architekturkompetenz mit AZ-305 verbessern

AZ-305 ist die Zertifizierung für Architekturentscheidungen, die über den stabilen Betrieb einzelner Azure-Ressourcen und Dienste hinausgehen und Identität, Governance, Daten, Netzwerke, Business Continuity sowie Kosten zusammenführen.

Die Prüfung AZ-305: Designing Microsoft Azure Infrastructure Solutions richtet sich an Personen, die Azure-Lösungen entwerfen und begründen können. Entscheidend ist weniger das Auswendiglernen einzelner Dienste als die Fähigkeit, Anforderungen sauber zu lesen, Azure-native Optionen gegeneinander abzuwägen und daraus ein belastbares Design abzuleiten.

Was AZ-305 tatsächlich validiert

AZ-305 ist keine reine Administratorprüfung. Ein Azure Solutions Architect muss verstehen, wie technische Entscheidungen Geschäftsanforderungen beeinflussen: Verfügbarkeit, Sicherheit, Wiederherstellbarkeit, Compliance, Performance und Kosten stehen oft in Spannung zueinander. Eine Lösung mit maximaler Redundanz kann unnötig teuer sein; eine kostengünstige Lösung kann unzureichend sein, wenn sie die geforderte Wiederanlaufzeit nicht erfüllt.

Die Zertifizierung ist deshalb besonders relevant für erfahrene Azure-Administratoren, Cloud Engineers und Infrastrukturverantwortliche, die den Wechsel in eine Architekturrolle anstreben. Microsoft beschreibt für diese Rolle fortgeschrittene Kenntnisse in Administration, Netzwerk, Identität, Sicherheit, Business Continuity und Governance. Wer diese Grundlagen noch nicht sicher beherrscht, sollte zuerst die operative Ebene schließen; Microsoft-Trainings oder ein gezielter AZ-104-Zwischenschritt können dabei helfen, bevor AZ-305 sinnvoll angegangen wird.

Wichtig ist auch die Terminologie: Microsoft Entra ID ist die heutige Bezeichnung für den früheren Dienst Azure Active Directory. In älteren Unterlagen, Diskussionen oder Fragen kann der alte Name noch auftauchen, doch in der Architekturarbeit sollte die aktuelle Benennung verwendet werden.

Der Unterschied zwischen Lernen für Dienste und Lernen für Architektur

Ein häufiger Fehler in der Vorbereitung besteht darin, Azure-Dienste isoliert zu lernen. Für AZ-305 reicht es nicht, zu wissen, dass Azure Firewall, Private Link, Application Gateway, Storage Accounts oder Recovery Services Vaults existieren. Kandidaten müssen erkennen, wann welche Option angemessen ist und welche Folgen diese Entscheidung für Betrieb, Sicherheit und Kosten hat.

Ein nützlicher Ansatz ist, jede Übungsaufgabe wie eine Architekturentscheidung zu behandeln. Zunächst werden funktionale Anforderungen und nichtfunktionale Anforderungen wie RPO, RTO, Datenresidenz, Latenz, Budget, regulatorische Vorgaben und Betriebsmodell geklärt. Danach werden mehrere Azure-Optionen verglichen. Das Ergebnis lässt sich in einem kurzen Architecture Decision Record festhalten: Entscheidung, Alternativen, Begründung, Risiken und offene Annahmen. Diese Arbeitsweise hilft sowohl in Fallstudienfragen als auch in realen Projekten.

Beispielsweise ist „hochverfügbarer Storage“ keine ausreichende Anforderung. Ein Architekt muss klären, ob zonale Ausfallsicherheit innerhalb einer Region genügt, ob eine zweite Region benötigt wird und wie sich LRS, ZRS, GRS oder GZRS auf Wiederherstellung, Konsistenz, Kosten und Anwendungsdesign auswirken. Ebenso ist „sichere Datenbankanbindung“ keine fertige Lösung: Private Endpoint, Service Endpoint, Firewall-Regeln, DNS-Design und Netzwerksegmentierung führen zu unterschiedlichen Betriebs- und Sicherheitsprofilen.

Governance zuerst denken

Viele Azure-Designs scheitern nicht an der Auswahl eines Compute-Dienstes, sondern an zu spät geklärter Governance. Management Groups, Subscriptions, Ressourcengruppen, Namenskonventionen, Tags, Azure Policy, RBAC und Privileged Identity Management bestimmen, wie eine Umgebung später kontrolliert, auditiert und betrieben wird. Wer diese Struktur erst nach dem Workload-Design ergänzt, muss häufig Berechtigungen, Netzwerkgrenzen und Deployment-Prozesse nachträglich reparieren.

Für AZ-305 ist daher ein Governance-first-Denken hilfreich. Kandidaten sollten erklären können, warum Workloads getrennte Subscriptions benötigen können, wann ein zentrales Plattformteam Richtlinien vorgibt und wie Teams dennoch selbstständig deployen. Typische Stolpersteine liegen an Mandantengrenzen, uneinheitlichen Namenskonventionen, überprivilegierten Rollen und fehlenden Policies für Regionen, SKUs oder öffentliche Endpunkte. Ein vertiefender deutschsprachiger Einstieg in diese Themen ist der Leitfaden zu Azure Governance und Landing Zones.

Identity-Design ist dabei eng mit Governance verbunden. Rollen sollten nicht an einzelne Personen gebunden werden, wenn Gruppen und zeitlich begrenzte Berechtigungen sauberer sind. Microsoft Entra ID, RBAC, Conditional Access und PIM bilden zusammen den Rahmen, in dem Zugriff nachvollziehbar und überprüfbar bleibt.

Azure-Trade-offs, die Kandidaten beherrschen sollten

Die Prüfung fragt selten nach isolierten Produktdefinitionen. Häufig steht ein Szenario im Mittelpunkt: ein Unternehmen möchte Daten schützen, Standorte verbinden, Ausfälle überstehen, Kosten begrenzen oder regulatorische Anforderungen erfüllen. Die richtige Antwort ergibt sich aus dem Abgleich dieser Anforderungen mit Azure-Designoptionen.

Business Continuity verdient besondere Aufmerksamkeit. RPO und RTO sollten aus Geschäftsprozessen abgeleitet werden, nicht aus technischen Vorlieben. Backup schützt primär vor Datenverlust, während Disaster Recovery die Wiederaufnahme von Diensten nach einem größeren Ausfall plant. In Azure bedeutet das häufig eine Kombination aus Backup, Replikation, zonenfähiger Bereitstellung, Storage-Redundanz, Azure Site Recovery und getesteten Runbooks.

Monitoring und Kosten sind Teil des Designs

Monitoring wird in Projekten oft als nachgelagerte Betriebsaufgabe behandelt. Für AZ-305 ist es besser, es als Architekturentscheidung zu verstehen. Die Wahl der Log Analytics Workspace-Topologie beeinflusst Zugriff, Datenresidenz, Abfragen, Aufbewahrung, Kosten und die Zusammenarbeit zwischen Plattform- und Anwendungsteams.

Ein durchdachtes Design legt fest, welche Ressourcen Diagnoseeinstellungen senden, welche Daten tatsächlich benötigt werden und wie Data Collection Rules, Sampling, Aufbewahrungsfristen und Workbooks genutzt werden. Alerting über Action Groups sollte nicht nur technische Schwellwerte abbilden, sondern auch Verantwortlichkeiten und Eskalationswege. Wer Logdaten ungefiltert sammelt, erhält zwar Sichtbarkeit, riskiert aber unnötige Kosten und schwer wartbare Dashboards; für die Kostenperspektive lohnt sich ergänzend ein Blick auf Azure Kostenmanagement und FinOps.

Für die Prüfungsvorbereitung sollten Kandidaten außerdem Azure Monitor, Application Insights, Log Analytics und Network Watcher nicht als getrennte Lernblöcke betrachten. In realistischen Designs greifen diese Dienste ineinander: Telemetrie zeigt den Zustand einer Lösung, Alerts lösen Reaktionen aus, Workbooks visualisieren Trends, und Kostenanalysen zeigen, ob das Monitoring-Verhalten selbst optimiert werden muss.

Ein praktikabler Hands-on-Fahrplan

Praxisübungen müssen nicht groß sein, sollten aber Architekturentscheidungen erzwingen. Eine gute Übung beginnt mit einem kurzen Szenario, etwa einer geschäftskritischen Webanwendung mit privaten Datenbankverbindungen, klaren RPO- und RTO-Anforderungen und getrennten Umgebungen für Entwicklung und Produktion. Daraus entstehen konkrete Designfragen zu Netzwerk, Identität, Governance, Deployment, Monitoring und Kosten.

Ein sinnvoller Lernpfad kombiniert Microsoft Learn, das Azure Well-Architected Framework, eigene Lab-Umgebungen und wiederholbare Deployments. Wer strukturierte Labs und angeleitete Vorbereitung bevorzugt, kann das AZ-305 Training für Azure Solutions Architects als Ergänzung nutzen; der Kern bleibt jedoch die Fähigkeit, Entscheidungen im Szenario zu begründen.

Eine kleine, wiederholbare Übung ist das Bereitstellen einer Ressourcengruppe mit konsistenten Tags. Das wirkt einfach, trainiert aber zwei AZ-305-relevante Gedanken: Governance gehört an den Anfang, und Infrastructure as Code macht Architekturentscheidungen nachvollziehbar.

Beispiel — Ressourcengruppe mit Bicep und Governance-Tags

targetScope = 'subscription'

param location string = 'westeurope'
param workloadName string = 'claims-platform'
param environment string = 'test'

resource rg 'Microsoft.Resources/resourceGroups@2023-07-01' = {
  name: 'rg-${workloadName}-${environment}-${location}'
  location: location
  tags: {
    workload: workloadName
    environment: environment
    owner: 'platform-team'
    costCenter: 'shared-services'
  }
}

Dieses Beispiel zeigt keine vollständige Landing Zone, aber es macht das Prinzip sichtbar: Namensgebung, Verantwortlichkeit und Kostenbezug werden früh standardisiert. Im nächsten Schritt könnten Kandidaten Azure Policy für erlaubte Regionen ergänzen, RBAC-Zuweisungen prüfen und Diagnoseeinstellungen für zentrale Logs konfigurieren. Eine Einführung in wiederholbare Deployments bietet der Artikel zu Bicep und ARM für Infrastructure as Code.

Prüfungsmechanik und Vorbereitungstaktik

Die Bestehensgrenze für Microsoft-Zertifizierungsprüfungen liegt typischerweise bei 700 von 1000 Punkten; die offizielle Prüfungsseite bleibt maßgeblich für aktuelle Details. Kandidaten sollten mit verschiedenen Fragetypen rechnen, darunter szenariobasierte Aufgaben, Drag-and-Drop-Elemente, Multiple-Choice-Fragen und Fallstudien. Entscheidend ist, Anforderungen genau zu lesen und keine Annahmen zu ergänzen, die im Szenario nicht genannt werden.

Fallstudien verlangen besondere Disziplin. Oft enthalten sie Geschäftsanforderungen, technische Anforderungen, bestehende Umgebungen und Einschränkungen. Die passende Antwort ergibt sich aus dem Mapping dieser Abschnitte. Einige Prüfungsbereiche können nach dem Verlassen nicht mehr frei überarbeitet werden; deshalb ist Zeitmanagement wichtiger als hektisches Durchklicken.

• Nur Dienstnamen auswendig lernen, statt Anforderungen und Trade-offs zu üben.
• Governance, RBAC, Policy und Subscriptions erst nach dem Workload-Design betrachten.
• Zonen, Region Pairs und Storage-Redundanz ohne RPO- und RTO-Bezug auswählen.
• Log-, Monitoring- und Datenaufbewahrungskosten ignorieren.
• In Fallstudien Annahmen treffen, statt Aussagen aus dem Text konsequent zuzuordnen.
• Mit Exam Dumps lernen, statt ethisch und belastbar mit offiziellen Lernzielen, Labs und Übungsfragen zu arbeiten.

Eine gute Taktik ist, pro Prüfungsblock eine Zeitbox zu setzen, unsichere Fragen zu markieren und zuerst die Anforderungen mit klaren Schlüsselwörtern zu identifizieren: „must“, „minimize cost“, „no public access“, „least administrative effort“, „meet RTO“, „existing ExpressRoute“ oder „regulatory requirement“. Solche Formulierungen lenken die Architekturentscheidung oft stärker als der attraktivste Dienstname.

FAQ zur AZ-305-Vorbereitung

Ist AZ-104 Voraussetzung für AZ-305?

AZ-104 ist nicht als formale Voraussetzung in jedem Lernpfad zwingend, aber als Vorerfahrung sehr hilfreich. Wer Azure-Ressourcen, Netzwerke, Identität, Monitoring und Betrieb noch nicht praktisch administriert hat, wird sich mit AZ-305-Szenarien schwerer tun.

Wie sollte man mit Microsoft Learn lernen?

Microsoft Learn eignet sich am besten als strukturierte Grundlage für die offiziellen Skills. Kandidaten sollten die Module mit eigenen Labs verbinden, Architekturentscheidungen schriftlich begründen und regelmäßig die offizielle AZ-305-Seite prüfen, weil Microsoft Prüfungsinhalte aktualisieren kann.

Welche Themen werden häufig unterschätzt?

Unterschätzt werden vor allem Governance, Business Continuity, Netzwerkisolierung, Kostensteuerung und Monitoring-Design. Viele Kandidaten konzentrieren sich zu stark auf Compute- und Storage-Dienste, obwohl die Prüfung häufig nach dem Zusammenspiel mehrerer Architekturdomänen fragt.

Aus Prüfungsvorbereitung wird Architekturpraxis

AZ-305 belohnt strukturiertes Denken: Anforderungen klären, Azure-Optionen abwägen, Risiken dokumentieren und die Auswirkungen auf Betrieb, Sicherheit und Kosten erklären. Wer diesen Ansatz trainiert, bereitet sich nicht nur auf eine Prüfung vor, sondern entwickelt genau die Arbeitsweise, die in Architekturrollen erwartet wird.

Der nächste Schritt sollte eine ehrliche Standortbestimmung sein. Sind die operativen Grundlagen solide, kann der Fokus auf Szenarien, Designentscheidungen und Fallstudien liegen; bestehen noch Lücken, helfen gezielte Microsoft-Lernressourcen, Labs oder flexibles Microsoft-Training, bevor die Prüfungsbuchung sinnvoll ist. Wer eine konkrete Einschätzung zum passenden Lernweg benötigt, kann Kontakt aufnehmen, ohne die Vorbereitung auf eine reine Kursentscheidung zu reduzieren.