Azure AZ-305: der Schritt zum Solutions Architect

Du verwaltest bereits Azure-Ressourcen, fühlst dich in Portalen, Subscriptions und Resource Groups wohl, aber dir fehlt manchmal der rote Faden: Wie fügt sich das alles zu einer durchdachten Lösung für ein Unternehmen zusammen? Genau hier setzt die Azure-Zertifizierung AZ-305 an und führt dich vom Operator zum Architekten.

AZ-104 vs. AZ-305: vom Schraubenschlüssel zum Bauplan

Bevor wir in Identität, Daten und Business Continuity einsteigen, lohnt sich die saubere Abgrenzung zur AZ-104.

AZ-104 (Azure Administrator):

• Fokus auf Umsetzung und Betrieb
• Du kennst die Azure-Dienste, kannst sie deployen und konfigurieren
• Typische Aufgaben:
• VMs und Storage anlegen und verwalten
• Netzwerke, VPNs und Firewalls konfigurieren
• Monitoring und Alerts einrichten
• Probleme im laufenden Betrieb analysieren

AZ-305 (Azure Solutions Architect Expert, Design-Prüfung):

• Fokus auf Architektur und Designentscheidungen
• Du triffst Entscheidungen, welche Dienste warum eingesetzt werden
• Typische Aufgaben:
• Anforderungen von Fachbereichen aufnehmen und in eine Azure-Architektur übersetzen
• Sicherheits- und Identitätskonzepte entwerfen
• Datenarchitekturen und Integrationskonzepte planen
• Kosten, Skalierung und Resilienz in Einklang bringen

Ein einfaches Bild: AZ-104 ist die Person, die das Haus nach Plan baut und instand hält. AZ-305 ist die Person, die den Bauplan entwirft, Statik, Materialien und Haustechnik auswählt und verschiedene Gewerke koordiniert.

Wichtig: Ohne solide Grundlagen aus dem AZ-104-Umfeld wird dir die AZ-305 schwerfallen. Du musst nicht zwingend die AZ-104-Prüfung abgelegt haben, aber du solltest dich in der Praxis sicher bewegen. Gerade in größeren Münchner Unternehmen zeigt sich schnell, ob ein Architekt wirklich verstanden hat, wie sich seine Konzepte im Alltag anfühlen.

Wer sollte Solutions Architect werden?

Die Architektenrolle passt nicht für jede Persönlichkeit gleich gut. Ein paar typische Profile, die von der AZ-305 stark profitieren:

• Erfahrene Azure-Administratoren, die:

• immer öfter in Projekten mitreden sollen

• Lösungen nicht nur umsetzen, sondern mitgestalten wollen

• als technische Ansprechperson für Fachbereiche auftreten

• Entwicklerinnen und Entwickler, die:

• Cloud-native Lösungen in Azure bauen

• verstehen wollen, wie sich ihre Anwendung in das Gesamtbild aus Netzwerk, Identität und Daten einfügt

• zunehmend Verantwortung für nicht-funktionale Anforderungen übernehmen, etwa Sicherheit und Verfügbarkeit

• IT-Consultants und technische Projektleitende, die:

• Architekturentscheidungen begründen und dokumentieren müssen

• mit Kundinnen und Kunden Azure-Szenarien entwerfen

• verschiedene Stakeholder unter einen Hut bringen sollen

Ob die Rolle zu dir passt, erkennst du unter anderem an diesen Punkten:

• Du hast Spaß daran, mit Fachbereichen zu sprechen und Anforderungen zu klären.
• Du kannst technische Komplexität reduzieren und verständlich erklären.
• Du denkst automatisch in Szenarien, Abhängigkeiten und Risiken.
• Du akzeptierst, dass es selten die eine perfekte Lösung gibt, sondern Kompromisse.

Wenn du dich eher als Spezialist für ein Thema verstehst, kann die Architektenrolle trotzdem spannend sein. Aber du musst bereit sein, über deinen Schwerpunkt hinauszublicken, etwa von Netzwerk auf Identität, Daten und Governance.

Identitätsdesign: Azure AD, Hybrid und Zero Trust

Identität ist in Azure der Dreh- und Angelpunkt. In der AZ-305 geht es weniger darum, einzelne Benutzer anzulegen, sondern darum, Identitätsstrategien zu entwerfen.

Typische Designfragen:

• Nutzt das Unternehmen nur Azure AD oder ein hybrides Setup mit lokalem Active Directory?
• Wie werden Benutzer und Gruppen synchronisiert, etwa mit Azure AD Connect oder Cloud Sync?
• Wie sieht ein sinnvolles Modell für Rollen und Berechtigungen aus, bezogen auf:
• Azure-RBAC (Rollen auf Subscription-, Resource-Group- und Ressourcenebene)
• Azure AD-Rollen für Tenant-Verwaltung
• Custom Roles für spezielle Anforderungen

Wichtige Themen im Identitätsdesign:

• Zero-Trust-Ansatz Nicht das Netzwerk wird vertraut, sondern jede einzelne Identität und jede einzelne Anfrage. Praktisch bedeutet das:

• Bedingter Zugriff mit Azure AD Conditional Access

• Starke Authentifizierung, etwa per MFA

• Least-Privilege-Prinzip für Rollen und Service Principals

• Serviceidentitäten und Workload-Identitäten Anwendungen und Automatisierungsskripte brauchen Zugriffsrechte. Architekturentscheidungen betreffen hier:

• Managed Identities statt klassischer Service Accounts

• Geheimnisverwaltung über Azure Key Vault

• Trennung von Rechten für Build-, Deploy- und Runtime-Prozesse

• Mandanten- und Mandantenübergreifende Szenarien In Konzernen oder bei Kooperationen mit Partnern musst du entscheiden:

• Single Tenant oder Multi Tenant für Anwendungen

• B2B-Gastzugriffe und deren Governance

• Organisationsweite Richtlinien für Zugriffssteuerung

In der Praxis in München erlebst du oft historisch gewachsene Identitätslandschaften. Der Mehrwert eines guten Azure-Architekten liegt dann darin, schrittweise eine saubere Zielarchitektur zu definieren und Migrationspfade zu planen.

Datenarchitektur: das richtige Speichermodell wählen

Daten sind in Azure mehr als nur „irgendwo Storage anlegen“. Die AZ-305 verlangt von dir, dass du für konkrete Szenarien die passenden Dienste auswählst und begründest.

Typische Entscheidungskategorien:

• Transaktionale Workloads

• Azure SQL Database oder SQL Managed Instance?

• Wann ist eine klassische VM mit SQL Server sinnvoll?

• Wann passt Cosmos DB als global verteilte NoSQL-Datenbank?

• Analytische Workloads

• Data Lake mit Azure Data Lake Storage

• Azure Synapse Analytics für Data Warehousing

• Azure Data Factory oder Synapse Pipelines für ETL/ELT

• Unstrukturierte Daten

• Blob Storage für große Dateien, Backups und Archive

• Fileshares mit Azure Files als Ersatz oder Ergänzung zu klassischen Fileservern

Beim Design geht es um Fragen wie:

• Welche Performance- und Latenzanforderungen gibt es?
• Welche Compliance-Vorgaben gelten, etwa DSGVO und Branchenregularien?
• Wie sieht das Backup- und Restore-Konzept aus?
• Wie werden Daten verschlüsselt, im Ruhezustand und während der Übertragung?

Ein einfaches Beispiel: Ein Münchner E-Commerce-Unternehmen braucht eine globale, hochverfügbare Produktkatalog-Datenbank mit geringer Latenz. Cosmos DB mit mehreren Regionen, automatischer Replikation und klarer Partitionierungsstrategie könnte hier sinnvoll sein. Gleichzeitig müssen Zahlungsdaten strikt reguliert und lokal gespeichert werden. Dafür wäre eine Azure SQL Database in einer bestimmten Region mit Always Encrypted eine bessere Wahl.

Infrastrukturdesign: Netzwerk, Compute und Governance

Im Bereich Infrastruktur geht die AZ-305 weit über das Anlegen einzelner VMs hinaus. Du sollst komplette Landschaften entwerfen.

Netzwerk- und Zugriffsarchitektur

Wichtige Designfragen:

• Wie werden VNETs segmentiert? Nach Umgebung (Dev, Test, Prod), nach Fachbereich oder nach Anwendung?
• Welche Konnektivität wird genutzt?
• Site-to-Site-VPN
• ExpressRoute
• Kombinationen mit Hub-and-Spoke-Topologie
• Wie werden Zugriffe geschützt?
• Network Security Groups
• Azure Firewall oder NVA
• Private Endpoints für PaaS-Dienste

Du musst entscheiden, welche Komplexität für die Anforderungen angemessen ist. Ein kleiner Münchner Mittelständler mit einigen wenigen Azure-Ressourcen braucht selten ein extrem ausgefeiltes Hub-and-Spoke-Konstrukt. Ein Unternehmen mit mehreren Standorten, Entwicklungs- und Produktionsumgebungen dagegen schon.

Compute und Plattformdienste

Auch bei Rechenressourcen geht es in der AZ-305 um Abwägungen:

• Wann eignen sich IaaS-VMs, wann App Services, Functions oder Container?
• Wie wird Skalierung umgesetzt, manuell, automatisch oder ereignisgetrieben?
• Welche SLAs brauchst du, und wie erreichst du sie?

Typische Entscheidungen:

• Legacy-Anwendung, die nur auf Windows Server läuft Rehosting auf VMs, eventuell mit Azure Virtual Machine Scale Sets.
• Neue Webanwendung Azure App Service mit integrierter CI/CD-Pipeline und Application Gateway.
• Ereignisgetriebene Verarbeitung Azure Functions mit Event Grid oder Service Bus.

Governance und Struktur

Architektur hört nicht beim Rechenzentrum auf. Du planst auch:

• Subscription-Strategien, etwa:
• Trennung nach Umgebungen
• Trennung nach Mandanten oder Kostenstellen
• Management Groups als logische Klammer
• Azure Policy, um Standards technisch durchzusetzen
• Tagging-Konzepte für Kosten und Transparenz

Ein gutes Governance-Design sorgt dafür, dass die Landschaft auch in zwei Jahren noch beherrschbar ist, obwohl mehrere Teams parallel daran arbeiten.

Business Continuity: Resilienz, Backup und Notfallplanung

Business Continuity ist in der AZ-305 ein zentrales Thema. Es geht darum, wie du sicherstellst, dass kritische Workloads auch bei Ausfällen weiterlaufen oder schnell wiederhergestellt werden.

Wichtige Begriffe:

• RPO (Recovery Point Objective) Wie viel Datenverlust ist maximal akzeptabel?
• RTO (Recovery Time Objective) Wie lange darf die Wiederherstellung dauern?

Auf Basis dieser Vorgaben entwirfst du Strategien, etwa:

• Hochverfügbarkeit innerhalb einer Region:
• Availability Sets und Availability Zones für VMs
• Zonenredundante Dienste, etwa für Load Balancer oder Storage
• Georedundanz:
• Replikation in zweite Region
• Aktive/aktive oder aktive/passive Szenarien
• Backup-Strategien:
• Azure Backup für VMs, Datenbanken und Fileshares
• Kombination mit On-Premises-Backups
• Aufbewahrungsrichtlinien und Test-Restores

Ein konkretes Beispiel: Eine Fachanwendung im Gesundheitsbereich darf höchstens 15 Minuten Daten verlieren und 2 Stunden ausfallen. Daraus ergeben sich klare Anforderungen an Replikation, Backup-Frequenzen und Automatisierung von Failover-Prozessen. Als Architekt entwirfst du dafür die passende Kombination aus Azure Site Recovery, Storage-Replikation und Notfallhandbuch.

Wichtig ist auch, dass du Business Continuity nicht nur technisch denkst. Es geht auch um:

• Rollen und Verantwortlichkeiten im Notfall
• Dokumentierte Runbooks
• Regelmäßige Tests von Failover-Szenarien

Wie bereitest du dich sinnvoll auf die AZ-305 vor?

Die AZ-305 ist stark szenariobasiert. Reines Auswendiglernen von Diensten reicht nicht. Ein sinnvoller Fahrplan:

1. Praxis konsolidieren Arbeite bewusst einige Monate mit Azure, idealerweise in Projekten, in denen du schon Designentscheidungen mitbekommst.

2. Offizielle Lernpfade nutzen Microsoft Learn bietet kostenfreie, gut strukturierte Module zur AZ-305. Achte auf die Szenarien und Entscheidungsbegründungen, nicht nur auf die Klickpfade.

3. Architektur-Entscheidungen dokumentieren Übe, deine Überlegungen aufzuschreiben:

• Welche Anforderungen gibt es?
• Welche Optionen stehen zur Auswahl?
• Warum triffst du welche Entscheidung? Das hilft enorm für die Prüfung und für die Praxis.

4. Whiteboard-Übungen Nimm typische Szenarien, etwa:

• mehrschichtige Webanwendung mit Datenbank
• hybride Umgebung mit Standortvernetzung
• global verteilte Anwendung mit lokalen Compliance-Vorgaben und entwirf dazu eine Azure-Architektur auf dem Whiteboard oder digital.

Wenn du das nicht alleine machen möchtest, sind strukturierte Schulungen mit Trainererfahrung hilfreich, besonders wenn du Fragen aus deinem Alltag einbringen willst. Aktuelle Termine und passende Kurse findest du bei cmt.de.

Fazit: AZ-305 als Türöffner zur Architektenrolle

Die AZ-305 ist mehr als eine weitere Azure-Prüfung. Sie zwingt dich, in End-to-End-Szenarien zu denken: von Identität über Daten, Netzwerk und Governance bis zu Business Continuity.

Wenn du:

• bereits solide Azure-Erfahrung hast,
• mehr Verantwortung für technische Entscheidungen übernehmen willst,
• gerne mit Menschen aus Fachbereichen und Management sprichst,

dann passt die Solutions-Architect-Rolle sehr wahrscheinlich gut zu dir. Die AZ-305 gibt dir dafür einen klaren Rahmen und einen strukturierten Blick auf die vielen Bausteine, aus denen du tragfähige Azure-Lösungen entwirfst.