AZ-900 — Azure Core Services: 170 Übungsfragen

Step 1: Anforderungen analysieren – Die Anwendung verlangt schnellen Zugriff auf benutzerbezogene Profilinformationen im schemalosen Format mit Key-Value-Zugriffen und geringer Latenz. Das ist ein typisches Einsatzszenario für einen NoSQL-Tabellenstore.

Step 2: Dienstmatching – Azure Table Storage bietet genau diese Eigenschaften: Es ist ein schemaloser, hochskalierbarer NoSQL-Dienst, in dem Entitäten über PartitionKey und RowKey adressiert werden können, was schnelle Lookups und kosteneffiziente Speicherung ermöglicht. Außerdem ist Table Storage einfach zu verwenden, wenn keine komplexen relationalen Abfragen erforderlich sind.

Step 3: Entscheidung – Aufgrund der Anforderungen ist Azure Table Storage die richtige Wahl. Für komplexere Abfragen, stärkere Indizierung oder relationale Anforderungen wäre eine Datenbank wie Azure Cosmos DB oder Azure SQL passender, doch für einfache, schemalose Profilobjekte ist Table Storage effizient. Trap: Manche verwechseln Blob Storage mit einer Datenbank; Blobs speichern nur große Objekte/Binärdaten, nicht strukturierte Key-Value-Einträge. Ebenso ist Queue Storage kein Datenspeicher für Profile. Warum jede falsche Antwort scheitert: - Azure Blob Storage: Speichert unstrukturierte Objekte (Dateien, Bilder), nicht strukturierte/tabellarische Einträge mit schnellen Key-Value-Lookups; daher ungeeignet für häufige, feingranulare Profilabfragen. - Azure Queue Storage: Dient als Messaging-Warteschlange, nicht als persistenten Key-Value-Datenspeicher für Benutzerprofile. - Azure Files: Bietet SMB/NFS-Dateifreigaben und verhält sich wie ein Dateisystem; nicht optimiert für schnelle Key-Value-Lookups auf schemalosen Entitäten. Zusammenfassung: Für schemalose, schnell zugängliche Profilinformationen ist Azure Table Storage kosteneffizient und performant; andere Storage-Typen erfüllen die Access-Pattern nicht oder sind für andere Anforderungen optimiert.

Step 1: Anforderungen spezifizieren Langfristige Archivierung mit sehr seltenen Zugriffen erfordert einen Speicher mit sehr niedrigen Kosten pro GB, aber höheren Wiederherstellungskosten und Latenzen sind akzeptabel. Das Teilen von Dateien zwischen VMs per SMB verlangt hingegen einen Dateiservice mit Protokollunterstützung für SMB oder NFS.

Step 2: Matching mit Azure-Diensten Azure Blob Storage unterstützt Access Tiers (Hot, Cool, Archive). Archive ist speziell für langfristige, seltene Zugriffe optimiert, bietet sehr niedrige Speicherkosten und höhere Latenz/Kosten beim Wiederherstellen. Azure Files ist ein vollständig verwalteter Dateiservice, der SMB (und je nach SKU auch NFS) unterstützt, wodurch mehrere VMs dieselben Dateien wie in einem traditionellen Dateisystem teilen können. Queue Storage und Table Storage adressieren andere Use Cases: Messaging beziehungsweise NoSQL-Key-Value-Daten.

Step 3: Nutzungsempfehlungen Für Archivdaten wählen Sie Blob Storage im Archive-Tier und konfigurieren Lifecycle Policies, um Objekte automatisch in das passende Tier zu verschieben. Für gemeinsame Dateizugriffe verwenden Sie Azure Files mit SMB oder NFS, je nach Bedarf. Beachten Sie, dass Azure Files auch Performance- und Zugriffsoptionen (z. B. Premium-Volume) anbietet, wenn VMs hohen Durchsatz benötigen. Trap: Manche Nutzer denken, Archive-Tier sei geeignet für zufällige Zugriffsmuster. Archive ist jedoch für sehr seltene Zugriffe konzipiert und nicht für häufige oder latenzsensible Zugriffe geeignet. Auch sollte man Azure Files nicht mit Blob Storage verwechseln, da Blob kein nativen SMB-Zugriff bietet. Why each wrong answer fails: - Azure Blob Storage (mit Hot/Cool/Archive Access Tiers) (richtig): Bietet dedizierte Archiv-Tiers und Lifecycle-Management für langfristige, seltene Zugriffe. - Azure Files (SMB/NFS-Dateifreigaben) (richtig): Ermöglicht native SMB/NFS-Freigaben und ist die korrekte Wahl, um Dateien zwischen VMs zu teilen. - Azure Queue Storage (falsch): Dient als Messaging-Warteschlange, nicht als Archivspeicher oder Dateifreigabe. - Azure Table Storage (falsch): Ein schemaloser NoSQL-Key-Value-Store, gut für massive Mengen strukturierter Telemetrie, aber nicht für Archivierung per Tier oder SMB-Dateifreigaben. Fazit: Verwenden Sie Blob Storage Archive-Tier für kosteneffiziente Langzeitarchivierung und Azure Files für SMB/NFS-gestützte gemeinsame Dateifreigaben zwischen VMs.

Step 1: Ziel definieren — Sie möchten Pods direkte private IPs aus dem bestehenden VNet zuweisen, damit normale VNet-Mechanismen (NSGs, User-Defined Routes) auf Pod‑Level greifen. Das heißt: Pods müssen IP-Adressen aus dem VNet-Adressraum erhalten, nicht nur die Node-IP mit Portweiterleitung.

Step 2: Netzwerkmodelle vergleichen — AKS bietet zwei typische CNI-Modelle: kubenet (ein einfaches Overlay, bei dem Pods private IPs innerhalb eines Overlay-Raums nutzen und Node‑IP/Port‑NAT verwendet wird) und Azure CNI (bei dem jedem Pod eine IP aus dem VNet zugewiesen wird). kubenet erfordert häufig zusätzliche NAT/Forwarding und bietet nicht dieselbe direkte Integration mit NSGs. Azure CNI integriert Pods direkt ins VNet.

Step 3: Entscheidung — Um Pods direkt als VNet-Ressourcen zu behandeln, ist Azure CNI die richtige Wahl. Das erlaubt, dass NSGs, Routen und Peering wie bei anderen VNet-Subnets angewandt werden. kubenet würde nicht die geforderte direkte IP‑Zuweisung liefern. Host‑Network-Modus ist speziell und würde Pods Host‑Netzwerk verwenden, bietet aber nicht die gewünschte VNet-IP-Zuweisung in der üblichen Form. AGIC ist ein Ingress-Controller und beeinflusst nicht die Pod‑IP‑Zuweisung. Trap: Manche denken, kubenet plus zusätzliche NAT/LoadBalancer-Mechanismen reiche aus; das ist zwar möglich für viele Szenarien, erfüllt aber nicht die Anforderung, dass Pods native VNet-IP-Adressen erhalten und direkt NSGs/UDRs unterliegen. Why each wrong answer fails: kubenet mit Azure NAT-Gateway — falsch, kubenet verwendet ein Overlay und die Pods erhalten nicht automatisch IPs aus dem VNet‑Subnet; Traffic wird oft über Node-NAT geleitet, sodass Pod-Level-NSG-Regelung eingeschränkt ist. Host‑Network-Modus ohne Overlay — falsch, Host‑Network bindet den Pod an die Node‑Netzwerkschnittstelle, ist nicht die Standardlösung für direkte VNet-IP-Adressen pro Pod und hat Sicherheits-/Isolationseinbußen. Application Gateway Ingress Controller (AGIC) — falsch, AGIC ist ein Layer-7-Ingress-Lösungsplugin für HTTP/HTTPS und steuert keinen IP‑Adresszuteilungsmechanismus für Pods; es beeinflusst Routing auf Anwendungsebene, nicht die Zuweisung privater VNet-IPs an Pods.

Step 1: Erkennen des Service-Typs — Azure App Service ist ein Platform-as-a-Service (PaaS) speziell für das Hosten von Webanwendungen und APIs. Es bietet native Funktionen wie Deployment-Slots, automatisches Skalieren, TLS-Zertifikatsverwaltung und einfache CI/CD-Integration, während Microsoft die zugrundeliegende Infrastruktur und das OS verwaltet.

Step 2: Abwägen der Alternativen — Azure Functions ist zwar ebenfalls PaaS und für serverlose Workloads geeignet, richtet sich aber primär an ereignisgetriebene, kurzlebige Funktionen, nicht an traditionelle App-Stacks mit Staging/Slots. Azure Virtual Machines sind Infrastructure-as-a-Service (IaaS) und setzen voraus, dass Sie VM-Images, OS-Patches und Software selbst verwalten. Azure Kubernetes Service (AKS) ist Container-basiert und eignet sich für containerisierte Anwendungen mit Orchestrierung, bringt aber zusätzlichen Verwaltungsaufwand und Komplexität.

Step 3: Anwendung auf reale Szenarien — Wenn Sie eine mehrschichtige Webanwendung betreiben und ein SLA sowie einfache Deployments und Zertifikatsverwaltung möchten, reduziert App Service den Betriebsaufwand und oft die Kosten gegenüber VM-basierten Deployments, besonders bei regional verteilter Skalierung. Bei strengem Compliancebedarf oder speziellen Kernel-Anforderungen wären VMs oder AKS geeigneter. Trap: Die häufige Fehlannahme ist, dass alle PaaS-Angebote gleich sind; Azure Functions ist ebenfalls PaaS, aber nicht primär für klassische Web-Apps mit Staging-Slots gedacht. Why each wrong answer fails: - Azure Virtual Machines: Falsch, weil VMs IaaS sind — Sie müssen das Betriebssystem, Patches, Backups und Skalierung selbst verwalten; keine integrierten Deployment-Slots. - Azure Functions: Falsch, weil Functions serverlos und ereignisgetrieben sind; sie unterstützen nicht denselben Workflow für traditionelle Webanwendungen mit Staging/Deployment-Slots und persistenten App-Settings. - Azure Kubernetes Service: Falsch, weil AKS Container-Orchestrierung ist und mehr Verwaltung (Container-Images, Cluster-Updates, Node-Pools) erfordert; nicht der einfache PaaS-Workflow mit eingebauten Zertifikats- und Slot-Funktionen. Zusätzliche Hinweise: In Multi-Region- oder Hochlast-Szenarien bietet App Service integrierte Autoscale-Optionen und kann kosteneffizienter sein, da Microsoft Teile des Betriebs (OS-Patching, Plattform-Updates) übernimmt, was Ihre betrieblichen Kosten und Komplexität reduziert.

Step 1: SLA-Grundlagen prüfen Azure definiert SLAs basierend auf der Architektur Ihrer Bereitstellung. Eine einzelne VM hat eine andere SLA als redundante Architekturen. Außerdem unterscheidet Azure zwischen Availability Sets (schützt gegen Hardware-/Update-Ausfälle innerhalb eines Rechenzentrumsrings) und Availability Zones (physische Trennung über Rechenzentren hinweg).

Step 2: Relevante SLA-Informationen anwenden Für zwei oder mehr Instanzen, die über Availability Zones verteilt sind und hinter einem Standard Load Balancer betrieben werden, bietet Azure in vielen Fällen eine höhere SLA-Garantie — typischerweise 99,99% für die zonenredundante Bereitstellung. Dies ist höher als die SLA für ein Availability Set (z. B. 99,95% bei zwei oder mehr Instanzen) und deutlich höher als für eine einzelne VM.

Step 3: Konkreter Fall und Entscheidung Da im Szenario explizit zwei VMs in verschiedenen Availability Zones UND ein Standard Load Balancer genannt werden, entspricht das dem Muster für höheres Zonenschutz-Level, daher ist 99,99% die passende Antwort. Trap: Häufiger Denkfehler Viele Kandidaten denken, dass zwei VMs generell die gleiche SLA bieten wie ein Availability Set oder dass eine einzelne VM-SLA gilt. Wichtig ist, wo und wie die Redundanz aufgebaut ist: zonenübergreifende Redundanz mit Load Balancer bringt die höchsten SLA-Garantien. Warum die falschen Antworten fehlschlagen: - Antwort 1 (99,9% für jede einzelne VM): Das ist die SLA-Klasse einer einzelnen VM (unter gewissen Bedingungen), jedoch trifft sie nicht auf die Gesamt-Architektur mit zwei zonenverteilten VMs hinter einem Load Balancer zu. Die Lösung-SLA bezieht sich auf die Anwendung/Service-Architektur, nicht auf eine einzelne Instanz. - Antwort 2 (99,95% für zwei VMs in einem Availability Set): Diese Zahl ist korrekt für bestimmte Konfigurationen in einem Availability Set, nicht jedoch für zonenredundante Deployments. Availability Sets und Availability Zones sind unterschiedliche Schutzmechanismen; die zonenredundante Variante bietet in der Regel 99,99%. - Antwort 4 (Es gibt keine SLA für Mehrfachbereitstellungen): Das ist falsch — Azure dokumentiert klar SLAs für unterschiedliche Architekturen, inklusive Multi-VM-/zonen-redundanter Architekturen. Mehrfachbereitstellungen haben oft höhere, dokumentierte SLAs. Zusammenfassung: Zwei VMs in unterschiedlichen Availability Zones plus Standard Load Balancer entsprechen einem zonenredundanten Szenario, wofür Azure typischerweise eine SLA von 99,99% angibt.

Step 1: Zieldefinition — Für ein Produktions-AKS-Cluster mit hoher Verfügbarkeit gilt es, Single Points of Failure (Hosts, Racks, ganze Rechenzentren) zu vermeiden und sicherzustellen, dass sowohl Steuerungskomponenten als auch Workloads bei einem Teil-Ausfall weiterlaufen.

Step 2: Technische Maßnahmen evaluieren — Availability Zones verteilen Ressourcen über mehrere physisch getrennte Rechenzentren in derselben Region; dadurch wird Schutz gegen Ausfälle eines ganzen Rechenzentrums erreicht. Innerhalb Kubernetes helfen Affinity/Anti-Affinity- und Pod-Disruption-Budgets dabei, Pods über Nodes und Zonen zu verteilen, damit nicht alle Instanzen einer Anwendung gleichzeitig ausfallen.

Step 3: Umsetzungsempfehlung — Verlegen Sie Node-Pools in mehrere Availability Zones (Option 1) und nutzen Sie Kubernetes-Affinity/Anti-Affinity-Policies und PodDisruptionBudgets (Option 3), damit kritische Pods über Zones/Nodes verteilt und kontrollierte Updates möglich sind. Testen Sie Node-Ausfälle und Upgrade-Prozesse, um die Effektivität zu bestätigen. Trap: Ein häufiger Fehler ist, Availability Sets als „günstige“ Alternative zu sehen. Sie bieten Schutz vor bestimmten Host- und Wartungsproblemen, aber nicht die Isolation von komplett getrennten Rechenzentren wie Availability Zones — deshalb sind sie für zonenübergreifende Resilienz nicht ausreichend. Warum jede falsche Antwort fehlschlägt: - Verwenden von Availability Sets anstelle von Availability Zones (Option 2): Availability Sets schützen innerhalb eines Rechenzentrums gegen einzelne Hardwarefehler und Wartungsfenster, bieten jedoch keine Isolation auf Ebene mehrerer Rechenzentren (Zonen). Für regionale Resilienz und Schutz gegen Zonenausfälle sind Availability Zones überlegen. - Nur eine sehr große VM in einer Zone betreiben (Option 4): Das schafft einen Single Point of Failure; bei Ausfall dieser VM oder der Zone wäre die Anwendung komplett nicht verfügbar. Außerdem reduzieren große Monolith-VMs die Flexibilität bei Updates, Skalierung und Failover. Praktische Hinweise: Ergänzend zu Zonen und Pod-Strategien sollten Sie regelmäßige Backups, Monitoring (z. B. mit Azure Monitor), granulare Health-Probes und automatisierte Rollbacks einrichten. Beachten Sie auch die SLA-Details von AKS: Microsoft verwaltet die Steuerungsebene, aber für Worker-Nodes und Workloads sind Sie verantwortlich; daher ist Konfiguration der Zonen wichtig für Ihre Verfügbarkeit.

Step 1: Anforderungen und Kosten abwägen — Für regelmäßige, kurzzeitige Lastspitzen ist automatisches Skalieren ideal, weil Sie nur für die tatsächlich benötigte Kapazität zahlen und keine dauerhaften Ressourcen vorhalten müssen. Die Betriebskosten bleiben somit niedriger als bei permanent gehosteten großen VMs.

Step 2: Auswahl der passenden Plattform — Azure App Service bietet integriertes Autoscale (horizontal) basierend auf Metriken wie CPU, HTTP-Queue-Länge oder benutzerdefinierten Regeln. Als PaaS reduziert es Verwaltungsaufwand (kein OS-Management) und lässt sich leicht in CI/CD-Pipelines integrieren, was schnelle Reaktionszeiten bei Lastspitzen ermöglicht.

Step 3: Praktische Betriebsüberlegungen — Bei stark variierenden Lasten sparen Sie Geld, weil die Anzahl der Instanzen automatisch reduziert wird, wenn die Last sinkt. Stellen Sie sicher, dass Sie geeignete Skalierungsregeln, Mindest-/Maximal-Instanzzahlen und Health-Probes konfigurieren, und denken Sie an Caching, CDNs oder Connection-Pooling, um Kosten weiter zu optimieren. Trap: Ein verbreiteter Irrtum ist zu glauben, dass größere einzelne VMs automatisch kosteneffizienter sind; in der Praxis verursachen sie fixe Kosten, auch wenn die Last niedrig ist. Why each wrong answer fails: - Manuelles Erstellen großer virtueller Maschinen bei Bedarf: Falsch, weil manuelles Provisioning langsam ist, zu menschlichen Fehlern führt und ineffizient in den Kosten ist — Sie zahlen für die VM solange sie läuft, selbst bei abnehmender Last; außerdem müssen Sie OS- und Sicherheits-Updates selbst managen. - Bereitstellung zusätzlicher On-Premise-Server: Falsch, da On-Premise-Provisioning langfristige Investitionen und Fixkosten erfordert; es bietet wenig Flexibilität für kurzfristige Lastspitzen und erhöht Betriebskosten für Platz, Strom und Personal. - Speichern der Anwendung in einem Azure Blob Storage: Falsch und konzeptionell unpassend — Blob Storage ist ein Objekt-Speicher für Dateien, nicht ein Hosting-Service für Webanwendungen; er bietet keine Laufzeitumgebung oder automatische Skalierung für Web-Workloads. Zusätzliche Hinweise: Für sehr kurzzeitige, spiky Lasten kann Kombination aus App Service Autoscale, CDN (für statische Inhalte) und serverlosen Komponenten (z. B. Azure Functions) zusätzliche Kosteneinsparungen bringen. Achten Sie außerdem auf Skalierungslimits je Plan und die globale Verteilung (Regionsauswahl) um Latenz und Ausfallrisiken zu optimieren.

Step 1: Problemidentifikation — Zero-Downtime-Deployments erfordern eine Möglichkeit, eine neue Version zu hosten und zu testen, bevor der Verkehr nahtlos auf die neue Version umgeleitet wird.

Step 2: Feature-Auswertung — Azure App Service bietet Deployment-Slots (z. B. staging, staging-1), die eine laufende Instanz der App mit separater Konfiguration betreiben. Nach dem Testen kann ein Swap durchgeführt werden, der Konfigurationseinstellungen beibehält oder austauscht und den eingehenden Traffic ohne Downtime auf die neue Instanz leitet.

Step 3: Empfehlung — Deployment-Slots sind speziell für diesen Szenario entwickelt worden; sie ermöglichen warmes Swap-Verhalten, verringern Downtime-Risiken und unterstützen Rollbacks durch Swap zurück. Trap: Ein häufiger Fehler ist zu glauben, dass allgemeine Storage- oder VM-Funktionen (Snapshots, Versioning) für Web-App-Deployments äquivalent sind; sie adressieren nicht das Problem des nahtlosen Swap und des integrierten App-Service-Netzwerks. Warum jede falsche Antwort fehlschlägt: - Azure VM Snapshots: Snapshots sind nützlich zum Sichern des VM-Zustands, aber sie bieten keinen Mechanismus zum Hosting einer Nebeninstanz für Tests und können kein nahtloses Traffic-Swapping für Webanwendungen durchführen. - Azure Blob Versioning: Blob-Versioning schützen gespeicherte Objekte vor unbeabsichtigten Änderungen; sie sind nicht für die Ausführung oder das Deployment von Webanwendungen gedacht. - Resource Locks: Resource Locks verhindern versehentliche Löschen/Änderungen von Ressourcen, sind aber kein Mechanismus für Deployment, Testen oder Traffic-Switching. Daher sind Deployment-Slots die passende Lösung für Zero-Downtime-Bereitstellungen von Web-Apps.

Step 1: Anforderungen der Architektur analysieren — Produktionsreife Microservices benötigen in der Regel orchestrierte Bereitstellung, automatisches Skalieren (Horizontales Pod-Autoscaling, Cluster-Autoscaler), Service Discovery, Load-Balancing, Canary-Rollouts und oft detaillierte Netzwerk-Policies (z. B. Network Policies in Kubernetes). Diese Funktionen sind Kernbestandteil einer Kubernetes-basierten Plattform.

Step 2: AKS-Fähigkeiten betrachten — Azure Kubernetes Service (AKS) ist Microsofts verwalteter Kubernetes-Dienst. Er verwaltet die Control-Plane, bietet Integration mit Azure Load Balancer, Ingress-Controllern, Azure Monitor, Managed Identities und unterstützt die Einrichtung von Netzwerk-Policies, Service Meshes (z. B. Istio, Linkerd) und automatisierten Skalierungen. Dadurch erfüllt AKS die genannten Anforderungen out-of-the-box oder mit bewährten Erweiterungen.

Step 3: Gründe, andere Optionen auszuschließen — ACI eignet sich für einfache, kurzlebige Container-Workloads, bietet jedoch nicht dieselben Orchestrierungsfunktionen. Blob Storage ist für statische Daten und Web-Hosting gedacht und kann keine Microservice-Orchestrierung leisten. Reine VMs sind möglich, aber erfordern erheblichen Aufwand für die Implementierung von Service Discovery, Skalierung und Netzwerk-Policies, die Kubernetes standardmäßig bereitstellt. Trap: Manche denken, "Container auf VMs" reiche aus; zwar kann man alles mit VMs bauen, aber der Betriebsaufwand, die Komplexität und die fehlenden nativen Orchestrierungsfunktionen machen dies ineffizient für moderne Microservices. Why each wrong answer fails: - Option 2 (ACI): Falsch, weil ACI keinen vollwertigen Orchestrator bietet; es fehlt an integriertem Service Discovery, komplexem Netzwerk-Management und robusten Skalierungs-Features für viele miteinander verbundene Microservices. - Option 3 (Blob Storage mit statischem Website-Hosting): Falsch, da Blob Storage nur statische Inhalte hostet; es hat keine Laufzeitumgebung, keine Container-Verwaltung und kann keine Microservices ausführen. - Option 4 (Virtuelle Maschinen ohne Container-Orchestrator): Zwar möglich, aber unpraktisch für moderne Microservices: Sie müssten manuell Skalierung, Service Discovery, Rolling-Updates und Netzwerk-Policies implementieren und verwalten, was deutlich mehr Aufwand und Fehleranfälligkeit bedeutet. Fazit: Für eine produktionsreife Microservices-Architektur mit den genannten Anforderungen ist AKS konzeptionell die beste Wahl, weil es orchestrierte Abläufe, Skalierung, Service Discovery und Netzwerk-Kontrolle als integrierte Funktionen bietet.

Step 1: Anforderungen analysieren — Sie brauchen die höchstmögliche Verfügbarkeit (99,99 %) innerhalb einer Region. Azure bietet unterschiedliche SLA-Stufen, abhängig von der Architektur (Einzelinstanz, Availability Set, Availability Zones).

Step 2: Vergleich der Optionen — Eine einzelne VM hat deutlich niedrigere SLA-Werte; Availability Sets schützen vor Hardware-/Rack-Ausfällen innerhalb eines Rechenzentrums, liefern aber üblicherweise eine SLA von 99,95 % für zwei oder mehr VMs. Availability Zones sind physisch getrennte Rechenzentren innerhalb derselben Region und bieten die höchste regionale Verfügbarkeit (für mehrere VMs in verschiedenen Zonen Azure kündigt 99,99 % SLA an).

Step 3: Entscheidung — Für 99,99 % SLA deployen Sie mindestens zwei VMs über Availability Zones in derselben Region, typischerweise hinter einem Azure Load Balancer, sodass ein Zonenausfall abgefangen werden kann. Trap: Ein häufiger Irrtum ist zu glauben, dass zwei VMs in einem Region-Pair oder in einem Availability Set automatisch die gleiche hohe SLA wie Zonen bieten. Region-Pairs dienen primär der geografischen Trennung und Wiederherstellungsszenarien, nicht der zonenbasierten regionalen Hochverfügbarkeit. Warum jede falsche Antwort fehlschlägt: Antwort 1 (Eine einzelne VM): Einzelne VMs sind anfälliger und erhalten keine 99,99 % SLA; oft liegt die SLA für eine Single-VM deutlich darunter, selbst mit Premium-Datenträgern. Antwort 2 (Availability Set): Availability Sets verringern die Wahrscheinlichkeit gleichzeitiger Hardwareausfälle im selben Rechenzentrum, bieten aber üblicherweise 'nur' 99,95 % SLA für mehrere VMs, nicht 99,99 %. Antwort 4 (Region-Pair VMs): Obwohl Region-Pairs für Disaster Recovery wichtig sind, definiert Azure kein standardisiertes 99,99 % SLA allein durch Verteilung auf zwei Regionen; Cross-Region-Replikation und Failover erfordern zusätzliche Konfiguration (z. B. Traffic Manager, Replikation) und sind nicht äquivalent zu zonenbasierter Verfügbarkeit. Zudem kann Cross-Region-Failover größere Latenz und Komplexität verursachen. Zusammenfassend: Für 99,99 % innerhalb einer Region sind Availability Zones die korrekte Wahl.

Step 1: Anforderungen analysieren — Die Frage fordert eine Lösung, bei der so wenig Infrastruktur wie möglich verwaltet werden soll, inklusive Wegfall von VM-Patching und OS-Konfiguration. Gleichzeitig sollen PaaS-Funktionen wie automatische Skalierung und integrierte CI/CD-Unterstützung vorhanden sein. Das charakterisiert ein klassisches PaaS-Angebot.

Step 2: Dienstvergleich — Azure App Service (Web Apps) ist ein vollständig verwalteter PaaS-Dienst, der genau diese Anforderungen erfüllt: Plattformpflege (inkl. OS- und Laufzeit-Patching) übernimmt Microsoft, eingebaute Funktionen für Skalierung, Deployment-Slots, Integration mit Azure DevOps/GitHub Actions und einfache Bereitstellung von Code oder Container-Images. Die anderen Dienste stellen eher IaaS oder Container-Hosting mit unterschiedlichem Management-Aufwand dar.

Step 3: Entscheidung — Daher ist Azure App Service die passendste Wahl, weil es die Bereitstellungs- und Betriebsaufwände minimiert und PaaS-Funktionen out-of-the-box bietet. Trap: Häufiger Irrtum ist zu glauben, dass Azure Kubernetes Service (AKS) oder Azure Container Instances (ACI) ebenfalls „kein Management“ erfordern. AKS ist zwar ein verwalteter Kubernetes-Cluster (Managed Control Plane), aber das Verwalten von Node-Pools, Container-Images, Netzwerk- und Sicherheitskonfigurationen sowie der Kubernetes-Ressourcen bleibt anspruchsvoll und ist nicht vergleichbar mit der Einfachheit einer PaaS-Web-App. ACI ist leichtgewichtig, aber eher für kurzlebige oder einfache Container-Tasks gedacht und bietet nicht die eingebaute Web-App-Funktionalität (Deployment-Slots, Easy-Scale, integriertes CI/CD) im gleichen Umfang. Why each wrong answer fails: - Azure Virtual Machines: Falsch, weil VMs IaaS sind; Sie müssen Betriebssystemupdates, Patching, Skalierungslösungen (z. B. VM Scale Sets konfigurieren) und vieles mehr selbst verwalten, was der Frage widerspricht. - Azure Kubernetes Service (AKS): Falsch in diesem Szenario, weil AKS zwar Container-Orchestrierung vereinfacht, aber dennoch ein höheres Maß an Betriebsaufwand erfordert (Kubernetes-Resourcen, Node-Pools, Persistenz, Netzwerkpolicies). Es ist nicht die minimalverwaltete PaaS-Lösung, die in der Frage gewünscht wird. - Azure Container Instances (ACI): Falsch, weil ACI für kurzfristiges oder leichtgewichtiges Hosting gedacht ist und nicht die vollständige PaaS-Funktionalität für Webanwendungen (z. B. integriertes CI/CD, Deployment-Slots, einfache skalierbare Web-App-Funktionen) bietet. ACI eignet sich eher für ad-hoc Container-Workloads oder als Ergänzung zu anderen Diensten. Zusammenfassung: Azure App Service ist die richtige Wahl, wenn Sie eine Webanwendung ohne VM-/OS-Management betreiben wollen und PaaS-Funktionen wie automatische Skalierung, integriertes CI/CD und vereinfachtes Deployment benötigen.

Step 1: Anforderungen klären: Ziel ist, dass gesamter ausgehender Traffic eines Subnetzes über eine virtuelle Firewall-Appliance in einem anderen Subnetz geleitet wird. Das ist ein Routing-Problem — Sie müssen den Next Hop für bestimmten Adressbereiche festlegen.

Step 2: Richtige Ressource auswählen: User-Defined Routes (UDRs) bzw. Route Tables erlauben Ihnen, spezifische Routen zu definieren und den next hop für bestimmte Zielpräfixe festzulegen (z. B. next hop: virtuelle Appliance in Subnet B). So leiten Sie Traffic explizit über die Firewall.

Step 3: Ergänzende Sicherheitsmaßnahmen: Kombinieren Sie UDRs mit NSGs und ggf. Azure Firewall für policy-basierte Kontrolle. UDRs lenken den Pfad, NSGs filtern je nach Port/Protokoll, und die Appliance kann tiefergehende Inspektion/Protokollierung durchführen. Trap: Häufig wird angenommen, dass NSGs ausreichend sind, um Traffic durch eine Appliance zu 'zwingen'. NSGs können Verkehr erlauben oder blockieren, aber sie ändern den Pfad nicht. Ebenso ist Azure DNS irrelevant für das Routing von IP-Paketen. Why each wrong answer fails: - "Netzwerksicherheitsgruppe (NSG)": Falsch — NSGs können Zugang basierend auf IP, Port und Protokoll erlauben oder blockieren, aber sie steuern nicht, welcher Next Hop (z. B. virtuelle Appliance) verwendet wird. NSGs alleine können den Traffic nicht über eine bestimmte Appliance leiten. - "Availability Set": Falsch — Availability Sets adressieren Hochverfügbarkeit und Verteilung von VMs innerhalb eines Rechenzentrums-Clusters; sie haben nichts mit Routing oder Traffic-Umleitung zu tun. - "Azure DNS": Falsch — Azure DNS löst Domänennamen in IP-Adressen auf. Es hat keine Funktion zur Steuerung des IP-Routings oder zum Erzwingen, dass Traffic über eine bestimmte Appliance geleitet wird. Praktische Hinweise: Wenn Sie UDRs verwenden, setzen Sie den Next Hop auf die interne IP der Firewall-VM (oder verwenden Sie Azure Firewall als managed service). Denken Sie daran, auch Rückwege (Response Traffic) zu planen und NSGs so zu konfigurieren, dass die Appliance selbst den notwendigen Traffic empfangen darf. Testen Sie den Pfad mit Tools wie tcpdump, Azure Network Watcher oder IP Flow Verify, um sicherzustellen, dass die Route wie erwartet angewendet wird.