Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der AZ-900-Prüfung mit reinem Terraform — ein Block nach dem anderen, jeweils abgestimmt auf eine Prüfungsdomäne. Derselbe Code funktioniert auch mit OpenTofu.
Am Ende dieses Labs haben Sie mit einfachem Terraform die kleinste realistische erste Azure-Workload bereitgestellt – eine Ressourcengruppe, ein Speicherkonto mit sicheren Standardeinstellungen, eine winzige Linux-VM und eine Kostenverwaltungs-Budgetwarnung, die Sie per E-Mail benachrichtigt, bevor es Ihr Geldbeutel tut. Jede Ressource ordnet sich einem der AZ-900-Prüfungsschwerpunkte zu.
Jede Ressource ist einfaches Terraform. Es gibt keine Variablen, keine Module, keinen Remote-Zustand. Fügen Sie die Snippets in eine einzelne main.tf ein, führen Sie einmal terraform init aus und dann terraform apply Schritt für Schritt.
>= 1.5 oder OpenTofu >= 1.6.az login aus; der azurerm-Provider von Terraform übernimmt das aktive Abonnement automatisch.Alle Ressourcen in diesem Lab passen in den Azure kostenlosen Tarif für neue Abonnements (200 $ Guthaben für die ersten 30 Tage, plus immer kostenlose Beträge):
Wenn Sie die VM 24/7 außerhalb des kostenlosen Tarifs am Laufen halten, kostet dies ~5 $/Monat. Zerstören Sie das Lab, wenn Sie fertig sind.
Jeder Azure Terraform-Stack beginnt auf dieselbe Weise: Fixieren Sie den azurerm-Provider (wir verwenden ~> 4.0, die aktuelle stabile Version) und deklarieren Sie den features-Block. Der leere features {}-Block ist erforderlich – azurerm wird ohne ihn nicht initialisiert. Dies ist die am häufigsten getestete AZ-900-Bereitstellungs-Konvention auf Terraform-Autoren-Ebene.
Die Ressource random_id ist das Standardmuster zum Generieren global eindeutiger Speicherkontonamen – Azure-Speicherkontonamen müssen 3–24 Zeichen lang, alphanumerisch in Kleinbuchstaben und global eindeutig über alle Azure-Abonnements hinweg sein. Die random_id fügt 4 Hexadezimalziffern zum Namen hinzu, um Kollisionen zu vermeiden.
terraform {
required_version = ">= 1.5"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
random = {
source = "hashicorp/random"
version = "~> 3.6"
}
}
}
provider "azurerm" {
features {}
}
resource "random_id" "suffix" {
byte_length = 2
}
locals {
tags = {
Project = "certlabpro-az-900"
ManagedBy = "terraform"
}
}Jede Azure-Ressource lebt in einer Ressourcengruppe – Azures universellem Organisationscontainer. RGs sind kostenlos, regional (die RG selbst ist nur Metadaten, aber ihr Inhalt ist standardmäßig auf ihre Region beschränkt) und die Einheit der Massenverwaltung: Das Löschen einer RG löscht alles darin.
Die AZ-900-Domänen Cloud-Konzepte und Azure-Identität, Governance, Datenschutz, Compliance legen großen Wert auf dieses Konzept – Ressourcengruppen sind die kleinste Scoping-Einheit für RBAC-Rollenzuweisungen, Azure Policy und Kostenverfolgung. Taggen Sie jede RG.
resource "azurerm_resource_group" "main" {
name = "certlabpro-az-900-rg"
location = "eastus"
tags = local.tags
}Azure Storage ist der grundlegende Datendienst, den jede AZ-900-Workload verwendet. Wir erstellen ein Speicherkonto der Standard-Ebene mit LRS (lokal redundant) – die günstigste Replikationsoption und der von AZ-900 erwartete Standard für Nicht-Produktions-Lab-Workloads. Der öffentliche Netzwerkzugriff ist deaktiviert, HTTPS-only ist erzwungen und die minimale TLS-Version ist auf 1.2 festgelegt (die AZ-900-Sicherheits-Domäne prüft diese drei explizit als grundlegende Standardeinstellungen für die Hygiene).
account_kind = "StorageV2" ist das aktuelle Allzweck-v2-Konto; AZ-900 wird Sie manchmal bitten, es von BlobStorage (älter, nur Blobs) und FileStorage (Premium-Dateien) zu unterscheiden. StorageV2 ist die richtige Antwort für jede „Allzweck“-Frage.
resource "azurerm_storage_account" "main" {
name = "certlabpro${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
account_tier = "Standard"
account_replication_type = "LRS"
account_kind = "StorageV2"
https_traffic_only_enabled = true
min_tls_version = "TLS1_2"
public_network_access_enabled = false
allow_nested_items_to_be_public = false
tags = local.tags
}AZ-900 widmet einen ganzen Bereich (Azure-Preise, SLAs und Lebenszyklus) Abrechnungskonzepten. Das am häufigsten getestete praktische Artefakt in diesem Bereich ist eine Budgetwarnung – der Mechanismus des Kostenmanagements, der Sie per E-Mail benachrichtigt, wenn die tatsächlichen oder prognostizierten Ausgaben einen Schwellenwert überschreiten.
Wir begrenzen das Budget auf die Ressourcengruppe, die wir in Schritt 2 erstellt haben, was bedeutet, dass es alles in diesem Lab (und nur in diesem Lab) verfolgt. Die Benachrichtigung wird bei 80 % des Budgets ausgelöst – ein wiederkehrendes AZ-900-Fragemuster ist „warum 80 % statt 100 %?“ – denn bei 80 % haben Sie noch Zeit zu handeln; bei 100 % ist das Geld bereits weg.
Ersetzen Sie you@example.com durch Ihre echte Adresse, bevor Sie terraform apply ausführen.
resource "azurerm_consumption_budget_resource_group" "main" {
name = "certlabpro-az-900-budget"
resource_group_id = azurerm_resource_group.main.id
amount = 10
time_grain = "Monthly"
time_period {
start_date = "2026-06-01T00:00:00Z"
}
notification {
enabled = true
threshold = 80
operator = "GreaterThan"
threshold_type = "Actual"
contact_emails = ["you@example.com"]
}
}Ein standardmäßiges terraform destroy reißt alles in diesem Lab ab. Eine Azure-spezifische Anmerkung: Wenn Sie die Ressourcengruppe zerstören, entfernt Azure als Nebeneffekt jede darin enthaltene Ressource – auch wenn Terraform nichts davon weiß. Dies ist die AZ-900-getestete Bereinigungs-Grundlage: Wenn Sie jemals den Überblick verlieren, was sich in einer RG befindet, löscht das Löschen der RG den gesamten Unterbaum. Verwenden Sie dies vorsichtig bei geteilten Abonnements.
Das Speicherkonto hat in neueren Abonnements standardmäßig eine 14-tägige Soft-Delete-Aufbewahrungsfrist; der Namespace bleibt für dieses Zeitfenster reserviert. Wenn Sie das Lab sofort erneut ausführen, kann es zu einer Namenskollision kommen – der random_id-Suffix umgeht dies normalerweise, ist aber nicht garantiert.
AZ-900 deckt eine breite Dienstpalette ab — Azure Virtual Machines (wir behandeln dies konzeptionell, aber implementieren in diesem minimalen Lab keine VM), App Service, Azure Functions, AKS, Azure SQL, Cosmos DB, Azure AD/Entra ID, Azure Policy, Azure Blueprints, ARM-Vorlagen, Bicep, Pricing Calculator, TCO Calculator, Azure Advisor, Service Health und viele mehr.
Wir halten uns an die kleinste realistische erste Workload, da die Prüfung breite konzeptionelle Kenntnisse testet, nicht eine detaillierte Bereitstellung einzelner Dienste. Die oben angesprochenen vier Säulen – Ressourcengruppe (Governance), Speicherkonto (Dienste + Sicherheitsstandards), Kostenmanagement (Preise) und das implizite Compute-Ziel – sind die Grundlage, an die sich jedes andere AZ-900-Konzept anschließt.
Für eine dienstspezifische Abdeckung siehe die Abschnitte Durchsuchen und Editorial dieser Zertifizierungsseite – sie verweisen auf jeden benannten Dienst im AZ-900-Umfang.