最終確認: 2026年5月
DP-300 試験の対象となる AWS サービスを、プレーンな Terraform を使用して構築します。1 ブロックずつ、それぞれ試験ドメインに関連付けられています。同じコードが OpenTofu でも動作します。
このラボの終了までに、素のTerraformを使用して、運用環境に対応したAzure SQL Databaseをプロビジョニングできます。具体的には、Microsoft Entra専用認証を持つサーバー、最も安価な有料ティアの単一データベース、専用ストレージアカウントにパイプされる監査、脅威検出アラート付きのMicrosoft Defender for SQL、およびすべてのサーバー診断を受信するLog Analyticsを含みます。これはDP-300の参照ベースラインです。
これらのスニペットを単一の main.tf ファイルにドロップし、terraform init を実行した後、terraform apply をステップバイステップで実行してください。
>= 1.5 または OpenTofu >= 1.6。az login) — サインインしたIDがステップ3でSQL ServerのEntra管理者になります。enabled = false を設定すると、脅威保護リソースは課金されません。スタック全体で、Defenderが有効かどうかによって月額約5〜20ドル。速やかに破棄してください。
標準的なAzureの開始点です。
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 = 3
}
data "azurerm_client_config" "current" {}
locals {
tags = {
Project = "certlabpro-dp-300"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-dp-300-rg"
location = "eastus"
tags = local.tags
}DP-300の「セキュアな環境の実装」ドメインでは、ワークロードデータと監査データの分離がテストされます。一般的な運用パターンとして、監査ログ専用のストレージアカウントを用意し、ワークロード自身のストレージとは異なる保持ポリシー（より長く）と厳格なアクセス制御を適用します。
ここでは、監査アカウントをプロビジョニングし、90日間のBLOB保持期間を設定し（多くの規制対象業界におけるSQL監査ストレージ要件に合致）、パブリックアクセスをロックダウンします。ステップ3のSQL Serverは、ここに監査ログを書き込みます。
resource "azurerm_storage_account" "audit" {
name = "dp300audit${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
blob_properties {
delete_retention_policy {
days = 90
}
}
tags = local.tags
}Entra専用認証 (azuread_authentication_only = true) は、DP-300の運用におけるベストプラクティスの回答です。これにより、SQL認証管理者ログインが完全に無効になり、すべての接続がEntra ID経由に強制されます。試験ではこのパターンが繰り返しテストされます。
Entra管理者ブロックは現在のTerraformプリンシパルを指定します。つまり、terraform apply の実行後、az login のIDを使用して sqlcmd -G 経由で接続でき、SQLパスワードはどこにも必要ありません。基盤となるデータベースは最小のBasicティアです。断続的な負荷を持つ運用ワークロード（アイドル後の自動一時停止）には、General Purpose Serverlessに切り替えてください。
resource "azurerm_mssql_server" "main" {
name = "sql-dp300-${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
version = "12.0"
minimum_tls_version = "1.2"
public_network_access_enabled = true
# Entra-only mode: no SQL admin login created.
azuread_administrator {
login_username = "sqladmins"
object_id = data.azurerm_client_config.current.object_id
azuread_authentication_only = true
}
identity {
type = "SystemAssigned"
}
tags = local.tags
}
resource "azurerm_mssql_database" "main" {
name = "app"
server_id = azurerm_mssql_server.main.id
sku_name = "Basic"
max_size_gb = 2
tags = local.tags
}SQL Serverレベルの監査は、すべてのDBCCコマンド、スキーマ変更、ログイン試行、および付与/取り消しをキャプチャします。これをステップ2で作成したストレージアカウントに90日間の保持期間で接続します。ステップ3のSQL ServerのマネージドIDには、監査アカウントに対する Storage Blob Data Contributor ロールが付与されます。これは、ストレージアカウントキーベースの認証よりもDP-300が推奨するIDベースの認証パターンです。
サーバーレベルの監査は、サーバー配下のすべてのデータベースに適用されます。試験では、サーバーレベル監査（これ）とデータベースレベル監査（データベースごとの上書き）の違いがテストされます。サーバーレベル監査は、「すべてのデータベースを監査する必要がある」という質問に対する正しい回答です。
resource "azurerm_role_assignment" "sql_audit_writer" {
scope = azurerm_storage_account.audit.id
role_definition_name = "Storage Blob Data Contributor"
principal_id = azurerm_mssql_server.main.identity[0].principal_id
}
resource "azurerm_mssql_server_extended_auditing_policy" "main" {
server_id = azurerm_mssql_server.main.id
storage_endpoint = azurerm_storage_account.audit.primary_blob_endpoint
retention_in_days = 90
log_monitoring_enabled = true
depends_on = [azurerm_role_assignment.sql_audit_writer]
}Microsoft Defender for SQLは、DP-300の「監視と最適化」ドメインにおける脅威検出の回答です。SQLインジェクションの試み、異常なログイン場所、ブルートフォース攻撃、および異常な特権昇格をスキャンします。高度な脅威保護リソースはサーバーごとの有効化であり、セキュリティアラートポリシーは脅威が検出された際に誰にメールが送信されるかを構成します。
また、Log Analyticsワークスペースを接続し、データベース診断情報（SQLインサイト、クエリストアメトリック、エラー）をそこにパイプします。この最後のピースが整うことで、DP-300の強化されたSQLベースラインが構築されます。すなわち、Entra専用認証、サーバー監査、脅威検出、Log Analyticsによる可観測性です。DP-300の「管理と構成」に関するすべての質問は、これらの基本要素のいずれかに着地します。
resource "azurerm_log_analytics_workspace" "main" {
name = "log-dp300"
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_mssql_server_security_alert_policy" "main" {
resource_group_name = azurerm_resource_group.main.name
server_name = azurerm_mssql_server.main.name
state = "Enabled"
email_account_admins = true
email_addresses = ["dba@example.com"] # replace
retention_days = 30
disabled_alerts = [] # all alert types enabled
}
resource "azurerm_monitor_diagnostic_setting" "sql_db" {
name = "diag"
target_resource_id = azurerm_mssql_database.main.id
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
enabled_log {
category = "SQLInsights"
}
enabled_log {
category = "AutomaticTuning"
}
enabled_log {
category = "Errors"
}
metric {
category = "AllMetrics"
enabled = true
}
}terraform destroy ですべてが削除されます。注意点：
terraform destroy を介して無効にすると、月額約15ドル/サーバーの料金は停止します。DP-300は、このラボではカバーしきれないAzure上のSQLに関するより多くの内容を含んでいます。具体的には、Azure SQL Managed Instance（個別のプロビジョニング形状、月額課金）、Azure VM上のSQL Server（IaaS）、Azure Database for PostgreSQL Flexible Server、Azure Database for MySQL Flexible Server、MariaDB（非推奨）、エラスティックプール、geoレプリケーション/フェイルオーバーグループ、顧客管理キーによる透過的データ暗号化、Always Encrypted（列レベル）、動的データマスキング、行レベルセキュリティ、およびQuery Storeによるパフォーマンスチューニング全体が対象です。
私たちは単一の強化されたAzure SQL Databaseに焦点を当てています。これは、最も一般的なDP-300のシナリオであり、他のすべてのバリアント（MI、geoレプリケーション、フェイルオーバーグループ）が拡張する基盤だからです。Entra専用認証、監査、Defender、Log Analyticsを備えたサーバー+DBを一度にプロビジョニングできるようになれば、他のバリアントも異なるリソースタイプで同様の形状に従います。
サービスごとの詳細については、この認定資格ページの閲覧、プレイブック、およびEditorialセクションを参照してください。