最后审核时间:2026年5月
使用原生 Terraform 构建 AI-900 考试中的 AWS 服务——每次构建一个代码块,并紧扣考试领域。相同的代码可在 OpenTofu 上运行。
在本实验结束时,您将使用纯 Terraform 预置基础 Azure AI 表面 — 一个资源组、一个多服务 Azure AI 服务帐户(一个密钥,所有 AI API:计算机视觉、语言、语音、决策)、一个用于消耗输入的存储帐户,以及一个诊断设置,该设置将捕获每个 AI API 调用到 Log Analytics 以进行治理审查。
每个资源都是纯 Terraform。将这些代码片段放入一个 main.tf 文件中,运行 terraform init,然后逐步运行 terraform apply。
>= 1.5 或 OpenTofu >= 1.6。az login)。terraform apply 在 AI 帐户上因负责任 AI 错误而失败,请通过 Azure 门户接受条款并重新运行。大部分免费或非常便宜:
整个堆栈闲置时每月费用低于 1 美元。调用 AI API 会产生实际费用;完成后请销毁。
标准的 Azure 开场:固定 azurerm ~> 4.0,空的 features {} 块,以及一个用于全局唯一资源命名的 random_id(AI 服务帐户的 DNS 名称在整个 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 = 2
}
locals {
tags = {
Project = "certlabpro-ai-900"
ManagedBy = "terraform"
}
}
resource "azurerm_resource_group" "main" {
name = "certlabpro-ai-900-rg"
location = "eastus"
tags = local.tags
}几乎所有的 Azure AI 场景都从 Azure 存储中读取输入 — 计算机视觉的图像、语音的音频片段、语言的文本文件、自定义模型的训练数据。我们预先配置存储帐户,并采用安全默认值(仅限 HTTPS、TLS 1.2、禁用公共网络访问、无公共 Blob 访问)。
AI-900 Azure 机器学习基础 领域直接测试了将 Azure 存储作为数据基础的概念:当考试询问 AI 训练数据存储在哪里时,Azure 存储(或具体来说是 Azure Blob 存储)就是答案。
resource "azurerm_storage_account" "ai_data" {
name = "ai900data${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"
public_network_access_enabled = false
allow_nested_items_to_be_public = false
tags = local.tags
}Azure AI 服务(重新命名的认知服务总称)为您提供一个密钥、一个终结点,以及对所有 AI API 的访问权限 — 计算机视觉、语言、语音、翻译、文档智能、内容安全等等。单一多服务帐户是 AI-900 成本反模式问题:它比专用的单一服务帐户(语音、视觉、语言各自有其免费 F0 层级)的每次调用费用 更高,但管理起来要简单得多。AI-900 两种形式都会测试 — 考试会问您何时选择哪种形式。
我们为多服务帐户设置 kind = "CognitiveServices",为标准层设置 sku_name = "S0"。 custom_subdomain_name 是 VNet 集成所必需的(AI-900 负责任 AI 领域将其作为私有终结点的先决条件进行测试)。 local_auth_enabled = true 保持 API 密钥流程工作;false 将强制仅使用 Entra ID 身份验证。
resource "azurerm_cognitive_account" "ai" {
name = "certlabpro-ai-900-${random_id.suffix.hex}"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
kind = "CognitiveServices"
sku_name = "S0"
custom_subdomain_name = "certlabpro-ai-900-${random_id.suffix.hex}"
local_auth_enabled = true
identity {
type = "SystemAssigned"
}
tags = local.tags
}负责任 AI 是 AI-900 的一个支柱(五个考试领域之一)—— 您可以通过基础设施展示的最具体的 负责任 AI 实践是 审计日志记录。我们创建一个 Log Analytics 工作区作为诊断日志的目标;在第 5 步中,我们将 AI 帐户的诊断设置配置为将所有内容发送到此处。
Log Analytics 是 Azure 的中央可观察性服务 — Azure Monitor 将指标发送到此处,Application Insights 将应用遥测数据发送到此处,Sentinel 从此处读取以用于 SIEM。将其作为 AI 实验的审计目标,同时也成为其他所有 Azure 认证都假定您会使用的构建块。
resource "azurerm_log_analytics_workspace" "main" {
name = "certlabpro-ai-900-logs"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
sku = "PerGB2018"
retention_in_days = 30
tags = local.tags
}诊断设置是 Azure 的通用可观察性原语:每个 Azure 资源都可以将其分类日志和指标流式传输到 Log Analytics 工作区、事件中心或存储帐户。我们开启 AI 帐户的审计 (Audit) 和请求响应 (RequestResponse) 日志类别 — 审计捕获 调用了什么,请求响应捕获实际的请求和响应正文(对于事件响应很有用,如果提示中包含 PII 则很可怕;AI-900 负责任 AI 会测试这种权衡的两方面)。
随着这最后一部分的到位,每个 AI API 调用都将进入第 4 步中的工作区,并通过 KQL 进行查询。这就是 AI-900 完善负责任 AI 的方式:不仅仅是“我们有一个内容过滤器”,而是“我们拥有 AI 看到的每个请求的证据”。
resource "azurerm_monitor_diagnostic_setting" "ai" {
name = "certlabpro-ai-900-diag"
target_resource_id = azurerm_cognitive_account.ai.id
log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
enabled_log {
category = "Audit"
}
enabled_log {
category = "RequestResponse"
}
metric {
category = "AllMetrics"
enabled = true
}
}标准的 terraform destroy 将销毁本实验室中的所有内容。两点注意事项:
random_id 后缀通常可以避免这种情况。AI-900 涵盖了本实验室无法包含的 Azure AI 表面 — Azure OpenAI 服务(AI-102 中涵盖)、Azure 机器学习工作室 + 工作区 (DP-100)、Bot Service、计算机视觉自定义模型、自定义视觉门户训练、语言工作室的自定义问答和对话式语言理解、文档智能自定义模型、Azure AI 搜索、语音自定义语音/发音评估以及用于 ML 可解释性的负责任 AI 仪表板。
我们坚持使用 多服务帐户 + 存储 + 审计日志记录 的基本原语,因为它们是所有更高级的 Azure AI 模式所依赖的基础。一旦您了解多服务帐户如何在一个密钥下公开完整的 API 套件,按服务的深入研究就更容易理解了。
有关按服务的概念性覆盖,请参阅本认证页面的 浏览 和 Editorial 部分。