简介《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 文件路径也可以直接写成adminUsernameazureuser adminPasswordxxx这种行内键值对。文件方式的优势是便于在 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 的资源 IDsecretName指定 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 而不是 createcreate 只能创建新对象如果对象已存在会直接报错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 EngineDocker CLI 在本地构建镜像、跑容器没问题但操作集群对象必须走 kubectl。考试里看到“安装 docker client 然后 run 镜像”这类选项不用犹豫直接排除。另一个相关点是新版的 AZ-204 考试大纲里 AKS 已不是必考内容但题库仍保留这类题练习时不要花太多精力在 docker 命令本身重点放在 kubectl 的边界上。4.3 最小可复现动作从装 kubectl 到 rollout 完成真实环境里部署应用到 AKS最少需要四步装 kubectl、接集群凭据、写 YAML、apply。下面是一套完整的操作序列# 1. 安装 kubectlAzure 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 applyf myapp.yaml中间混入了排版转义字符看起来像是一个非法命令。一部分考生按原样执行命令直接报错于是坚定地选了“不能达成目标”另一部分考生意识到那是乱码还原成kubectl apply -f myapp.yaml选了“可以达成目标”。投票就分裂了。应对这类“争议题”我的习惯是三步走。第一步先还原题干里的命令删除明显不合理的转义字符和乱码得到最可能的技术原意第二步把还原后的命令放到本地终端实际跑一遍看它到底能做什么第三步对照官方文档对命令的定义确认它是否满足题面诉求。没必要在“投票谁多谁少”上较真因为社区投票反映的是读题偏差不是技术边界。从这类现象可以沉淀出一个通用判断考试题干里出现命令时字符级错误多余引号、反引号、乱码大概率是平台显示问题而不是出题本意。判题时以语义为准不要被排版带偏。如果命令经过还原后仍然不是完成题面任务的正规方式那就选 No。5.2 五个高频踩坑记录坑 1Redeploy 后动态公共 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。坑 4kubeconfig 指向旧集群导致应用部署错环境现象执行 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 五条实验链路错题到验证命令的映射备考的最后一公里不是把正确率刷到百分之百而是让每道错题都能落成一条可以重复执行的命令链路。下面这张表是我把常见错题映射成实验动作的方法每条链路都对应一门技术主题错题主题复现动作预期结果VM 故障迁移对测试 VM 执行 RedeployVM 状态回到 Running配置保留模板参数密码用 Key Vault 引用密码部署 VM部署成功且日志不出现明文密码AKS 部署 YAML安装 kubectl 并 apply 清单Deployment/ReplicaSet 正常创建权限访问异常移除访问策略再部署报错提示无法访问密钥kubectl 环境错乱切换上下文部署资源出现在目标集群每条链路都能在十几分钟内完成验证的不只是答案而是你对命令边界的理解。6.2 一条命令串起整条验证链路把几项技术串成一条流水线是我在备考时用过的最有效的收尾动作。下面这套脚本会依次完成建资源组、部署带 Key Vault 引用的 VM、触发 Redeploy、创建 AKS 集群、接入凭据、部署 YAML。整体耗时约二十分钟结束时把资源组删掉即可。rgrg-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 里的资源部署、安全存储、容器操作这三条主线就有了可迁移的实操经验。从那以后我每刷一道题都会先把它拆成一个“如果让我在控制台上做我会敲什么命令”的问题再在测试资源组里真实跑一遍题库里的正确率反而没那么重要了。考场上遇到没见过的题目边界感会帮你推导出最合理的选项。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/17 0:17:36 · 阅读 1.2k 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 文件路径也可以直接写成adminUsernameazureuser adminPasswordxxx这种行内键值对。文件方式的优势是便于在 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 的资源 IDsecretName指定 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 而不是 createcreate 只能创建新对象如果对象已存在会直接报错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 EngineDocker CLI 在本地构建镜像、跑容器没问题但操作集群对象必须走 kubectl。考试里看到“安装 docker client 然后 run 镜像”这类选项不用犹豫直接排除。另一个相关点是新版的 AZ-204 考试大纲里 AKS 已不是必考内容但题库仍保留这类题练习时不要花太多精力在 docker 命令本身重点放在 kubectl 的边界上。4.3 最小可复现动作从装 kubectl 到 rollout 完成真实环境里部署应用到 AKS最少需要四步装 kubectl、接集群凭据、写 YAML、apply。下面是一套完整的操作序列# 1. 安装 kubectlAzure 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 applyf myapp.yaml中间混入了排版转义字符看起来像是一个非法命令。一部分考生按原样执行命令直接报错于是坚定地选了“不能达成目标”另一部分考生意识到那是乱码还原成kubectl apply -f myapp.yaml选了“可以达成目标”。投票就分裂了。应对这类“争议题”我的习惯是三步走。第一步先还原题干里的命令删除明显不合理的转义字符和乱码得到最可能的技术原意第二步把还原后的命令放到本地终端实际跑一遍看它到底能做什么第三步对照官方文档对命令的定义确认它是否满足题面诉求。没必要在“投票谁多谁少”上较真因为社区投票反映的是读题偏差不是技术边界。从这类现象可以沉淀出一个通用判断考试题干里出现命令时字符级错误多余引号、反引号、乱码大概率是平台显示问题而不是出题本意。判题时以语义为准不要被排版带偏。如果命令经过还原后仍然不是完成题面任务的正规方式那就选 No。5.2 五个高频踩坑记录坑 1Redeploy 后动态公共 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。坑 4kubeconfig 指向旧集群导致应用部署错环境现象执行 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 五条实验链路错题到验证命令的映射备考的最后一公里不是把正确率刷到百分之百而是让每道错题都能落成一条可以重复执行的命令链路。下面这张表是我把常见错题映射成实验动作的方法每条链路都对应一门技术主题错题主题复现动作预期结果VM 故障迁移对测试 VM 执行 RedeployVM 状态回到 Running配置保留模板参数密码用 Key Vault 引用密码部署 VM部署成功且日志不出现明文密码AKS 部署 YAML安装 kubectl 并 apply 清单Deployment/ReplicaSet 正常创建权限访问异常移除访问策略再部署报错提示无法访问密钥kubectl 环境错乱切换上下文部署资源出现在目标集群每条链路都能在十几分钟内完成验证的不只是答案而是你对命令边界的理解。6.2 一条命令串起整条验证链路把几项技术串成一条流水线是我在备考时用过的最有效的收尾动作。下面这套脚本会依次完成建资源组、部署带 Key Vault 引用的 VM、触发 Redeploy、创建 AKS 集群、接入凭据、部署 YAML。整体耗时约二十分钟结束时把资源组删掉即可。rgrg-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 里的资源部署、安全存储、容器操作这三条主线就有了可迁移的实操经验。从那以后我每刷一道题都会先把它拆成一个“如果让我在控制台上做我会敲什么命令”的问题再在测试资源组里真实跑一遍题库里的正确率反而没那么重要了。考场上遇到没见过的题目边界感会帮你推导出最合理的选项。希望帮到你。本文还有配套的精品资源点击获取