AZ-204备考指南：虚拟机重部署、Key Vault与kubectl部署实战解析

简介：《AZ-204 2022最新题库》是一份面向微软Azure开发人员认证考生的练习资料，聚焦Azure虚拟机迁移、ARM模板安全存储密码、AKS部署等核心考点，适合正在备考AZ-204并希望熟悉真实题型与答题思路的开发者使用。资源采用PDF格式，共1个文件，整体大小约221KB，内容精炼，便于在电脑或移动设备上随时阅读和刷题。目前已有339人学习下载，具备一定参考价值。题库中不仅给出标准答案，还附有社区投票分布和解析说明，例如Azure虚拟机重新部署到新节点的正确操作、利用Key Vault和访问策略避免明文密码等关键知识点。考生可以通过这些典型题例，快速理解Azure资源管理、安全性与监控等高频主题的命题方式，检验自身掌握程度，并有针对性地查漏补缺，提升考试通过概率。

1. 考 AZ-204 前先看清：这版题库里藏着哪些必练动作

同一道题，社区投票结果五五开，A 选项 60%、B 选项 40%，两边都贴出了官方文档截图——这是我在 AZ-204 Microsoft Certificate 备考圈里最常见的场面。AZ-204 是面向 Azure 开发者的认证考试，题库表面是几百道选择题，骨子里考的是三件事：资源部署的命令边界、敏感信息的存放方式、容器化应用的操作入口。它适合那些已经写过 ARM 模板、碰过 VM 和 AKS、但还没形成体系判断的人。这篇笔记就用几道典型题的技术主线，把虚拟机重部署、Key Vault 接入、kubectl 部署这套动作从头过一遍，中间的“玄学”点会单独拆开讲清楚。

2. 虚拟机迁移与模板部署：重部署的边界和参数化路径

2.1 为什么 VM 出故障先考虑 Redeploy，而不是迁移订阅

题目给的场景很典型：一台虚拟机部署在物理节点 A 上，现在需要把它挪到另一个物理节点。乍看像“迁移”，但正确答案是“重新部署”。Redeploy 的本质是：Azure 先把虚拟机从当前底层节点上关闭并释放调度位置，再在一个新节点上重新开机，过程中保留原虚拟机的配置选项和关联资源（网卡、磁盘、网络安全组都不动）。它解决的是底层硬件异常、宿主机不稳定这类问题，而不是跨区域搬迁。

很多考生把“Redeploy”和“迁移订阅”混在一起，原因是没有分清两个动作的影响面。迁移订阅（Move to different subscription）改的是资源归属，资源 ID、RBAC 授权、配额计数都会跟着变；Redeploy 改的是运行位置，资源 ID 和所有权不变。考试里只要看到“底层节点故障”“硬件问题”“需要把 VM 换一台物理机”这类描述，优先考虑 Redeploy，而不是去动订阅或出口位置。以下操作路径可以作为候选实验：

# 重新部署指定虚拟机，触发底层节点切换 az vm redeploy --resource-group rg-exam-demo --name vm-exam-demo --no-wait

参数说明：--resource-group指向 VM 所在资源组，--name是虚拟机名；--no-wait表示命令立即返回，不在终端阻塞等待部署结果。不加--no-wait时，CLI 会一直轮询到操作完成，适合在管道脚本里需要同步确认的场景。执行之后用az vm show -g rg-exam-demo -n vm-exam-demo -d可以查看实例视图，确认虚拟机确实换到了新节点上。

Portal 路径同理：打开 VM 的 Overview 面板，在“Help”区域找到 Redeploy 按钮，点击后确认即可。这个操作会造成几分钟的中断，不要在业务高峰期无通知执行。要提醒一点：Redeploy 保留的是“配置和关联资源”，不等于保留动态公共 IP 地址，这个坑在第 5 章单独讲。

2.2 ARM 模板：从一台 VM 扩展到一批 VM 的最小结构

ARM 模板是声明式部署的核心载体。所谓声明式，就是你只描述“最终要有什么”，不描述“怎么一步步创建”。题库里频繁出现“基于当前 VM 导出模板”“下载模板后批量部署多台 VM”这类题目，考的就是模板的骨架结构。一个最小可运行的 VM 模板通常包含四块：参数定义（parameters）、资源声明（resources）、变量区（variables）、输出区（outputs）。其中参数区最值得关注，因为它直接关系到密码等敏感信息是否安全。

下面是一个裁剪后的 VM 部署模板，去掉了与主题无关的网络和存储细节，只保留能跑通的最小结构：

{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "adminUsername": { "type": "string" }, "adminPassword": { "type": "securestring" } }, "resources": [ { "type": "Microsoft.Compute/virtualMachines", "apiVersion": "2023-03-01", "name": "vm-exam-demo", "location": "[resourceGroup().location]", "properties": { "osProfile": { "computerName": "vm-exam-demo", "adminUsername": "[parameters('adminUsername')]", "adminPassword": "[parameters('adminPassword')]" }, "hardwareProfile": { "vmSize": "Standard_B2s" }, "storageProfile": { "imageReference": { "publisher": "Canonical", "offer": "ubuntu-24_04-lts", "sku": "server", "version": "latest" } }, "networkProfile": { "networkInterfaces": [ { "id": "[resourceId('Microsoft.Network/networkInterfaces', 'nic-exam-demo')]" } ] } } } ] }

代码逻辑说明：parameters里把管理员密码声明为securestring，这个类型在部署日志和部署历史里会被掩码，不会像普通string那样直接展示明文。resources里声明的是虚拟机本体，osProfile负责把参数值注入到系统的管理员账号配置中。networkProfile引用的网卡假设已经提前创建好，真实部署时还需要把虚拟网络、公共 IP、NIC 一并写进模板，这里略去了与主题无关的字段。

参数说明：vmSize选Standard_B2s是为了节省验证成本，生产环境按负载调整；imageReference里的publisher和offer决定了操作系统类型，换成 Windows Server 时需要同时改osProfile里的windowsConfiguration。模板的apiVersion建议跟随当前主流版本，过旧的版本可能在新建资源组时不被接受。

2.3 可复现部署：用 CLI 跑通模板与参数文件

模板写好之后，下一步就是把参数和模板分开，用参数文件喂给部署命令。这一步题库不会直接考命令行拼写，但理解参数文件的作用，对答“模板如何引用密码”“如何适应多 VM 部署”这类题非常重要。参数文件是一个普通 JSON，里面只放参数值，不涉及模板逻辑：

{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "adminUsername": { "value": "azureuser" }, "adminPassword": { "value": "此处不建议直接写明文" } } }

执行部署的命令如下：

az deployment group create \ --resource-group rg-exam-demo \ --template-file vm.json \ --parameters vm.parameters.json

参数说明：--template-file指向模板文件本地路径，--parameters参数可以接 JSON 文件路径，也可以直接写成adminUsername=azureuser adminPassword=xxx这种行内键值对。文件方式的优势是便于在 CI/CD 管道里复用，行内方式适合临时验证。部署完成后用az deployment group show -g rg-exam-demo -n <deployment-name> --query properties.outputs查看输出结果，确认参数注入成功。

这里要特别注意：参数文件用value字段传明文，如果这个文件被提交进 Git，密码就等于裸奔了。题库里第二道典型题问“如何在模板里引用密码而不存明文”，答案就是 Key Vault，对应第 3 章的完整流程。

3. Key Vault 接入：把管理员密码从明文模板里请出去

3.1 明文密码在模板里一定会翻车

把密码直接写进模板或参数文件，是 ARM 部署最常见的翻车点。表面上securestring能在部署日志里隐藏值，但参数文件本身是明文存在的，一旦仓库权限配置不当、或者代码库被导出，密码就彻底暴露。更隐蔽的问题是：ARM 模板的部署历史会记录参数值，即使后来删除了明文参数，旧版本仍可能被有权限的人捞出来。这也是考试反复强调“不要让密码以明文存储”的根本原因。

正确的解题方向是引入 Azure Key Vault，把密码封装成密钥（Secret），模板里只写一个引用关系，由部署引擎在运行时从 Key Vault 拉取值。题目问“需要创建哪些组件”时，标准答案是两个东西：一个 Key Vault 实例，外加一个访问策略（Access Policy）。Key Vault 负责存储，访问策略负责授权——这两个缺一不可，只建库不授权，部署主体拉取不到密钥；只授权不建库，密码没有可落地的存放位置。

3.2 建库、授权、放密码的三步操作

在真实环境里，完整流程分三步走。第一步创建 Key Vault 实例，第二步给部署主体授予读取密钥的权限，第三步把管理员密码作为 Secret 放进库里。下面是一组可复现的 CLI 命令：

# 1. 创建 Key Vault 实例（名称全局唯一） az keyvault create \ --name kv-exam-demo-001 \ --resource-group rg-exam-demo \ --location eastasia # 2. 给当前用户/服务主体授予读取密钥的权限 az keyvault set-policy \ --name kv-exam-demo-001 \ --object-id <principal-object-id> \ --secret-permissions get list # 3. 把管理员密码存入 Secret az keyvault secret set \ --vault-name kv-exam-demo-001 \ --name vm-admin-password \ --value "YourStrongPassword123!"

命令逻辑说明：第一步创建的 Vault 是密钥容器；第二步的object-id是部署主体的对象 ID，可以是当前登录用户、服务主体，也可以是托管身份。第三步的--value是你要保护的密码原文，写入后立即以加密形式存储在 Vault 中，不再出现在参数文件里。secret-permissions里get和list是最低限度的读取权限，不要授delete或set给只用不写的部署主体。

参数说明：Key Vault 名称要求全局唯一，kv-exam-demo-001只是示例，实际使用时可以加上公司缩写和序号。--location建议和 VM 资源组放在同一个区域，避免跨区域读取密钥带来的延迟和额外成本。访问策略的授权对象很关键：如果部署是通过管道里的服务主体执行的，就必须把服务主体的object-id填进去，而不是填你自己。这也是很多部署报“无法访问密钥”的原因——“我明明能访问，为什么管道不行”，实际上管道的身份和你不是同一个。

3.3 模板引用 Key Vault 的正确姿势

库建好了、权限也给了，接下来是模板侧怎么引用。ARM 模板里不需要放密码原文，只要在参数定义里声明一个引用关系，部署引擎会在部署开始时自动从 Key Vault 拉取 Secret 并转换成参数值。下面这段代码展示如何在参数文件中引用 Key Vault：

{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "adminUsername": { "value": "azureuser" }, "adminPassword": { "reference": { "keyVault": { "id": "/subscriptions/<subscription-id>/resourceGroups/rg-exam-demo/providers/Microsoft.KeyVault/vaults/kv-exam-demo-001" }, "secretName": "vm-admin-password" } } } }

代码逻辑说明：adminPassword不再写value字段，而是写reference对象。keyVault.id指向 Vault 的资源 ID，secretName指定 Secret 名称。部署引擎读取这个参数文件时，会调用 Key Vault 的读取接口，把 Secret 内容取出来注入模板，整个过程不会在参数文件或部署日志里留下明文密码。如果 Secret 设置了版本，可以在reference里加secretVersion字段锁定版本；不写版本时默认取最新版。

参数说明：这个方案的边界条件是“部署主体必须对 Key Vault 有 get/list 权限”，也就是 3.2 里访问策略要配好的原因。如果使用 RBAC 权限模型（较新的 Vault 版本默认支持）而不是旧版 Access Policy，需要确认主体有“Key Vault Secrets User”角色，而不是get/list权限本身。两种模型在同一 Vault 上不能混用，创建 Vault 时选定了权限模型，后续授权就要保持一致。

这里有个值得记住的判断技巧：考试里只要出现“密码不以明文存储”“模板引用机密”“使用 Key Vault”等关键词，你的思考路径永远是“Vault 存值 + 访问策略/角色授权 + 参数引用”三件套，缺一个都是干扰项。

4. AKS 上的 YAML 部署：kubectl 才是入口，docker run 不是

4.1 kubectl apply 解决的是什么问题

AKS 集群的部署方式经常被考生误解，尤其是“kubectl 和 docker 到底谁管谁”这个问题。先明确结论：向 AKS 集群部署 YAML 清单，标准工具是 kubectl，而不是 docker 命令。kubectl apply -f myapp.yaml 做的事情是：读取本地的 YAML 文件，把其中声明的资源状态（Deployment、Service、ConfigMap 等）发送给 Kubernetes API Server，由集群控制面完成实际调度和容器创建。它是一个“声明式更新”动作——你声明目标状态，kubectl 负责让集群向这个状态收敛。

为什么要用 apply 而不是 create？create 只能创建新对象，如果对象已存在会直接报错；apply 会对比当前状态和目标状态的差异，做增量更新。在 CI/CD 流水线里反复执行同一个部署文件，apply 是幂等的，不会因为重复执行而出错。这也是考试里强调“manifest 文件已存在、需要部署应用”时，正确选项多为 apply 的原因。

# 让 kubectl 对比本地清单与集群现状，并完成增量更新 kubectl apply -f myapp.yaml

命令逻辑说明：-f指定清单文件路径，支持单文件或目录。执行成功后，kubectl 会返回每个资源的创建/更新结果，比如deployment.apps/myapp created。随后可以用kubectl get pods -w观察 Pod 是否进入 Running 状态，用kubectl rollout status deployment/myapp确认副本集滚动完成。这里的-w是 watch 的意思，会持续监听资源变化直到退出。

4.2 docker run 为什么是标准干扰项

题库里这类题的把戏在于：题干描述的是“把 YAML 清单部署到 AKS”，但给出的命令却是docker run -it <azure-cli镜像>。很多考生看到“azure-cli”就以为和 Azure 相关、能部署，实际上 docker run 只是把这个镜像拉下来并启动一个交互式容器，它既不读取你的 myapp.yaml，也不会和 K8s API Server 建立任何连接。即使这个容器内部带了 kubectl，你仍然需要在容器里手动执行 kubectl 才能访问集群，而且还得先配置好 kubeconfig。一句话概括：docker run 启动的是一个隔离环境，不是部署动作。

这也暴露了一个常见思维误区：把 AKS 当成“远程 Docker”。AKS 的管理面是 Kubernetes，不是 Docker Engine；Docker CLI 在本地构建镜像、跑容器没问题，但操作集群对象必须走 kubectl。考试里看到“安装 docker client 然后 run 镜像”这类选项，不用犹豫，直接排除。另一个相关点是：新版的 AZ-204 考试大纲里 AKS 已不是必考内容，但题库仍保留这类题，练习时不要花太多精力在 docker 命令本身，重点放在 kubectl 的边界上。

4.3 最小可复现动作：从装 kubectl 到 rollout 完成

真实环境里部署应用到 AKS，最少需要四步：装 kubectl、接集群凭据、写 YAML、apply。下面是一套完整的操作序列：

# 1. 安装 kubectl（Azure CLI 不自带，需要单独装） az aks install-cli # 2. 获取 AKS 集群访问凭据 az aks get-credentials \ --resource-group rg-exam-demo \ --name aks-exam-demo \ --overwrite-existing # 3. 查看当前上下文，确认接入的是目标集群 kubectl config get-contexts # 4. 部署 YAML 清单 kubectl apply -f myapp.yaml # 5. 确认部署完成 kubectl rollout status deployment/myapp

命令参数说明：az aks install-cli会自动下载与当前平台匹配的 kubectl 二进制；az aks get-credentials中的--overwrite-existing表示强制覆盖本地已有的 kubeconfig 配置，避免多个集群切换后上下文残留。kubectl config get-contexts查看当前指向的集群名，星号标记的是当前上下文，如果发现指向旧集群，需要先切回：kubectl config use-context <cluster-name>。rollout status会监听 Deployment 的滚动更新过程，直到所有副本更新完成或在超时时间内失败。

myapp.yaml 的一个极简示例：

apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 2 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: nginx:1.25 ports: - containerPort: 80

这个清单声明的目标状态是：两个副本的 Deployment，镜像为 nginx:1.25。实际开发时把 image 替换成自己构建的镜像地址，并加上容器资源限额和健康检查。注意selector.matchLabels必须与template.metadata.labels保持一致，否则 apply 时 API Server 会拒绝创建。这就是一个完整的部署链路，也是把“kubectl apply”从背书变成动手的关键实验。

5. 避坑：同一道题社区投票五五开时怎么判

5.1 判题的唯一准绳：排除干扰字符并本地实测

题库里有不少题存在“社区投票分裂”的怪象，两边都贴文档、都言之凿凿，投票结果接近五五开。我见过最典型的案例，是一道考 kubectl 部署的题：题干里写的命令是kubectl apply"f myapp.yaml，中间混入了排版转义字符，看起来像是一个非法命令。一部分考生按原样执行，命令直接报错，于是坚定地选了“不能达成目标”；另一部分考生意识到那是乱码，还原成kubectl apply -f myapp.yaml`，选了“可以达成目标”。投票就分裂了。

应对这类“争议题”，我的习惯是三步走。第一步，先还原题干里的命令，删除明显不合理的转义字符和乱码，得到最可能的技术原意；第二步，把还原后的命令放到本地终端实际跑一遍，看它到底能做什么；第三步，对照官方文档对命令的定义，确认它是否满足题面诉求。没必要在“投票谁多谁少”上较真，因为社区投票反映的是读题偏差，不是技术边界。

从这类现象可以沉淀出一个通用判断：考试题干里出现命令时，字符级错误（多余引号、反引号、乱码）大概率是平台显示问题，而不是出题本意。判题时以语义为准，不要被排版带偏。如果命令经过还原后仍然不是完成题面任务的正规方式，那就选 No。

5.2 五个高频踩坑记录

坑 1：Redeploy 后动态公共 IP 变了

现象：对一台带有公共 IP 的 VM 执行 Redeploy，操作完成后业务访问中断，发现 IP 地址和操作前不一样。

原因：Redeploy 会触发底层节点切换，如果公共 IP 是动态分配的（Basic SKU 默认动态），节点切换后无法保证原地址不变；官方说明里说保留“配置和关联资源”，并没有把动态地址写进保障范围。

解决：生产环境的 VM 公共 IP 改用静态分配（Standard SKU），或者把关键访问放到负载均衡器后面，由负载均衡统一分发。顺带说一句，这也是为什么“Redeploy 保留所有配置”不等于“IP 一定不变”，遇到这类延伸题要能迅速反应。

坑 2：把真实密码写在参数文件默认值里

现象：模板文件在 Git 仓库里存放一段时间后，被扫描工具或安全审计发现暴露了管理员密码。

原因：很多人在 parameters 的defaultValue字段直接填了真实密码，文件被推到仓库后就沉淀进历史记录，删除当前文件并不能清除历史版本。

解决：模板和参数文件都不写默认密码；密码一律放 Key Vault，参数文件里只写 reference。这个坑在考试里可能以“最安全的做法是什么”的形式出现，正确选项绝不是“把密码放到参数默认值”，而是“使用 Key Vault 存储 Secret 并引用”。

坑 3：管道里直接 kubectl apply 报 command not found

现象：Azure Pipeline 或本地脚本执行到kubectl apply -f myapp.yaml时报错，提示 kubectl 不存在。

原因：机器上只装了 Azure CLI，没有安装 kubectl。Azure CLI 本身不具备这个命令，需要单独通过az aks install-cli安装。很多考生以为装了 az 就等于装了一切，这就是把 CLI 生态当成黑匣子的代价。

解决：在管道脚本开头先执行az aks install-cli，确认kubectl version --client能正常输出版本号后再执行 apply。如果使用托管代理，也可以预先在镜像里内置 kubectl。

坑 4：kubeconfig 指向旧集群导致应用部署错环境

现象：执行 kubectl apply 成功返回 created，但打开另一个集群的控制台发现 Pod 出现在旧集群里，或者本地出现 “connection refused” 连接错误。

原因：az aks get-credentials没有加--overwrite-existing，本地的 kubeconfig 里保留了多个集群上下文，当前上下文仍指向旧集群。

解决：获取凭据时加--overwrite-existing，执行前用kubectl config current-context确认目标。切换环境后养成检查上下文的习惯，能避免大量环境错乱问题。

坑 5：模板 apiVersion 过旧导致部署失败

现象：用一份老模板部署时，报 “The apiVersion '...' is invalid” 或 “unsupported apiVersion”。

原因：ARM 模板的apiVersion是每个资源类型各自的版本，老版本被淘汰后在新建资源组里不再被接受；Kubernetes 清单的apiVersion同理，版本落后过多会被 API Server 拒绝。

解决：部署模板前先查当前支持的版本，ARM 资源可以打开 Azure 资源浏览器确认，K8s 清单用kubectl api-versions查看集群支持的版本。写新模板时直接采用当前主流版本，不要沿用旧项目里的旧模板复制粘贴。

6. 把错题变成验证链路：五条可复现的实验路径

6.1 五条实验链路：错题到验证命令的映射

备考的最后一公里，不是把正确率刷到百分之百，而是让每道错题都能落成一条可以重复执行的命令链路。下面这张表是我把常见错题映射成实验动作的方法，每条链路都对应一门技术主题：

每条链路都能在十几分钟内完成，验证的不只是答案，而是你对命令边界的理解。

6.2 一条命令串起整条验证链路

把几项技术串成一条流水线，是我在备考时用过的最有效的收尾动作。下面这套脚本会依次完成：建资源组、部署带 Key Vault 引用的 VM、触发 Redeploy、创建 AKS 集群、接入凭据、部署 YAML。整体耗时约二十分钟，结束时把资源组删掉即可。

rg=rg-exam-$(date +%Y%m%d%H%M) az group create --name $rg --location eastasia # VM 部署（模板引用 Key Vault Secret） az deployment group create \ --resource-group $rg \ --template-file vm.json \ --parameters vm.parameters.json # 触发 VM 重部署，模拟底层节点切换 az vm redeploy --resource-group $rg --name vm-exam-demo # 创建 AKS 集群（开发环境最小规格） az aks create \ --resource-group $rg \ --name aks-exam-demo \ --node-count 1 \ --generate-ssh-keys # 接入集群并部署清单 az aks get-credentials --resource-group $rg --name aks-exam-demo --overwrite-existing kubectl apply -f myapp.yaml kubectl rollout status deployment/myapp # 清理：删除整个资源组，避免持续计费 az group delete --name $rg --yes --no-wait

脚本逻辑说明：资源组名用时间戳保证唯一，避免和历史资源冲突；VM 部署依赖模板和参数文件，验证 Key Vault 的引用是否生效；Redeploy 验证重部署后 VM 是否恢复；AKS 创建用--node-count 1降低开销并缩短创建时间；最后的az group delete --yes --no-wait是事后清理，防止实验资源产生持续费用。整套链路跑通后，你对 AZ-204 里的资源部署、安全存储、容器操作这三条主线就有了可迁移的实操经验。

从那以后，我每刷一道题都会先把它拆成一个“如果让我在控制台上做，我会敲什么命令”的问题，再在测试资源组里真实跑一遍；题库里的正确率反而没那么重要了。考场上遇到没见过的题目，边界感会帮你推导出最合理的选项。希望帮到你。

本文还有配套的精品资源，点击获取