Zuletzt überprüft: Mai 2026
Erstellen Sie die AWS-Dienste der AZ-104-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 AZ-104-Referenz-Workload bereitgestellt – eine Ressourcengruppe, ein VNet mit einem NSG-geschützten privaten Subnetz, eine Linux-VM mit einer systemzugewiesenen verwalteten Identität, ein Speicherkonto, aus dem die VM über diese Identität lesen kann, und einen Log Analytics-Arbeitsbereich, der VM-Diagnosen empfängt. Jeder Block ist einer der fünf AZ-104-Prüfungsdomänen zugeordnet.
Fügen Sie die Snippets in eine einzige main.tf ein, führen Sie terraform init aus und anschließend terraform apply Schritt für Schritt.
>= 1.5 oder OpenTofu >= 1.6.az login).~/.ssh/id_rsa.pub (oder ändern Sie den Pfad in Schritt 4) für den Administrator-Login der VM.Die VM ist die Kostenursache:
Stoppen Sie die VM (az vm deallocate), wenn Sie sie nicht aktiv nutzen, um die Compute-Kosten zu halbieren. Zerstören Sie die gesamte Ressourcengruppe, um die Abrechnung vollständig zu beenden.
Standard-Azure-Eröffnung: azurerm ~> 4.0 festlegen, die Ressourcengruppe erstellen, den lokalen öffentlichen SSH-Schlüssel als Datenquelle lesen, damit die VM in Schritt 4 ihn verwenden kann. Der Bereich Identität und Governance von AZ-104 testet Ressourcengruppen als kleinsten RBAC-Bereich; Tags kaskadieren hier für die Kostenverfolgung unter Überwachen von Azure-Ressourcen.
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-104"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-az-104-rg"
location = "eastus"
tags = local.tags
}Jede AZ-104-Workload läuft innerhalb eines virtuellen Netzwerks. Wir erstellen ein /16-VNet und reservieren ein /24-Subnetz für die VM. Die an das Subnetz angehängte NSG erlaubt eingehenden SSH-Verkehr (Port 22) – in einer Produktionsumgebung würde der Quell-CIDR eingeschränkt; das Lab öffnet ihn auf *, damit Sie von jeder IP-Adresse aus eine Verbindung herstellen können.
Der AZ-104-Bereich Netzwerke bereitstellen und verwalten testet dieses geschichtete Sicherheitsmuster wiederholt: NSGs sind zustandsbehaftet, sie gelten für Subnetze oder NICs (wir wenden sie hier auf das Subnetz an – die AZ-104-Best-Practice-Antwort), und die Struktur der Standard-Ablehnungs- + expliziten Zulassungsregeln unterscheidet Azure NSGs von AWS-Sicherheitsgruppen (Azure NSGs haben explizite Regelnummern; AWS SGs nicht).
resource "azurerm_virtual_network" "main" {
name = "certlabpro-az-104-vnet"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
address_space = ["10.0.0.0/16"]
tags = local.tags
}
resource "azurerm_subnet" "app" {
name = "app"
resource_group_name = azurerm_resource_group.main.name
virtual_network_name = azurerm_virtual_network.main.name
address_prefixes = ["10.0.1.0/24"]
}
resource "azurerm_network_security_group" "app" {
name = "certlabpro-az-104-nsg"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
security_rule {
name = "AllowSSH"
priority = 100
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "22"
source_address_prefix = "*"
destination_address_prefix = "*"
}
tags = local.tags
}
resource "azurerm_subnet_network_security_group_association" "app" {
subnet_id = azurerm_subnet.app.id
network_security_group_id = azurerm_network_security_group.app.id
}Standardmäßige AZ-104-Speicherstandardeinstellungen: Standard-Tier, LRS, nur HTTPS, mindestens TLS 1.2, öffentlicher Zugriff blockiert. Wir gewähren der verwalteten Identität der VM in Schritt 4 Lesezugriff auf dieses Konto. Der Bereich Azure-Identitäten und Governance verwalten testet dieses Muster verwaltete Identität → Ressource als passwortlose Alternative zur Speicherung von Speicherkontoschlüsseln in der App-Konfiguration.
resource "azurerm_storage_account" "data" {
name = "az104data${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"
allow_nested_items_to_be_public = false
tags = local.tags
}Die VM ist das kanonische AZ-104 Compute-Artefakt. Wir verwenden Standard_B1s (die kleinste für den Free-Tier qualifizierte Linux-SKU), Ubuntu 22.04 LTS, SSH-Schlüssel-Authentifizierung (die AZ-104 Anti-Passwort-Antwort) und eine systemzugewiesene verwaltete Identität.
Die Rollenzuweisung gewährt dieser verwalteten Identität Storage Blob Data Reader für das Speicherkonto aus Schritt 3 – das bedeutet, die VM kann die Speicher-REST-APIs mit ihrem Identitäts-Token aufrufen, ohne dass Schlüssel auf der Festplatte gespeichert sind. Dies ist die AZ-104 Speicher implementieren und verwalten + Identität Crossover-Frage: Wie greift eine VM ohne Anmeldeinformationen auf den Speicher zu? Verwaltete Identität + RBAC-Rollenzuweisung.
resource "azurerm_public_ip" "vm" {
name = "certlabpro-az-104-vm-pip"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
allocation_method = "Static"
sku = "Standard"
tags = local.tags
}
resource "azurerm_network_interface" "vm" {
name = "certlabpro-az-104-vm-nic"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
ip_configuration {
name = "ipconfig1"
subnet_id = azurerm_subnet.app.id
private_ip_address_allocation = "Dynamic"
public_ip_address_id = azurerm_public_ip.vm.id
}
tags = local.tags
}
resource "azurerm_linux_virtual_machine" "main" {
name = "certlabpro-az-104-vm"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
size = "Standard_B1s"
admin_username = "azureuser"
disable_password_authentication = true
network_interface_ids = [azurerm_network_interface.vm.id]
admin_ssh_key {
username = "azureuser"
public_key = file("~/.ssh/id_rsa.pub")
}
os_disk {
caching = "ReadWrite"
storage_account_type = "Standard_LRS"
}
source_image_reference {
publisher = "Canonical"
offer = "0001-com-ubuntu-server-jammy"
sku = "22_04-lts-gen2"
version = "latest"
}
identity {
type = "SystemAssigned"
}
tags = local.tags
}
resource "azurerm_role_assignment" "vm_storage_reader" {
scope = azurerm_storage_account.data.id
role_definition_name = "Storage Blob Data Reader"
principal_id = azurerm_linux_virtual_machine.main.identity[0].principal_id
}Der AZ-104-Bereich Azure-Ressourcen überwachen und verwalten (ca. 10–15 % der Prüfung) stützt sich auf Log Analytics als Ziel für alles Beobachtbare. Wir erstellen den Arbeitsbereich und eine Diagnoseeinstellung für das Speicherkonto aus Schritt 3 – jede Speichertransaktion landet nun in abfragbarer KQL-Form.
Für die VM würden wir typischerweise den Azure Monitor Agent (AMA) über eine VM-Erweiterung installieren – das ist der moderne Pfad nach dem Log Analytics Agent. Für das Lab richten wir den Arbeitsbereich ein; die Installation des Agenten selbst ist ein separater Laufzeitschritt (azurerm_virtual_machine_extension), der unter Durchsuchen / Editorial behandelt wird. Die architektonische Form – Arbeitsbereich existiert, Ressourcen strömen hinein – ist das, was AZ-104-Fragen testen.
resource "azurerm_log_analytics_workspace" "main" {
name = "certlabpro-az-104-logs"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
sku = "PerGB2018"
retention_in_days = 30
tags = local.tags
}
resource "azurerm_monitor_diagnostic_setting" "storage" {
name = "diag"
target_resource_id = "${azurerm_storage_account.data.id}/blobServices/default/"
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
enabled_log {
category = "StorageRead"
}
enabled_log {
category = "StorageWrite"
}
metric {
category = "AllMetrics"
enabled = true
}
}terraform destroy reißt alles ab. Zwei Hinweise:
az vm deallocate die Compute-Abrechnung (Speicher wird weiterhin abgerechnet). terraform destroy entfernt alles.Static – sie überlebt die VM-Deallokation und hält die IP-Adressreservierung. Zerstören Sie sie oder wandeln Sie sie in Dynamic um, wenn Sie nicht für eine ungenutzte öffentliche IP (~0,005 $/Stunde) zahlen möchten.AZ-104 deckt ein breites Spektrum an operativen Bereichen ab – Azure Backup, Recovery Services Vault, Site Recovery, Azure Files / Azure File Sync, Azure Migrate, Application Gateway, Load Balancer, Azure Bastion, VPN Gateway, ExpressRoute, Azure Firewall, Azure Policy, Azure Blueprints (wird eingestellt), Conditional Access in Entra ID, B2B/B2C, benutzerdefinierte RBAC-Rollen und ARM-/Bicep-Vorlagen.
Wir halten uns an die VNet + VM + Speicher + Monitor-Basislinie, da sie die Grundlage ist, die jede andere AZ-104-Frage voraussetzt. Fügen Sie ein Application Gateway für Layer-7-Routing hinzu; fügen Sie ein VPN Gateway für hybride Konnektivität hinzu; fügen Sie Recovery Services Vault für Sicherungen hinzu – jedes ist eine gezielte Erweiterung dieser Basis.
Für eine servicebezogene Abdeckung siehe die Abschnitte Durchsuchen, Handbuch und Editorial dieser Zertifizierungsseite.