Praxislabor — AZ-700 Microsoft Azure Network Engineer Associate

Übersicht

Voraussetzungen

Schritte

1. 1.Provider, Ressourcengruppe, Benennung

   Standard Azure-Einführung.

   Kopieren

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
     }
   }
   
   provider "azurerm" {
     features {}
   }
   
   locals {
     tags = {
       Project   = "certlabpro-az-700"
       ManagedBy = "terraform"
     }
   }
   
   resource "azurerm_resource_group" "main" {
     name     = "certlabpro-az-700-rg"
     location = "eastus"
     tags     = local.tags
   }

2. 2.Das Hub-VNet mit einem Subnetz für gemeinsam genutzte Dienste erstellen

   Ressourcen:

   • Azure Virtual Network

   Hub-Spoke ist die AZ-700-Referenztopologie. Der Hub zentralisiert gemeinsam genutzte Dienste (Firewall, VPN-Gateway, DNS-Resolver, Überwachung), und Spokes verbinden sich per Peering mit dem Hub, um auf diese zuzugreifen. Wir erstellen den Hub unter 10.0.0.0/16 mit einem Subnetz – in einem echten Hub hätten Sie ein GatewaySubnet für das VPN/ExpressRoute-Gateway, ein AzureFirewallSubnet für die Azure Firewall und ein Subnetz für gemeinsam genutzte Dienste für DNS-Resolver-Inbound-/Outbound-Endpunkte. Der Lab-Umfang ist die Topologieform; die Gateway-Dienste sind außerhalb des Umfangs (hohe Kosten).

   Kopieren

   resource "azurerm_virtual_network" "hub" {
     name                = "vnet-hub"
     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" "hub_shared" {
     name                 = "shared-services"
     resource_group_name  = azurerm_resource_group.main.name
     virtual_network_name = azurerm_virtual_network.hub.name
     address_prefixes     = ["10.0.1.0/24"]
   }

3. 3.Das Spoke-VNet mit einem NSG-geschützten App-Subnetz erstellen

   Ressourcen:

   • Azure Virtual Network

   Das Spoke-VNet unter 10.1.0.0/16 – bewusst nicht überlappend mit dem Hub. Die an das App-Subnetz angehängte NSG würde in der Produktion den Ingress auf bestimmte Quell-CIDRs beschränken; das Lab verwendet * als Quelle, damit die Architektur testbar ist.

   AZ-700 Implement core networking infrastructure behandelt wiederholt die Frage NSG pro Subnetz vs. NSG pro NIC. NSGs auf Subnetz-Ebene (dieses Lab) sind die richtige Antwort, wenn die Frage lautet „auf alle Ressourcen im Subnetz angewendet“; NIC-Ebene ist die Überschreibung.

   Kopieren

   resource "azurerm_virtual_network" "spoke" {
     name                = "vnet-spoke"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     address_space       = ["10.1.0.0/16"]
     tags                = local.tags
   }
   
   resource "azurerm_subnet" "spoke_app" {
     name                 = "app"
     resource_group_name  = azurerm_resource_group.main.name
     virtual_network_name = azurerm_virtual_network.spoke.name
     address_prefixes     = ["10.1.1.0/24"]
   }
   
   resource "azurerm_network_security_group" "spoke_app" {
     name                = "nsg-spoke-app"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
   
     security_rule {
       name                       = "AllowHttpsFromInternet"
       priority                   = 100
       direction                  = "Inbound"
       access                     = "Allow"
       protocol                   = "Tcp"
       source_port_range          = "*"
       destination_port_range     = "443"
       source_address_prefix      = "*"
       destination_address_prefix = "*"
     }
   
     tags = local.tags
   }
   
   resource "azurerm_subnet_network_security_group_association" "spoke_app" {
     subnet_id                 = azurerm_subnet.spoke_app.id
     network_security_group_id = azurerm_network_security_group.spoke_app.id
   }

4. 4.Hub und Spoke in beide Richtungen per Peering verbinden

   Ressourcen:

   • Azure Virtual Network

   VNet-Peering ist die AZ-700-Konnektivitäts-Primitive innerhalb einer Region. Zwei wichtige Eigenschaften, die die Prüfung testet:

   • Bidirektionales Peering – muss auf beiden Seiten erstellt werden (Hub-zu-Spoke UND Spoke-zu-Hub); einseitiges Peering funktioniert nicht. Terraform erstellt hier beide Ressourcen.
   • allow_forwarded_traffic – erforderlich, wenn der Hub plant, Datenverkehr von einem Spoke zu einem anderen weiterzuleiten (Transit durch eine Firewall im Hub).
   • use_remote_gateways / allow_gateway_transit – der Spoke verwendet use_remote_gateways = true, um das VPN/ER-Gateway des Hubs zu nutzen. Wir haben in diesem Lab kein Gateway, aber die Attributform wird in der Prüfung getestet.
   Kopieren

   resource "azurerm_virtual_network_peering" "hub_to_spoke" {
     name                      = "hub-to-spoke"
     resource_group_name       = azurerm_resource_group.main.name
     virtual_network_name      = azurerm_virtual_network.hub.name
     remote_virtual_network_id = azurerm_virtual_network.spoke.id
     allow_forwarded_traffic   = true
     allow_gateway_transit     = true
   }
   
   resource "azurerm_virtual_network_peering" "spoke_to_hub" {
     name                      = "spoke-to-hub"
     resource_group_name       = azurerm_resource_group.main.name
     virtual_network_name      = azurerm_virtual_network.spoke.name
     remote_virtual_network_id = azurerm_virtual_network.hub.id
     allow_forwarded_traffic   = true
     # use_remote_gateways    = true # uncomment when a gateway exists in the hub
   }

5. 5.Eine private DNS-Zone hinzufügen, die mit beiden VNets verknüpft ist

   Ressourcen:

   • Azure Private DNS

   Private DNS-Zonen sind die AZ-700-Antwort im Bereich Design and implement name resolution für die VNet-übergreifende Namensauflösung, die nicht auf Azure's Standard-DNS angewiesen ist. Wir erstellen die Zone internal.contoso.com und verknüpfen sowohl das Hub- als auch das Spoke-VNet damit. Ressourcen in beiden VNets können nun Datensätze in dieser Zone abfragen.

   Das Flag registration_enabled = true auf der Hub-Verknüpfung ermöglicht es Ressourcen im Hub, ihre Hostnamen automatisch zu registrieren. AZ-700 testet diese automatische Registrierung im Vergleich zur manuellen A-Record-Erstellung als wiederkehrende Frage „wie erhalte ich saubere DNS-Namen für meine VMs“.

   Kopieren

   resource "azurerm_private_dns_zone" "main" {
     name                = "internal.contoso.com"
     resource_group_name = azurerm_resource_group.main.name
   
     tags = local.tags
   }
   
   resource "azurerm_private_dns_zone_virtual_network_link" "hub" {
     name                  = "hub-link"
     resource_group_name   = azurerm_resource_group.main.name
     private_dns_zone_name = azurerm_private_dns_zone.main.name
     virtual_network_id    = azurerm_virtual_network.hub.id
     registration_enabled  = true # auto-register hub-resident VMs
   
     tags = local.tags
   }
   
   resource "azurerm_private_dns_zone_virtual_network_link" "spoke" {
     name                  = "spoke-link"
     resource_group_name   = azurerm_resource_group.main.name
     private_dns_zone_name = azurerm_private_dns_zone.main.name
     virtual_network_id    = azurerm_virtual_network.spoke.id
     registration_enabled  = false # spoke resources query but don't register
   
     tags = local.tags
   }

Bereinigung