ハンズオンラボ — AZ-305 Microsoft Azure Solutions Architect Expert

概要

前提条件

ステップ

1. 1.プロバイダー、リソースグループ、命名

   標準的なAzureの導入部分です。AZ-305では、「2リージョン」に関する質問に対して eastus / westus のペアを使用することが期待されます。これらは、遅延テストやペアリージョンでのフェールオーバーシナリオにおける、AZ-305の標準的なリージョンペアです。

   コピー

   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.ピアリングでハブ・スポークVNetトポロジを構築する

   プロビジョニング対象:

   • Azure Virtual Network

   ハブ・スポークはAZ-305の参照ネットワーク設計です。中央の ハブ VNetが共有サービス（ファイアウォール、VPNゲートウェイ、DNS）をホストし、スポーク VNetがワークロードをホストします。スポークはハブと双方向にピアリングし、スポーク間のトラフィックはハブを経由します。このトポロジは、あらゆるマルチワークロードAzureランディングゾーンの基盤であるため、試験で繰り返し問われます。

   ここでは、最もシンプルなハブ・スポーク（ハブVNet 1つ（10.0.0.0/16）、スポークVNet 1つ（10.1.0.0/16）、双方向ピアリング）を構築します。実際のハブ・スポーク設計では、ハブにAzure Firewallを追加し、next_hop_in_ip_address ルートテーブルでスポークトラフィックを強制的に経由させますが、ここではコストの都合上（Azure Firewallはアイドル時で1時間あたり約1ドル）割愛します。この概念は説明します。

   コピー

   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.シークレットと証明書用にRBAC認証を備えたKey Vaultをプロビジョニングする

   プロビジョニング対象:

   • Azure Key Vault

   Key VaultはAZ-305のシークレットおよび証明書に関する基本要素です。試験で問われる大きなアーキテクチャ上の決定には、RBACとアクセスポリシーの比較 (RBACが現代のデフォルトであり、アクセスポリシーはレガシーです) と、論理削除 + 消去保護 (論理削除はデフォルトで有効になっており、消去保護は論理削除期間を上書きできないようにするものです。これは一部のコンプライアンス要件に必要です) があります。

   ここではRBAC認証を有効にし、現在のTerraformプリンシパルをKey Vault管理者として割り当てることで、後続のシークレット/証明書リソースが機能するようにします。「アプリケーションがデータベースパスワードを読み取れない」というAZ-305の質問の90%は、「マネージドIDにKey Vaultシークレットユーザーのロールが割り当てられていなかったため」という結果に終わります。

   コピー

   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.グローバルHTTPSエントリポイントとしてAzure Front Doorを立ち上げる

   プロビジョニング対象:

   • Azure Front Door

   Front DoorはAZ-305における グローバルロードバランサー + WAF + CDN の解答です。試験では、Application Gateway (リージョンL7)、Traffic Manager (DNSベース、トラフィック通過なし)、Load Balancer (リージョンL4) の3つの代替手段と比較して問われます。Front Doorは、「グローバルに分散したユーザー + HTTPS + WAF + キャッシュ」のあらゆるシナリオにおいて適切な解答です。

   ここでは、Front Doorプロファイル + エンドポイント + スタブオリジングループをプロビジョニングします。本番環境では、WebアプリまたはAKSイングレスをオリジンとして接続しますが、このラボではAZ-305の質問で問われるトポロジの形が重要です。Standardティアは、試験で期待されるセキュリティ機能とルーティング機能（WAF、カスタムルール、セッションアフィニティ）をサポートし、Premiumティアは完全にプライベートなバックエンドアクセス用のプライベートリンクリソースを追加します。

   コピー

   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.Front DoorとKey Vaultの診断情報をLog Analyticsにパイプする

   プロビジョニング対象:

   • Azure Monitor

   AZ-305の「データストレージと統合の設計」ドメインと「事業継続性の設計」ドメインは、いずれもアーキテクチャ要素に関する可観測性に依存します。ここでは、Log Analyticsワークスペースを作成し、Front DoorのアクセスログとKey Vaultの監査ログをそこに接続します。

   診断のための配管が整うことで、AZ-305の参照アーキテクチャが形作られます。すなわち、グローバルイングレス（Front Door）→ハブ・スポークネットワーク→ワークロードスポーク→シークレットレイヤー（Key Vault）→可観測性ファブリック（Log Analytics）です。追加されるすべてのアーキテクチャ要素（Front Doorの背後にあるApplication Gateway、スポーク内のCosmos DB、ハブ内のLogic Appsなど）は、この基盤に接続されます。

   コピー

   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"
     }
   }

クリーンアップ