Azure Solutions Architect: Karrierewege nach bestandener AZ-305

• AZ-305 bestanden oder kurz davor.
• Rollen wie Azure Solutions Architect, Cloud Architect oder Platform Engineer realistisch einordnen.
• Nächste Schritte für Bewerbung, Projektverantwortung und Weiterbildung in DE/AT/CH planen.

Microsoft Certified: Azure Solutions Architect Expert bezeichnet den Zertifizierungsstatus für Fachleute, die Azure-Lösungen entwerfen und dafür unter anderem AZ-305 sowie die Voraussetzungen im Microsoft-Zertifizierungspfad berücksichtigen. Dieser Beitrag berücksichtigt den aktuellen Pfad rund um AZ-305, AZ-104 und diesen Expert-Status. Prüfungsinhalte und Rezertifizierungsregeln können sich ändern; verbindlich bleiben die Angaben auf Microsoft Learn.

Nach dem Bestehen von AZ-305 beginnt für viele Azure-Administratoren, Entwickler und Engineers die schwierigere Phase: Die Zertifizierung muss in eine klare Rolle, belastbare Architekturartefakte und sichtbaren geschäftlichen Nutzen übersetzt werden. In der DACH-Region zählt dabei selten allein das Zertifikat. Häufig werden Deutschkenntnisse, Datenschutzverständnis, Erfahrung mit hybriden Umgebungen und ein sicherer Umgang mit Governance-Anforderungen ebenso genau geprüft wie Azure-Fachwissen.

Was AZ-305 fachlich aussagt

Die Prüfung Designing Microsoft Azure Infrastructure Solutions bewertet, ob Kandidaten Azure-Infrastrukturlösungen entwerfen können, die Geschäftsanforderungen, Sicherheit, Governance, Datenplattformen, Netzwerke und Betrieb zusammenführen. Sie ist keine reine Produktprüfung. Wer sie besteht, sollte erklären können, warum eine Architektur gewählt wurde, welche Risiken akzeptiert werden und welche betrieblichen Konsequenzen daraus entstehen.

Im Microsoft-Zertifizierungspfad steht AZ-305 eng neben der Administrator-Perspektive. Der Status Microsoft Certified: Azure Solutions Architect Expert wird mit AZ-305 und der passenden Administrator-Zertifizierung erreicht. Die Azure Administrator-Zertifizierung bleibt deshalb mehr als eine Vorstufe: Sie liefert die operative Grundlage, um Architekturentscheidungen nicht an der Realität von Identitäten, Netzwerken, Monitoring und Betrieb vorbei zu treffen.

Der praktische Wert von AZ-305 liegt in der Verbindung von Design und Verantwortung. Ein Azure Solutions Architect muss Landing Zones, Netzwerkzonen, Identity-Modelle, RBAC, Backup, Disaster Recovery, Kostenkontrollen und Compliance so zusammenbringen, dass ein System über den Go-live hinaus steuerbar bleibt. Eine Landing Zone ist dabei kein einzelnes Template, sondern eine vorbereitete Cloud-Umgebung mit Netzwerk-, Identitäts-, Sicherheits-, Governance- und Betriebsgrundlagen. Policy-as-Code bedeutet, dass Regeln für Ressourcen, Tags, Regionen oder Sicherheitskonfigurationen versioniert und automatisiert geprüft werden. RBAC beschreibt rollenbasierte Berechtigungen; privilegierte Identitäten und zeitlich begrenzte Admin-Rechte müssen davon getrennt betrachtet werden.

Welche Rollen nach AZ-305 wirklich naheliegen

Nach AZ-305 ist „Architekt“ kein einheitliches Berufsbild. In Stellenausschreibungen im deutschsprachigen Markt überschneiden sich Begriffe wie Cloud Architect, Azure Solutions Architect, Enterprise Architect, Platform Engineer und DevOps Engineer häufig. Entscheidend ist weniger der Titel als die Art der Verantwortung: Wer Anforderungen moderiert, Zielarchitekturen beschreibt und Risiken bewertet, arbeitet anders als jemand, der Terraform-Module baut, Pipelines betreibt oder Datenmodelle entwirft.

Ein Solutions Architect verbringt viel Zeit mit Stakeholder-Alignment, Entscheidungsunterlagen, Architekturreviews und der Übersetzung von Geschäftsanforderungen in technische Optionen. Typische Artefakte sind Referenzarchitekturen, Zielbilder, Risikoannahmen, BCDR-Konzepte, Kostenmodelle und Governance-Entscheidungen. Erfolg wird oft daran gemessen, ob Architekturentscheidungen nachvollziehbar sind, Sicherheits- und Compliance-Anforderungen erfüllt werden und Projekte ohne unnötige Reibung in den Betrieb übergehen.

Platform Engineers und DevOps Engineers arbeiten näher an Build- und Run-Prozessen. Ihr Schwerpunkt liegt auf Infrastructure as Code mit Bicep oder Terraform, GitOps-Workflows, CI/CD-Pipelines, Policy-as-Code, Observability und wiederverwendbaren Plattformmodulen. Für diesen Weg ist die DevOps Engineer Expert-Zertifizierung ein naheliegender Anschluss, weil sie stärker auf Delivery, Automatisierung und Betriebsreife ausgerichtet ist.

Data Architects und Data Engineers bewegen sich dagegen näher an Domänen, Speicherdesign, Integrationsmustern, Datenqualität und Analyseanforderungen. Wer nach AZ-305 merkt, dass Datenplattformen, Lakehouse-Architekturen, Governance von Datenprodukten oder Analytics-Workloads im Vordergrund stehen, sollte seine Lücken anders schließen als jemand, der in Richtung Platform Engineering geht. Für Entwickler mit starkem Applikationsfokus kann auch die Azure Developer Associate-Zertifizierung helfen, Architekturentscheidungen näher an Code, APIs, Messaging und Deployment-Modellen auszurichten.

Der DACH-Arbeitsmarkt: was zusätzlich zählt

In Deutschland, Österreich und der Schweiz sind Azure-Architekturrollen besonders in regulierten und integrationsintensiven Branchen sichtbar, etwa Finanzdienstleistungen, Gesundheitswesen, öffentlicher Sektor, Industrie und Professional Services. In diesen Umgebungen werden Cloud-Designs selten als reine Public-Cloud-Übung behandelt. Standortanforderungen, Datenschutz, Mandantentrennung, Netzwerksegmentierung, Identity Federation, Auditierbarkeit und Legacy-Integration prägen viele Projekte.

Hiring Manager achten deshalb häufig auf Nachweise, die über Zertifikate hinausgehen. Eine Bewerbung wirkt stärker, wenn sie konkrete Architekturartefakte enthält: ein anonymisiertes Landing-Zone-Konzept, ein BCDR-Runbook mit RTO- und RPO-Annahmen, ein FinOps-Kostenmodell, ein RBAC-Entwurf für mehrere Teams oder ein IaC-Repository mit wiederverwendbaren Modulen. Recruiter können Zertifizierungen schnell erkennen; technische Entscheider reagieren eher auf Artefakte, die zeigen, wie jemand Abwägungen dokumentiert und Risiken kontrolliert.

Gehaltsaussagen sollten vorsichtig gelesen werden. Quellen wie StepStone und Glassdoor DE geben Anhaltspunkte für Marktspannen, bilden aber selten die Unterschiede zwischen interner Rolle, Beratung, Personalverantwortung, Branche, Region, Projektrisiko und Sprachprofil vollständig ab. Für Bewerber ist daher sinnvoller, die eigene Verhandlungsposition über Verantwortungsumfang zu beschreiben: Architekturverantwortung für produktive Plattformen, Regulierungskontext, Budget- oder Kostenkontrolle, Migrationserfahrung, Sicherheitsdesign und Betriebserfahrung.

Häufige Übergangsfehler nach der Zertifizierung

Ein häufiger Fehler besteht darin, eine Architektur als Liste von Azure-Diensten zu präsentieren. In Projekten zählt jedoch die Begründung: Welche Verfügbarkeitsanforderung gibt es, welche Daten dürfen wo liegen, welche RTO- und RPO-Werte sind realistisch, welche Identitäten verwalten privilegierte Aktionen, wie werden Kosten begrenzt und wie wird die Lösung im Betrieb beobachtet? Ohne diese Nichtfunktionalen bleibt ein Design unvollständig, auch wenn die einzelnen Dienste korrekt gewählt sind.

Ein zweiter Übergangsfehler betrifft Governance und FinOps. Tags, Budgets, Alerts, Richtlinien, Namenskonventionen und Verantwortlichkeiten wirken weniger sichtbar als Netzwerke oder Datenbanken, entscheiden aber über Skalierbarkeit im Alltag. Gerade in hybriden Unternehmen mit mehreren Business Units und externen Dienstleistern wird schnell unklar, wer Build, Run, Security, Kostenfreigaben und Ausnahmeentscheidungen verantwortet. Gute Architekturarbeit macht diese Grenzen früh sichtbar.

Auch Business Continuity und Disaster Recovery werden oft zu spät konkretisiert. Backup ist keine vollständige DR-Strategie, und eine replizierte Datenbank beantwortet noch nicht die Frage, wie Anwendungen, Identitäten, Netzwerke, Schlüssel, DNS, Monitoring und operative Runbooks im Ausfall zusammenspielen. Eine anonymisierte DACH-Fallskizze zeigt das Muster: Ein Industrieunternehmen mit zentralem ERP, mehreren Standorten und Azure-Workloads musste nicht zuerst mehr Dienste auswählen, sondern RTO/RPO pro Geschäftsprozess festlegen, Identity-Failover prüfen, Netzwerkpfade dokumentieren und Kosten für Warm-Standby gegenüber manueller Wiederherstellung abwägen. Erst danach war klar, welche Architektur angemessen war.

Die ersten 90 Tage in einer Architektenrolle

Die ersten Monate nach AZ-305 sollten nicht damit verbracht werden, möglichst viele neue Dienste zu lernen. Wichtiger ist, Vertrauen aufzubauen und die Entscheidungsqualität zu erhöhen. Ein neuer Azure Solutions Architect sollte zunächst verstehen, welche Workloads geschäftskritisch sind, wo technische Schulden liegen, welche Sicherheitsannahmen ungeprüft sind und welche Kostenstellen bereits unter Druck stehen.

Ein sinnvoller Startpunkt ist eine Stakeholder-Landkarte. Dazu gehören Applikationsteams, Plattformteam, Security, Datenschutz, Netzwerkbetrieb, Finanzen, Einkauf, Compliance und die Fachbereiche, die Verfügbarkeit oder Datenzugriff tatsächlich bewerten. Aus dieser Perspektive entstehen schnelle Beiträge: ein Architekturentscheidungsprotokoll für ein laufendes Projekt, ein Review der Landing-Zone-Abweichungen, ein Kosten- und Tagging-Check, eine RBAC-Bereinigung oder ein BCDR-Workshop für einen kritischen Workload.

Nach 30 bis 60 Tagen sollte erkennbar sein, welche Architekturstandards fehlen oder uneinheitlich angewendet werden. Nach 90 Tagen sollte mindestens ein wiederverwendbares Artefakt entstanden sein: ein Referenzdesign, ein Governance-Pattern, ein Kostenmodell, ein Runbook oder ein IaC-Modul. Diese Artefakte sind intern nützlich und später auch für das eigene Portfolio wertvoll, sofern sie anonymisiert und ohne vertrauliche Informationen dargestellt werden.

Den nächsten Zertifizierungs- und Lernschritt wählen

Der nächste Schritt nach AZ-305 sollte von der Zielrolle ausgehen. Wer stärker in Richtung Enterprise- oder Solutions Architecture gehen möchte, sollte Governance, Sicherheit, BCDR, Netzwerkdesign und Entscheidungsdokumentation vertiefen. Wer Plattformverantwortung sucht, braucht mehr Routine mit Terraform oder Bicep, Pipelines, Testbarkeit, Observability und Policy-as-Code. Wer Datenarchitekturen verantworten will, sollte Datenmodellierung, Speicheroptionen, Integrationsmuster und Data Governance ausbauen.

Ein pragmatischer 12-Wochen-Plan beginnt mit einer Lückenanalyse statt mit einer weiteren Prüfungsbuchung. In den ersten Wochen sollte eine Person zwei bis drei vorhandene Architekturen gegen Anforderungen wie Verfügbarkeit, Identität, Netzwerksegmentierung, Kosten und Betrieb prüfen. Danach folgt ein kleines Portfolio-Projekt: Landing Zone, BCDR-Runbook, FinOps-Modell oder IaC-Modul. Erst wenn klar ist, ob die eigene Lücke eher in Build-Automatisierung, Security, Daten oder Governance liegt, lohnt sich die Auswahl des nächsten Examens, etwa AZ-400, AZ-204, DP-203 oder SC-100.

Die jährliche Erneuerung von Microsoft-Zertifizierungen sollte ebenfalls eingeplant werden. Microsoft beschreibt die Rezertifizierung über Microsoft Learn; Kandidaten sollten diese Seite regelmäßig prüfen, weil sich Anforderungen und Inhalte ändern können. Für fachliche Aktualität sind außerdem die Microsoft Tech Community und die Azure Community hilfreich, sofern Beiträge kritisch gegen offizielle Dokumentation und eigene Projektanforderungen geprüft werden.

Wie AZ-305 in die Karriereplanung passt

AZ-305 ist ein glaubwürdiges Signal für Architekturfähigkeit, ersetzt aber nicht die Arbeit an Kontext, Kommunikation und Artefakten. Wer aus Administration kommt, sollte besonders auf Designbegründungen, Governance und Kostensteuerung achten. Wer aus Entwicklung kommt, sollte Betriebsmodelle, Netzwerke, Identitäten und Resilienz vertiefen. Wer aus DevOps kommt, sollte vermeiden, Architektur ausschließlich als Automatisierungsproblem zu betrachten.

Strukturierte Vorbereitung kann helfen, diese Perspektiven zusammenzuführen. Ein AZ-305-Kurs von Readynez ist vor allem dann sinnvoll, wenn Lernende ihre vorhandene Praxis gegen die Prüfungsziele und typische Architekturentscheidungen abgleichen möchten. Wer allgemeiner nach Azure- und Cloud-Training sucht, findet über Readynez einen Einstieg in die verfügbaren Lernformate.

Der wichtigste Karriereschritt nach AZ-305 ist eine klare Positionierung. Eine Person sollte benennen können, ob sie geschäftsnahe Solution Architecture, technische Plattformverantwortung, Datenarchitektur oder Security Architecture anstrebt. Aus dieser Entscheidung ergeben sich die nächsten Projekte, die passenden Artefakte, die relevante Zertifizierung und die Gespräche, die intern oder auf dem Arbeitsmarkt geführt werden sollten.

FAQ

Was ist die AZ-305-Zertifizierung?

AZ-305 ist die Prüfung „Designing Microsoft Azure Infrastructure Solutions“. Zusammen mit der passenden Administrator-Zertifizierung führt sie zum Status Microsoft Certified: Azure Solutions Architect Expert. Inhaltlich geht es um das Design von Azure-Lösungen für Identität, Governance, Daten, Infrastruktur, Netzwerk, Business Continuity und Betrieb.

Welche Voraussetzungen sollte jemand vor AZ-305 mitbringen?

Kandidaten sollten Azure-Administration, Governance, Identitäten, Netzwerke, Speicher, Monitoring und Sicherheitsgrundlagen praktisch kennen. Erfahrung aus Entwicklung oder DevOps ist hilfreich, weil viele Architekturentscheidungen Auswirkungen auf Deployment, Betrieb und Anwendungsdesign haben.

Welche Jobs passen nach AZ-305?

Naheliegende Rollen sind Azure Solutions Architect, Cloud Architect, Cloud Consultant, Platform Engineer mit Architekturverantwortung, DevOps Engineer mit Azure-Fokus, Data Architect oder Security Architect. Die passende Richtung hängt davon ab, ob die Person lieber Anforderungen und Entscheidungen moderiert, Plattformen automatisiert, Datenarchitekturen entwirft oder Sicherheits- und Compliance-Fragen verantwortet.

Welche Zertifizierung ist nach AZ-305 sinnvoll?

Für Platform- und DevOps-Schwerpunkte ist AZ-400 naheliegend. Für Entwicklerprofile kann AZ-204 passen, für Datenrollen DP-203 und für Sicherheitsarchitektur SC-100. Die Auswahl sollte aus der Zielrolle und den aktuellen Kompetenzlücken entstehen, nicht aus einer möglichst langen Zertifikatsliste.

Wie oft muss die Microsoft-Zertifizierung erneuert werden?

Microsoft rollenbasierte und Spezialzertifizierungen müssen regelmäßig erneuert werden. Die aktuellen Regeln, Fristen und Abläufe beschreibt Microsoft auf der offiziellen Seite zur Zertifizierungserneuerung auf Microsoft Learn.