最后审核时间：2026年5月
使用原生 Terraform 构建 DP-900 考试中的 AWS 服务——每次构建一个代码块，并紧扣考试领域。相同的代码可在 OpenTofu 上运行。
在本实验结束时，您将使用纯 Terraform 预置 DP-900 考试所考察的三种数据平台形态——一个用于 Blob/分析数据并带有生命周期策略的 Azure 存储账户、一个基于基本层服务器的关系型 Azure SQL 数据库，以及一个用于非关系型 JSON 的无服务器 Cosmos DB 账户。一个堆栈，三种底层存储，每一种都与 DP-900 领域相关。
所有资源都是纯 Terraform 代码。将这些代码片段放入一个 main.tf 文件中，运行 terraform init，然后逐步运行 terraform apply。
>= 1.5 或 OpenTofu >= 1.6。az login)。混合型费用——两个便宜，一个有实际账单：
整个堆栈运行期间约 $5–8/月。完成后请及时销毁——SQL 数据库是唯一无论您是否使用都会 24/7 计费的项目。
标准的 Azure 开场白整合到一个代码块中：固定 azurerm ~> 4.0，注册 random 和 random_password 提供程序（我们将同时使用两者——random_id 用于唯一的资源命名，random_password 用于 SQL 管理员密码），并创建资源组。
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-dp-900"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-dp-900-rg"
location = "eastus"
tags = local.tags
}Azure 存储是 DP-900 所有问题所假定的分析数据底层存储（热/冷/存档分层，以及自动转换冷数据的生命周期策略）。我们开启分层命名空间 (is_hns_enabled = true)，这将把账户转换为 Azure Data Lake Storage Gen2——这是 Azure Synapse、Databricks 和 Fabric 所有分析工作负载所期望的版本。
生命周期策略是 DP-900 考试中最常考的成本优化机制：活跃数据使用热层，30 天后转为冷层，90 天后转为存档层。三层，三个保留窗口——考试会在场景中提及这些数字。
resource "azurerm_storage_account" "analytics" {
name = "dp900data${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"
is_hns_enabled = true # Data Lake Storage Gen2
https_traffic_only_enabled = true
min_tls_version = "TLS1_2"
allow_nested_items_to_be_public = false
tags = local.tags
}
resource "azurerm_storage_management_policy" "analytics" {
storage_account_id = azurerm_storage_account.analytics.id
rule {
name = "tier-cold-data"
enabled = true
filters {
blob_types = ["blockBlob"]
prefix_match = ["raw/"]
}
actions {
base_blob {
tier_to_cool_after_days_since_modification_greater_than = 30
tier_to_archive_after_days_since_modification_greater_than = 90
}
}
}
}Azure 上的关系型数据意味着 Azure SQL Database (PaaS，完全托管)。DP-900 考试区分了 SQL Database（单一数据库，无服务器或基于 DTU，PaaS）与 SQL Managed Instance（近 100% SQL Server 兼容性，大型实例 PaaS）与 SQL Server on VM（IaaS，完全控制）之间的区别。
我们预置一个 SQL Server 逻辑容器（连接字符串端点），并在其下创建一个基本层的数据库——这是最便宜的付费 SKU。强制执行传输中始终加密 (TLS 1.2)。防火墙规则允许 Azure 服务连接（典型的 DP-900 问题“我的 App Service 如何与我的 SQL 对话？”——此规则就是答案）。
resource "random_password" "sql_admin" {
length = 24
special = true
min_upper = 2
min_lower = 2
min_numeric = 2
}
resource "azurerm_mssql_server" "main" {
name = "certlabpro-dp-900-${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
version = "12.0"
administrator_login = "sqladmin"
administrator_login_password = random_password.sql_admin.result
minimum_tls_version = "1.2"
public_network_access_enabled = true
tags = local.tags
}
resource "azurerm_mssql_database" "main" {
name = "certlabpro-dp-900-db"
server_id = azurerm_mssql_server.main.id
sku_name = "Basic"
max_size_gb = 2
zone_redundant = false
tags = local.tags
}
resource "azurerm_mssql_firewall_rule" "allow_azure_services" {
name = "AllowAzureServices"
server_id = azurerm_mssql_server.main.id
start_ip_address = "0.0.0.0"
end_ip_address = "0.0.0.0" # 0.0.0.0/0.0.0.0 = "allow Azure services" sentinel
}Azure 上的非关系型数据意味着 Azure Cosmos DB，一个全球分布式多 API 数据库。DP-900 专门考察 API 的区别——NoSQL（核心/SQL API，最常见）、MongoDB、Cassandra、Gremlin 和 Table。我们使用核心 SQL API + 无服务器容量模式（按请求付费，无闲置计费——DP-900 考试中关于无服务器与预置成本反模式的问题）。
consistency_level = "Session" 是 Cosmos DB 的默认值，也是 DP-900 考试中最常考的一致性级别：每个会话的线性一致性，具有出色的延迟。其他四种——强一致性 (Strong)、有限过期 (Bounded staleness)、最终一致性 (Eventual)、一致前缀 (Consistent prefix)——是概念性考试主题。
随着这三种数据底层存储到位（步骤 2 中的 Blob，步骤 3 中的 SQL，步骤 4 中的 Cosmos），DP-900 的《核心数据概念》领域便有了实际的形态：“哪种 Azure 服务适用于哪种数据形态”这个问题，就由这三种资源来回答。
resource "azurerm_cosmosdb_account" "main" {
name = "certlabpro-dp-900-${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
offer_type = "Standard"
kind = "GlobalDocumentDB" # Core (SQL) API
capabilities {
name = "EnableServerless"
}
consistency_policy {
consistency_level = "Session"
}
geo_location {
location = azurerm_resource_group.main.location
failover_priority = 0
}
tags = local.tags
}标准的 terraform destroy 会销毁本实验中的所有内容。两点注意事项：
random_password 生成的——它存储在 Terraform 状态中。如果您将状态提交到 Git，则也提交了密码。在任何非简单设置中，请使用远程状态后端（带有版本控制 + 软删除的 Azure 存储）。DP-900 涵盖了许多本实验无法容纳的数据服务——Azure Synapse Analytics（DP-600/DP-700 中涵盖）、Azure Databricks、Azure Data Factory、Microsoft Fabric、Azure Stream Analytics、Event Hubs、Azure SQL Managed Instance、适用于 PostgreSQL / MySQL / MariaDB 的 Azure 数据库、Power BI，以及那些在闲置时费用昂贵的 Azure 分析服务（Synapse 专用 SQL 池、专用 Spark 池）。
我们坚持三种核心数据形态（Blob/分析型、关系型、非关系型），因为 DP-900 本质上是一个“哪种服务适用于哪种形态”的考试。一旦您内化了本实验预置的三种底层存储，其他所有 DP-900 问题都将成为在此基础上的分层问题。
有关逐个服务的覆盖范围，请参阅此认证页面的浏览、手册和 Editorial 部分。