Microsoft AZ-900: Azure-Architektur & Globale Infrastruktur — Lernleitfaden

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Teil des Microsoft Azure AZ-900 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Die globale Architektur von Azure ist darauf ausgelegt, resiliente, performante und konforme Cloud-Dienste in großem Umfang bereitzustellen. Das Verständnis des physischen Aufbaus von Geografien, Regionen und Verfügbarkeitszonen sowie der logischen Hierarchie von Verwaltungsgruppen, Abonnements, Ressourcengruppen und Ressourcen ist die Grundlage für zuverlässiges Design und Governance. Die von Azure Resource Manager bereitgestellte Steuerungsebene ermöglicht in Kombination mit deklarativen Vorlagen konsistente, wiederholbare Bereitstellungen, die den Unternehmensrichtlinien und Sicherheitsanforderungen entsprechen. Designentscheidungen in diesem Bereich beeinflussen direkt die Verfügbarkeitsziele, die Verpflichtungen zur Datenresidenz und die Benutzererfahrung weltweit. Die Auswahl des richtigen Redundanzmodells, die Berechnung zusammengesetzter SLAs und die Wahl globaler Routing-Dienste wie Azure Front Door, Traffic Manager und Azure CDN sind entscheidend für die Erfüllung der Ziele in den Bereichen Geschäftskontinuität, Compliance und Leistung.

Geografien, Regionen, Verfügbarkeitszonen und Regionspaare

Azure-Geografien sind definierte Sätze von Regionen, die die Grenzen für Datenresidenz und Compliance wahren. Beispiele hierfür sind die Vereinigten Staaten, Europa, das Vereinigte Königreich, Australien und Kanada sowie souveräne Clouds mit eigenen Compliance- und Konnektivitätsmodellen. Workloads, die innerhalb einer bestimmten Gerichtsbarkeit verbleiben müssen, sollten in Regionen bereitgestellt werden, die zur Zielgeografie gehören, um die Einhaltung gesetzlicher Vorschriften und die Datenresidenz sicherzustellen. Eine Region ist eine Gruppe von Rechenzentren, die innerhalb eines durch Latenz definierten Perimeters bereitgestellt und über ein dediziertes Netzwerk mit geringer Latenz verbunden sind. Nicht alle Dienste oder Funktionen sind in jeder Region verfügbar, daher sollten Kapazität und Funktionsverfügbarkeit frühzeitig in der Planung überprüft werden. Regionen, die Verfügbarkeitszonen (Availability Zones) unterstützen, bieten drei oder mehr physisch getrennte Rechenzentrumszonen mit unabhängiger Stromversorgung, Kühlung und Vernetzung. Zonenredundante Dienste (ZRS) und eine zonenübergreifende Architektur schützen vor Ausfällen auf Rechenzentrumsebene und gewährleisten gleichzeitig einen Zugriff mit geringer Latenz innerhalb der Region. Jede Azure-Region ist mit einer anderen Region innerhalb derselben Geografie zu einem Regionspaar (Region Pair) verbunden (z. B. „North Europe“ mit „West Europe“, „East US“ mit „West US“). Regionspaare ermöglichen eine priorisierte Wiederherstellung bei weitreichenden Ausfällen, gestaffelte Plattform-Updates und die Datenreplikation für bestimmte Dienste. Die georedundanten Optionen von Azure Storage (GRS/GZRS) replizieren Daten asynchron in die gekoppelte Region; wenn Lesezugriff auf die sekundäre Region erforderlich ist, verwenden Sie RA-GRS oder RA-GZRS, um Lesevorgänge vom sekundären Endpunkt während eines Ausfalls oder eines geplanten Failovers zu ermöglichen. Für geschäftskritische Workloads, die sowohl Hochverfügbarkeit innerhalb der Region als auch eine regionsübergreifende Notfallwiederherstellung erfordern, kombinieren Sie Zonenredundanz mit der Replikation über Regionspaare. Das Abwägen von Latenz, Resilienz und Compliance führt zu einem gängigen Muster: Aktive Workloads werden zonenübergreifend in einer primären Region bereitgestellt und durch die Replikation von Daten und die Bereitstellung von Failover-Pfaden zur gekoppelten Region vor regionalen Katastrophen geschützt. Überprüfen Sie regelmäßig Failover-Runbooks und das DNS- oder Front-End-Routing-Verhalten, um sicherzustellen, dass die Wiederherstellungsziele erreicht werden.

• Geografie
  • Umfang: Regionsübergreifende Grenze
  • Hauptvorteil: Datenresidenz und Compliance
  • Typische Verwendung: Einhaltung gesetzlicher Vorschriften (z. B. EU-Daten)
• Region
  • Umfang: Einzelner Ballungsraum
  • Hauptvorteil: Zugriff auf Dienste mit geringer Latenz
  • Typische Verwendung: Primärer Bereitstellungsstandort
• Verfügbarkeitszone (Availability Zone)
  • Umfang: Getrennte Rechenzentren innerhalb einer Region
  • Hauptvorteil: Fehlertoleranz auf Rechenzentrumsebene
  • Typische Verwendung: Hochverfügbarkeit innerhalb der Region
• Regionspaar (Region Pair)
  • Umfang: Zwei Regionen in derselben Geografie
  • Hauptvorteil: Koordinierte Wiederherstellung und Updates
  • Typische Verwendung: Regionsübergreifende Notfallwiederherstellung

Ressourcenorganisation und Governance: Verwaltungsgruppen, Abonnements, Ressourcengruppen und Ressourcen

Die Verwaltungshierarchie von Azure ermöglicht die Steuerung von Richtlinien, Zugriff und Kosten im großen Maßstab. Verwaltungsgruppen stehen über den Abonnements und ermöglichen es Ihnen, Azure Policy und die rollenbasierte Zugriffssteuerung (RBAC) zentral anzuwenden, wobei die Vererbung auf untergeordnete Verwaltungsgruppen und Abonnements kaskadiert. Dies ist das richtige Konstrukt für die Segmentierung nach Unternehmensbereichen, Umgebungsstufen (Produktion, Nicht-Produktion) oder regulatorischen Grenzen, während einheitliche Leitplanken beibehalten werden. Abonnements sind die Grenze für Verwaltung, Abrechnung und Kontingente. Sie eignen sich gut, um Kosten und Zugriff für Geschäftseinheiten, Umgebungen oder Anwendungen zu isolieren. Verwenden Sie ein konsistentes Abonnementdesign, um die Produktion von der Nicht-Produktion zu trennen und um Limits und Budgets durchzusetzen. Weisen Sie bei Organisationen mit mehreren Abteilungen und dezentraler Verwaltung jeder Abteilung ein oder mehrere Abonnements zu und ordnen Sie diese abteilungsspezifischen Verwaltungsgruppen unter, um eine saubere Vererbung von Richtlinien und RBAC zu gewährleisten. Ressourcengruppen sind logische Container für Ressourcen, die einen gemeinsamen Lebenszyklus haben. Sie ermöglichen atomare Bereitstellungen, konsistente Kennzeichnung (Tagging) und Lebenszyklus-Operationen wie Löschen oder Sperren. Gruppieren Sie Ressourcen, die gemeinsam bereitgestellt, aktualisiert und außer Betrieb genommen werden, wie z. B. eine Web-Ebene und ihre Überwachungskomponenten. Verwenden Sie Tags, um die interne Kostenverrechnung (Chargeback/Showback), den Besitz, die Umgebung und Compliance-Attribute über Ressourcen und Gruppen hinweg zu steuern. Sperren (ReadOnly, CanNotDelete) bieten auf Ressourcen- oder Gruppenebene Schutz vor versehentlichem Löschen. Ressourcen sind die bereitgestellten Dienstinstanzen (VMs, App Service-Pläne, Speicherkonten). RBAC-Bereiche (Verwaltungsgruppe, Abonnement, Ressourcengruppe, Ressource) ermöglichen die Vergabe von Zugriffsrechten mit den geringsten Privilegien genau dort, wo sie benötigt werden. Behalten Sie bei Bereitstellungen über mehrere Abteilungen hinweg einen einzigen Microsoft Entra ID-Mandanten bei, es sei denn, es besteht eine starke Compliance- oder Autonomieanforderung für mehrere Mandanten; Abonnements und Verwaltungsgruppen bieten in der Regel eine ausreichende Trennung bei weitaus geringerem Verwaltungsaufwand.

• Verwaltungsgruppe
  • Hauptzweck: Organisationsweite Governance
  • Angewandte Kontrollen: RBAC, Policy, Blueprints (über Policy + Vorlagen)
  • Gängige Muster: Segmentierung nach Abteilung/Regulierung
• Abonnement
  • Hauptzweck: Abrechnungs- und Kontingentgrenze
  • Angewandte Kontrollen: Budgets, RBAC, Policy
  • Gängige Muster: Isolierung pro Geschäftsbereich oder pro Umgebung
• Ressourcengruppe
  • Hauptzweck: Lebenszyklusgrenze
  • Angewandte Kontrollen: Sperren, Tags, RBAC
  • Gängige Muster: Pro Anwendung oder Workload-Einheit
• Ressource
  • Hauptzweck: Dienstinstanz
  • Angewandte Kontrollen: RBAC auf Instanzebene, Tags
  • Gängige Muster: Einzelne Dienstkomponenten

Azure Resource Manager und Vorlagen

Azure Resource Manager (ARM) ist die Steuerungsebene für die Bereitstellung, Aktualisierung und Löschung von Azure-Ressourcen über eine konsistente API und ein rollenbasiertes Modell. ARM bietet idempotente Operationen, Abhängigkeitsmanagement, Tagging und die Durchsetzung von Richtlinien zum Zeitpunkt der Bereitstellung, wodurch die Plattform-Governance in jede Änderung eingebettet werden kann. Deklarative ARM-Vorlagen beschreiben den gewünschten Zustand Ihrer Umgebung in JSON und unterstützen Parameter, Variablen, Bedingungen und modulare verknüpfte Vorlagen. Sie ermöglichen wiederholbare, versionierte Bereitstellungen über Umgebungen und Abonnements hinweg. Für eine optimierte Erstellungserfahrung bietet Bicep eine prägnante Syntax, die zu ARM-Vorlagen transpiliert wird, während dieselbe Bereitstellungs-Engine und dieselben Vorteile beibehalten werden. Speichern Sie Vorlagen in der Quellcodeverwaltung, packen Sie sie als Vorlagenspezifikationen (Template Specs) zum Teilen und integrieren Sie sie in CI/CD-Pipelines, um driftfreie, auditierbare Infrastrukturänderungen sicherzustellen. Sensible Werte wie Administratorkennwörter oder Verbindungszeichenfolgen sollten niemals in Vorlagen eingebettet werden. Verwenden Sie secureString/secureObject-Parameter mit Key Vault-Referenzen, damit ARM Geheimnisse zum Zeitpunkt der Bereitstellung abruft, ohne sie in Protokollen preiszugeben. Kombinieren Sie Vorlagen mit verwalteten Identitäten (Managed Identities), um hartcodierte Anmeldeinformationen in der Automatisierung zu eliminieren. Dieser Ansatz reduziert das Risiko und erhält gleichzeitig die vollständige Automatisierung für umfangreiche Bereitstellungen über mehrere Abonnements hinweg.

• Idempotente Bereitstellungen
  • ARM/Vorlagen-Unterstützung: Ja
  • Ergebnis: Sichere, wiederholbare Änderungen
• Richtliniendurchsetzung bei der Bereitstellung
  • ARM/Vorlagen-Unterstützung: Ja
  • Ergebnis: Leitplanken in Pipelines integriert
• Modularer Aufbau
  • ARM/Vorlagen-Unterstützung: Verknüpfte Module / Bicep-Module
  • Ergebnis: Wiederverwendbarkeit und Standardisierung
• Umgang mit Geheimnissen
  • ARM/Vorlagen-Unterstützung: Key Vault-Referenzen
  • Ergebnis: Keine Geheimnisse in Code oder Protokollen

Verfügbarkeit, SLAs, Composite-SLAs und Service-Lebenszyklus

Azure veröffentlicht finanziell abgesicherte Service-Level-Agreements (SLAs) für allgemein verfügbare (GA) Dienste. Für virtuelle Maschinen hängt die Verfügbarkeit von der Bereitstellungstopologie ab: Eine einzelne VM mit Premium-SSD-Speicher hat ein SLA von 99,9 %; zwei oder mehr VMs in einer Verfügbarkeitsgruppe (Availability Set) haben ein SLA von 99,95 %; und zwei oder mehr VMs, die über Verfügbarkeitszonen (Availability Zones) verteilt sind, erreichen ein SLA von 99,99 %. Plattformdienste (z. B. Azure SQL Database oder App Service) haben ihre eigenen SLAs, die je nach Tarif (Tier) oder Redundanzoption variieren können. Richten Sie die Architektur am Ziel-SLA aus, indem Sie das passende Redundanzmodell und die entsprechenden Service-Tiers auswählen. Wenn eine Lösung von mehreren Diensten abhängt, ist das Composite-SLA das Produkt der einzelnen SLAs, falls alle Komponenten für die Funktion der App erforderlich sind. Wenn beispielsweise eine Web-App (99,95 %) von einer Datenbank (99,99 %) abhängt, beträgt die Composite-Verfügbarkeit ungefähr 0,9995 × 0,9999 = 99,94 %. Die Erhöhung der Redundanz auf jeder Ebene – wie die Bereitstellung über Zonen hinweg, das Hinzufügen mehrerer Instanzen hinter einem Load Balancer oder die Verwendung georedundanter Datenspeicher – verbessert die effektive Verfügbarkeit. Umgekehrt senkt das Hinzufügen serieller Abhängigkeiten das Composite-SLA und sollte durch einen klaren funktionalen Mehrwert gerechtfertigt sein. Der Status im Service-Lebenszyklus beeinflusst die Zuverlässigkeitsgarantien. Public-Preview-Features werden angeboten, um Feedback zu sammeln, und können auf bestimmte Regionen beschränkt sein oder Funktionslücken aufweisen; sie haben in der Regel kein SLA und werden nicht für produktionskritische Pfade empfohlen. GA-Features (General Availability) sind produktionsreif und durch ein SLA abgedeckt. Roadmaps und Zeitpläne für die Einführung in den Regionen sollten verfolgt werden, um eine unbeabsichtigte Abhängigkeit von Preview-Features in Produktionsdesigns zu vermeiden, insbesondere in compliance-sensitiven Umgebungen. Ziele für die Notfallwiederherstellung (Disaster Recovery) wie RPO und RTO ergänzen SLAs und leiten Designentscheidungen wie zonen- oder regionsübergreifende Replikation, Backup-Frequenz und Failover-Orchestrierung. Validieren Sie Failover-Verfahren regelmäßig, um sicherzustellen, dass die gemessene Wiederherstellungsleistung den Geschäftszielen entspricht und dass auch DNS-, Zertifikats- und Identitätsabhängigkeiten wie erwartet wiederhergestellt werden.

• Einzelne VM (Premium SSD)
  • Indikatives SLA: 99,9 %
  • Hinweise: Für unkritische Workloads oder tolerante Apps verwenden
• 2+ VMs in einer Verfügbarkeitsgruppe (Availability Set)
  • Indikatives SLA: 99,95 %
  • Hinweise: Schützt vor Ausfällen von Racks/Fehlerdomänen (Fault Domains)
• 2+ VMs über Verfügbarkeitszonen (Availability Zones) verteilt
  • Indikatives SLA: 99,99 %
  • Hinweise: Schützt vor Ausfällen auf Rechenzentrumsebene
• Public-Preview-Feature
  • Indikatives SLA: Kein finanziell abgesichertes SLA
  • Hinweise: Evaluieren; auf kritischen Pfaden vermeiden
• GA-Feature (abhängig vom Service-Tier)
  • Indikatives SLA: SLA-abgesichert
  • Hinweise: Tier- und regionsspezifische SLAs prüfen

Globales Routing und Content Delivery: Azure Front Door, Traffic Manager und Azure CDN

Die globale Benutzererfahrung hängt von intelligentem Routing, der Nähe zum Inhalt und schnellem Failover ab. Azure Front Door ist ein globaler Anycast-Layer-7-Reverse-Proxy mit Web Application Firewall (WAF), TLS-Terminierung, URL/pfadbasiertem Routing, Sitzungsaffinität (Session Affinity) und Systemdiagnosen (Health Probes) vom Edge. Es beschleunigt dynamische Inhalte durch Split-TCP und Protokolloptimierungen und bietet ein nahezu sofortiges Failover zwischen den Ursprüngen (Origins). Front Door ist ideal für aktiv-aktive oder aktiv-passive, über mehrere Regionen verteilte Webanwendungen und APIs, bei denen sowohl Leistung als auch zentralisierte Sicherheit am Edge erforderlich sind. Azure Traffic Manager ist ein DNS-basierter Dienst zur Datenverkehrsverteilung, der Clients unter Verwendung von Richtlinien wie Priorität, Gewichtung, Leistung (Latenz), geografisch, Subnetz oder Mehrwert (Multivalue) zum besten Endpunkt leitet. Da er auf DNS-Ebene arbeitet, unterstützt er Nicht-HTTP-Endpunkte (z. B. TCP-Dienste) und hybride Szenarien, aber die Failover-Geschwindigkeit wird durch die DNS-TTL und das Client-Caching begrenzt. Traffic Manager fungiert nicht als Proxy für den Datenverkehr und beschleunigt keine Inhalte; er beantwortet lediglich DNS-Anfragen mit dem ausgewählten Endpunkt. Azure CDN speichert statische Inhalte an Edge-Points-of-Presence zwischen, um die Latenz zu reduzieren und die Ursprünge zu entlasten. Es eignet sich gut für große statische Assets wie Bilder, Videos, Skripte und Downloads. Obwohl ein CDN die Roundtrips für zwischenspeicherbare Inhalte reduziert, ist es kein zustandssensitiver globaler Load Balancer für dynamische Ursprünge; kombinieren Sie es mit Front Door oder Traffic Manager für ein Failover mit mehreren Ursprüngen oder für dynamische Routing-Logik. Viele Architekturen platzieren ein CDN für das Caching statischer Assets und Front Door für dynamischen Datenverkehr und Sicherheit vor derselben Anwendung.

• Azure Front Door (Std/Prm)
  • Ebene/Mechanismus: Layer-7-Anycast-Proxy
  • Primäre Anwendungsfälle: Globales Load Balancing, Edge-Sicherheit, Beschleunigung
  • Routing-Methoden: Priorität, Gewichtung; pfad-/hostbasierte Regeln
  • Systemdiagnose (Health Probing): Edge-POP-Probes
  • Failover-Geschwindigkeit: Sekunden (nahezu sofort)
  • Dynamische Beschleunigung: Ja
  • Statisches Caching: Ja (regelbasiert)
  • WAF verfügbar: Ja (integriert)
  • Typisches Muster: Front Door vor über mehrere Regionen verteilten Web-Apps/APIs
• Azure Traffic Manager
  • Ebene/Mechanismus: DNS-basierte Richtlinie
  • Primäre Anwendungsfälle: Regionsübergreifendes DNS-Routing; Nicht-HTTP-Endpunkte
  • Routing-Methoden: Priorität, Gewichtung, Leistung, geografisch, Subnetz, Mehrwert (Multivalue)
  • Systemdiagnose (Health Probing): Globale Endpunkt-Probes
  • Failover-Geschwindigkeit: TTL-gebunden (zehn Sekunden bis Minuten)
  • Dynamische Beschleunigung: Nein
  • Statisches Caching: Nein
  • WAF verfügbar: N/A
  • Typisches Muster: DNS-Steuerung für HTTP- und Nicht-HTTP-Dienste
• Azure CDN
  • Ebene/Mechanismus: Edge-Caching-Netzwerk
  • Primäre Anwendungsfälle: Entlastung durch statische Inhalte und Latenzreduzierung
  • Routing-Methoden: N/A (Cache-Regeln)
  • Systemdiagnose (Health Probing): N/A (optionales Failover der Ursprungsgruppe)
  • Failover-Geschwindigkeit: N/A (cache-basiert)
  • Dynamische Beschleunigung: Nein (über Cache hinaus)
  • Statisches Caching: Ja
  • WAF verfügbar: Über Front Door Premium oder separate WAF
  • Typisches Muster: CDN für Assets + Front Door/Traffic Manager für Ursprünge

Praktisches Problem: Entwurf einer hochverfügbaren, konformen und global performanten Webplattform für IronPeak Manufacturing

Szenario: IronPeak Manufacturing ist in Europa und Nordamerika tätig und konsolidiert Kunden- und Partnerportale auf Azure. Die Plattform muss eine Verfügbarkeit von 99,99 % für die Web-Ebene erfüllen, EU-Kundendaten innerhalb der EU halten, ein schnelles Failover zwischen Regionen ermöglichen und weltweit schnelle Ladezeiten für Seiten liefern. Das Team wünscht sich vollständig automatisierte Bereitstellungen ohne Klartext-Geheimnisse im Code oder in Protokollen.

Herausforderung: Erreichen von Hochverfügbarkeit innerhalb einer Region und regionsübergreifender Notfallwiederherstellung mit Datenresidenz in der EU, globaler Beschleunigung und Failover für dynamischen Datenverkehr sowie wiederholbaren, sicheren Bereitstellungen über Abonnements hinweg.

Empfohlener Ansatz:

1. Wählen Sie die Geografie Europa und stellen Sie die primäre Workload in einer Region mit Verfügbarkeitszonen (z. B. West Europe) bereit, indem Sie zwei oder mehr Instanzen von VM-Skalierungsgruppen oder App Service-Instanzen verwenden, die über die Zonen verteilt sind.
2. Aktivieren Sie die regionsübergreifende Notfallwiederherstellung in der gekoppelten Region (North Europe) mithilfe der nativen Replikation der Dienste: Verwenden Sie RA-GZRS für Storage und Geo-Replikation für Datenbanken, sofern verfügbar; konfigurieren Sie automatisierte Failover-Runbooks.
3. Stellen Sie der Anwendung Azure Front Door Standard/Premium für globale HTTPS-Terminierung, WAF, Edge-Integritätstests, prioritätsbasiertes Failover zwischen West Europe (primär) und North Europe (sekundär) sowie Regeln für pfadbasiertes Routing voran.
4. Cachen Sie statische Assets (Bilder, Skripte, Downloads) mit Azure CDN, das mit denselben Ursprüngen integriert ist, um die Latenz zu reduzieren und den Datenverkehr zu entlasten; validieren Sie Cache-Regeln und TTLs.
5. Definieren Sie Verwaltungsgruppen für die EU- und NA-Divisionen; ordnen Sie Produktions- und Nicht-Produktions-Abonnements unter jeder Gruppe an und wenden Sie Azure Policy für Datenresidenz, Tagging und zulässige Standorte an.
6. Implementieren Sie ARM/Bicep-Vorlagen, die in der Quellcodeverwaltung gespeichert und als Vorlagenspezifikationen veröffentlicht werden; parametrisieren Sie Regionen, SKUs und Skalierung; referenzieren Sie Geheimnisse aus Azure Key Vault mithilfe von verwalteten Identitäten für Bereitstellungen.
7. Legen Sie SLAs fest und testen Sie die zusammengesetzte Verfügbarkeit: Zwei zonenverteilte Instanzen hinter Front Door zielen auf 99,99 % für die App-Ebene ab; validieren Sie vierteljährlich End-to-End-Failover-Übungen, DNS, Zertifikate und Identitätsabhängigkeiten.
8. Instrumentieren Sie die Plattform mit Application Insights und Azure Monitor; konfigurieren Sie Front Door-Integritätstests und Benachrichtigungen; passen Sie Autoskalierungs- und Caching-Richtlinien basierend auf Telemetriedaten an.

Azure-Begründung: Dieses Design hält EU-Daten innerhalb der Geografie Europa und bietet gleichzeitig eine regionsinterne Fehlerisolierung durch Verfügbarkeitszonen und eine regionsübergreifende Notfallwiederherstellung in der gekoppelten Region. Azure Front Door liefert globale Beschleunigung und ein zustandsabhängiges Failover für dynamischen Datenverkehr, während Azure CDN statische Inhalte zur Leistungssteigerung entlastet. ARM/Bicep-Vorlagen mit Key Vault-Referenzen ermöglichen wiederholbare, sichere Bereitstellungen über Abonnements und Regionen hinweg. Die gewählten Topologien entsprechen den veröffentlichten SLAs, um das Ziel von 99,99 % für die Web-Ebene zu erreichen, und Richtlinien auf Ebene der Verwaltungsgruppe und des Abonnements setzen Governance mit minimalem Betriebsaufwand durch.

← Cloud-Konzepte · Alle Domänen · Compute- →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →