Atelier pratique — AZ-305 Microsoft Azure Solutions Architect Expert

Présentation

Prérequis

Étapes

1. 1.Fournisseur, Groupe de ressources, dénomination

   Ouverture Azure standard. L'AZ-305 s'attend à ce que vous utilisiez la paire eastus / westus pour toute question sur "deux régions" — ce sont la paire de régions AZ-305 canonique pour les tests de latence et les scénarios de basculement inter-régions.

   Copier

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
       random  = { source = "hashicorp/random",  version = "~> 3.6" }
     }
   }
   
   provider "azurerm" {
     features {
       key_vault {
         purge_soft_delete_on_destroy = true
       }
     }
   }
   
   resource "random_id" "suffix" {
     byte_length = 3
   }
   
   data "azurerm_client_config" "current" {}
   
   locals {
     tags = {
       Project   = "certlabpro-az-305"
       ManagedBy = "terraform"
     }
   }
   
   resource "azurerm_resource_group" "main" {
     name     = "certlabpro-az-305-rg"
     location = "eastus"
     tags     = local.tags
   }

2. 2.Construire une topologie de VNet en étoile avec appairage

   Déploie :

   • Azure Virtual Network

   La topologie en étoile est la conception de réseau de référence de l'AZ-305 : un VNet hub central héberge les services partagés (pare-feu, passerelle VPN, DNS), et les VNets spoke hébergent les charges de travail. Les spokes s'appairent au hub de manière bidirectionnelle ; le trafic spoke-à-spoke transite par le hub. L'examen teste cette topologie à l'infini car c'est le fondement de toute zone d'atterrissage Azure à charges de travail multiples.

   Nous construisons la topologie en étoile la plus simple possible : un VNet hub (10.0.0.0/16), un spoke (10.1.0.0/16), appairage bidirectionnel. Les conceptions réelles de VNet en étoile ajoutent l'Azure Firewall dans le hub et des tables de routage next_hop_in_ip_address forçant le trafic spoke à le traverser — ceci est couvert conceptuellement mais ignoré ici pour des raisons de coût (Azure Firewall coûte environ 1 $/heure à l'arrêt).

   Copier

   resource "azurerm_virtual_network" "hub" {
     name                = "certlabpro-az-305-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"
     resource_group_name  = azurerm_resource_group.main.name
     virtual_network_name = azurerm_virtual_network.hub.name
     address_prefixes     = ["10.0.1.0/24"]
   }
   
   resource "azurerm_virtual_network" "spoke" {
     name                = "certlabpro-az-305-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_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
   }
   
   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
   }

3. 3.Provisionner un Key Vault avec autorisation RBAC pour les secrets et les certificats

   Déploie :

   • Azure Key Vault

   Key Vault est la primitive de l'AZ-305 pour les secrets et les certificats. Deux grandes décisions architecturales testées par l'examen : RBAC vs Stratégies d'accès (RBAC est la valeur par défaut moderne ; les stratégies d'accès sont héritées), et suppression logicielle + protection contre l'effacement (la suppression logicielle est activée par défaut ; la protection contre l'effacement rend la fenêtre de suppression logicielle non-modifiable — requise pour certains régimes de conformité).

   Nous activons l'autorisation RBAC et attribuons le principal Terraform actuel comme Administrateur de Key Vault afin que les ressources de secrets/certificats ultérieures fonctionnent. Les questions AZ-305 sur "l'application ne peut pas lire le mot de passe de sa base de données" se terminent 90 % du temps par "parce que l'identité gérée n'avait pas le rôle Utilisateur de secrets Key Vault sur le coffre".

   Copier

   resource "azurerm_key_vault" "main" {
     name                          = "kv-az305-${random_id.suffix.hex}"
     resource_group_name           = azurerm_resource_group.main.name
     location                      = azurerm_resource_group.main.location
     tenant_id                     = data.azurerm_client_config.current.tenant_id
     sku_name                      = "standard"
   
     enable_rbac_authorization     = true
     soft_delete_retention_days    = 7  # 7 minimum; 90 for purge protection in production
     purge_protection_enabled      = false # set true for production / compliance
     public_network_access_enabled = true
   
     tags = local.tags
   }
   
   resource "azurerm_role_assignment" "kv_admin_self" {
     scope                = azurerm_key_vault.main.id
     role_definition_name = "Key Vault Administrator"
     principal_id         = data.azurerm_client_config.current.object_id
   }

4. 4.Mettre en place Azure Front Door comme point d'entrée HTTPS global

   Déploie :

   • Azure Front Door

   Front Door est la réponse de l'AZ-305 pour les scénarios de répartiteur de charge global + WAF + CDN. L'examen le teste contre trois alternatives : Application Gateway (couche 7 régionale), Traffic Manager (basé sur DNS, pas de transit de trafic) et Load Balancer (couche 4 régionale). Front Door est la bonne réponse pour tout scénario "utilisateurs globalement distribués + HTTPS + WAF + mise en cache".

   Nous provisionnons un profil Front Door + un point de terminaison + un groupe d'origines factice. En production, vous brancheriez une application web ou un ingress AKS comme origine ; pour le laboratoire, c'est la forme de la topologie que les questions AZ-305 testent. Le niveau Standard prend en charge les fonctionnalités de sécurité et de routage attendues par l'examen (WAF, règles personnalisées, affinité de session) ; Premium ajoute des origines Private Link pour un accès backend entièrement privé.

   Copier

   resource "azurerm_cdn_frontdoor_profile" "main" {
     name                = "certlabpro-az-305-fd"
     resource_group_name = azurerm_resource_group.main.name
     sku_name            = "Standard_AzureFrontDoor"
   
     tags = local.tags
   }
   
   resource "azurerm_cdn_frontdoor_endpoint" "main" {
     name                     = "certlabpro-az-305-${random_id.suffix.hex}"
     cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.main.id
   
     tags = local.tags
   }
   
   resource "azurerm_cdn_frontdoor_origin_group" "main" {
     name                     = "app-origins"
     cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.main.id
     session_affinity_enabled = false
   
     load_balancing {
       sample_size                 = 4
       successful_samples_required = 3
     }
   
     health_probe {
       path                = "/"
       request_type        = "HEAD"
       protocol            = "Https"
       interval_in_seconds = 30
     }
   }

5. 5.Transférer les diagnostics de Front Door + Key Vault vers Log Analytics

   Déploie :

   • Azure Monitor

   Le domaine Concevoir le stockage et l'intégration des données de l'AZ-305 et le domaine Concevoir la continuité d'activité dépendent tous deux de la capacité à observer les éléments de l'architecture. Nous créons un espace de travail Log Analytics et y connectons les journaux d'accès de Front Door + les journaux d'audit de Key Vault.

   Avec la plomberie de diagnostic en place, l'architecture de référence AZ-305 est configurée : entrée globale (Front Door) → réseau en étoile → spoke de charge de travail → couche de secrets (Key Vault) → fabrique d'observabilité (Log Analytics). Chaque ajout architectural (Application Gateway derrière Front Door, Cosmos DB dans le spoke, Logic Apps dans le hub) se connecte à cette base.

   Copier

   resource "azurerm_log_analytics_workspace" "main" {
     name                = "certlabpro-az-305-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" "key_vault" {
     name                       = "diag"
     target_resource_id         = azurerm_key_vault.main.id
     log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
   
     enabled_log {
       category = "AuditEvent"
     }
   
     metric {
       category = "AllMetrics"
       enabled  = true
     }
   }
   
   resource "azurerm_monitor_diagnostic_setting" "front_door" {
     name                       = "diag"
     target_resource_id         = azurerm_cdn_frontdoor_profile.main.id
     log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
   
     enabled_log {
       category = "FrontDoorAccessLog"
     }
   
     enabled_log {
       category = "FrontDoorHealthProbeLog"
     }
   }

Nettoyage