★ FEATURED ARTICLE 简介面向 AZ-204 认证考生的最新题库精编聚焦微软 Azure 开发人员核心技能内容覆盖虚拟机迁移与重新部署、Azure Resource Manager 模板安全管理、AKS 容器化应用部署等高频考点适合即将参加认证考试或希望系统自测 Azure 开发能力的开发者。资源为单个 PDF 文件体积仅 221KB轻便实用可离线阅读、按 Topic 逐一刷题。目前已有 339 人学习。题库选取 Topic 1 多道典型题目每题附正确答案与解析部分题目标注社区投票分布、精选评论及官方文档参考链接。题目场景具体如通过“重新部署”操作将 Azure 虚拟机迁移到新 Host 节点同时保留配置与关联资源使用 Azure Key Vault 与访问策略保护管理员密码避免在模板中以明文存储以及基于 AKS 集群通过 kubectl apply 部署 YAML 清单。这些解析有助于厘清常见误区、熟悉命令与门户操作适合备考冲刺阶段查漏补缺也可作为评估自身 Azure 开发能力的实用自测材料。1. AZ-204 复习地图题库不是用来背答案的是用来串服务的AZ-204 认证是一场用选择题包装的边界判断考试它很少直接问你某个命令是什么而是给你一段残缺的操作场景让你判断该用哪个动作、哪条命令、哪个权限。这套题库里的四道题表面是虚拟机迁移、模板密码、kubectl 部署、docker 命令背后其实只考一件事——你能不能把 Azure 的服务边界、命令边界和权限边界分清楚。适合谁适合已经写过一点 Azure 代码、但面对两个相近选项就犹豫的人。把它当成地图看虚拟机是计算入口ARM 模板是配置入口Key Vault 是安全入口AKS 是容器入口。下面沿这四条线逐层展开最后落到一张能自检的复习清单。2. 虚拟机与 ARM 模板重新部署、密钥托管与参数传递的考点闭环第一道题干里埋着最容易误读的线索两个 Hyper-V 主机 Host1 和 Host2一台由自定义 ARM 模板部署的 VM1。题目问把 VM1 移动到 Host2应该做什么。很多复习到一半的人会往迁移方向想把 VM 导出、复制、跨订阅移动。但 Azure 虚拟机根本没有暴露物理主机概念Host1、Host2 这两个名词是用来干扰你的。真正对应的操作是重新部署官方文档对这个动作的定义是把 VM 移动到 Azure 基础设施内的新节点然后重新开机保留所有配置和关联资源。2.1 重新部署RedeployVM 迁移问题的标准答案与前提选项 A 是从更新管理刀片启用。更新管理解决的是操作系统补丁和更新评估它不会改变虚拟机的宿主节点。如果 VM 因为底层硬件故障或宿主机异常导致无法访问更新管理帮不上忙。选项 B 是把 VM 移动到不同订阅。这是跨订阅的管理操作调整的是资源归属和计费范围不是底层运行位置也不解决节点级故障。选项 D 是修改使用位置这更像改资源元数据对运行节点毫无影响。真正符合题目语义的只有 C。再理解一下重新部署的边界。它不等同于重启重启只是让 VM 在当前节点上重新启动而重新部署会把 VM 放到新节点然后开机。它也不等同于删除重建VM 的系统磁盘、配置、网络接口和关联资源都会保留。但有一个容易被忽略的副作用本地临时盘临时 SSD的数据会丢失动态公网 IP 可能变化。如果应用把临时状态写在临时盘里重部署后这部分数据拿不回来。实际排障时判断该不该重部署有一个简单分工如果 VM 的状态是 Running 但 SSH/RDP 连不上、Azure 门户上显示底层基础设施问题优先考虑重新部署如果是应用层故障、配置错误、服务启动失败重部署大概率治标不治本甚至掩盖真正的问题。考试里记住一个动作即可az vm redeploy --resource-group MyRG --name VM1这条命令的作用就相当于在门户的重新部署刀片点一下Azure 会把 VM 迁移到底层基础设施的新节点再启动。参数里最重要的是资源组名和 VM 名两者错了会直接报 NotFound 或验证失败。如果执行后 VM 仍无法连接要去看启动诊断和串行控制台日志而不是反复重部署——反复重部署不会把应用层问题修好。2.2 ARM 模板为什么不能写死密码参数化的主线第二道题是个拖放题你已经下载了一个 ARM 模板来部署大量虚拟机模板基于一台现有虚拟机但要改造成引用管理密码且密码不能以明文存储在模板里。需要创建什么组件答案是 Key Vault 和访问策略。这里的关键不是把密码写进模板参数文件——参数文件同样是仓库里的明文。正确思路是让模板在部署时才从 Key Vault 读取密码模板本身只存 Key Vault 的引用信息。ARM 模板中的 secret 引用长这样{ parameters: { adminPassword: { reference: { keyVault: { id: /subscriptions/xxx/resourceGroups/MyRG/providers/Microsoft.KeyVault/vaults/MyVault }, secretName: vmAdminPassword } } } }这个 JSON 片段做了一件事声明一个名为 adminPassword 的模板参数它的值不是静态字符串而是来自指定 Key Vault 中名为 vmAdminPassword 的 secret。部署引擎在部署时才去取这个 secret模板文件里不出现密码本身。比写死强在三点模板能进代码仓库密码轮换不需要改模板谁有权限读 secret 可以被审计。使用这种引用时有三个先决条件要同时满足Key Vault 存在、secret 存在、执行部署的主体对那个 secret 有读取权限。很多人做成前两步就停了结果部署报错时看到的提示是访问被拒绝而不是密码错误。另外同一个 Key Vault 可以放多组 secret例如管理员密码、数据库连接串、证书。模板中每个敏感参数都可以单独引用不同的 secret这样一套模板可以适配多套环境只需切换 Key Vault 或 secret 名。2.3 Key Vault 访问策略从建库到引用的完整动作把密码放进 Key Vault 的完整动作是三段式建库、放 secret、授权。建库用 az keyvault create放 secret 用 az keyvault secret set授权用 az keyvault set-policy。三条命令串起来是这样az keyvault create --name MyVault --resource-group MyRG az keyvault secret set --vault-name MyVault --name vmAdminPassword --value 你的密码 az keyvault set-policy --vault-name MyVault --upn userexample.com --secret-permissions get第一行创建密钥库返回一个 vault uri后续命令都要通过 --vault-name 定位。第二行把密码作为 secret 存入secret 名称会成为引用路径的一部分命名建议和用途对齐比如 vmAdminPassword、sqlConnectionString方便模板引用。第三行给某个用户授予 get 权限这里要是漏了模板部署时会得到权限不足的错误而很多人第一反应是检查模板语法实际上问题在权限。权限模型值得再拆一层。访问策略分两类管理面权限控制 Key Vault 本身的增删改查通过 Azure RBAC和数据面权限对 secret、key、certificate 的读取通过访问策略或新的 RBAC 方式。考试和实操中最常卡的都是数据面权限。模板部署场景里执行 az deployment group create 的那个人必须对 secret 有 get 权限如果 VM 在启动时要读取 secret 来初始化应用那要配置托管身份并结合角色分配不能直接把用户密码塞给 VM。在这条知识线上最容易忽略的是模板中的参数默认值和Key Vault 引用的区别。前者是模板文件里写死的 fallback 值后者是部署时的动态读取。有人在模板里写adminPassword: { type: securestring, defaultValue: Pssw0rd! }这就是把密码明文写进了模板和 Key Vault 引用是两回事。securestring 只保证部署日志里不显示明文不保证模板文件本身不泄露。判题时只要看到明文二字就不该把 securestring 单独作为答案。3. 容器与 AKSkubectl、Azure CLI 与 YAML 部署的分工边界第三、四道题是同一场景的两种方案对比AKS 集群Azure AD 加入的设备开发了一个被打包成容器镜像的应用 MyApp要部署 YAML 清单。方案一安装 Azure CLI 并运行 kubectl apply方案二安装 docker client 并运行 docker run。两道题的答案分别是 Yes 和 No。放在一起看考试考的不是会不会敲命令而是能不能分清楚工具链里谁负责哪一步。3.1 kubectl apply 解析为什么用 kubectl 而不是 Azure CLI先看标准动作。kubectl apply -f myapp.yaml 会把 YAML 清单里的期望状态提交给 Kubernetes API Server创建或更新 Deployment、Service 等对象。apply 的语义是声明式的它先对比当前状态与清单里声明的状态再决定创建、修改还是删除。对比之下kubectl create 是命令式的强调的是创建如果资源已存在会报错kubectl replace 则是整体替换。考试里出现 apply 时重点认准应用配置变更、来自文件或 stdin这个定义。但这里有个绕不开的坑kubectl 不是 Azure CLI 的一部分。Azure CLI 负责管理 Azure 资源例如创建 AKS 集群、获取凭据kubectl 负责管理 Kubernetes 资源。要在这台 Azure AD 加入的设备上执行 kubectl apply前置动作是用 az aks install-cli 安装 kubectl再用 az aks get-credentials 下载集群凭据。完整链路是az aks install-cli # 安装 kubectl 可执行文件 az aks get-credentials --resource-group MyRG --name MyCluster # 写入 kubeconfig kubectl apply -f myapp.yaml # 应用 YAML第一条命令把 kubectl 装到本机第二条命令访问 AKS 管理面把集群的访问信息写到 ~/.kube/config第三条命令才真正部署应用。少了第二条kubectl 不知道连哪个集群会报unable to find cluster或连接超时。题目方案只写了安装 Azure CLI 并运行 kubectl apply判题时为什么算 Yes因为方案的核心动作是 kubectl apply它确实能部署 YAMLAzure CLI 的安装可以看成准备步骤后续完全可以通过 az aks install-cli 补上 kubectl。这是常见判题口径方案包含正确动作、且能补全前置条件时算满足目标。较真的人会选 No理由是 Azure CLI 本身不提供 kubectl 命令。但注意题干问的不是Azure CLI 是否直接包含 kubectl而是这个方案能否完成部署。答案 A 更贴合题目语义评论区大部分人也支持 A。3.2 docker run 的迷惑性容器命令、K8s 命令与云 CLI 三者边界第四题的方案改为安装 docker client运行 docker run -it azure-cli:0.10.17。正确答案是 No理由很直接docker run 是容器生命周期命令作用是启动一个容器并进入交互终端它不会把任何 YAML 应用到 AKS。拆开看这条命令docker run 表示创建并启动容器-it 表示分配交互终端azure-cli:0.10.17 是一个包含 Azure CLI 工具的镜像。整体效果是进入一个装着 azure-cli 的临时容器连 AKS 集群都没连接更谈不上部署。即使进入容器后再敲 az aks get-credentials也还要装 kubectl、写 kubeconfig、再 apply题干没有提供这些步骤。这个选项是典型的翻车现场很多人看到azure-cli四个字母觉得和 Azure 有关就以为它能部署 AKS。但工具与目标不匹配。区分三个角色Azure CLI 管 Azure 资源面kubectl 管 Kubernetes 资源docker 管本地容器。AKS 是托管 Kubernetes 集群它的工作负载只能由 kubectl 或其他 K8s 客户端操作docker run 管不到云端集群。如果真想用容器来管理 AKS正确的做法是进入一个已安装 kubectl 的容器再执行命令而不是把 docker run 本身当成部署动作。这类题的通用判断公式是先看命令动词作用在哪个资源上。docker run 作用于本地容器kubectl apply 作用于集群对象az deployment group create 作用于资源组部署。命令动词和题目目标资源不匹配时直接排除不要考虑镜像名字有多像。3.3 AKS 部署链路从镜像构建到 YAML 应用的完整动作把第三、四题拼起来就是一条完整的 AKS 部署链路开发者在本地或 CI 构建容器镜像推送到容器注册表AKS 集群从注册表拉取镜像YAML 清单声明部署kubectl apply 把清单提交给集群集群创建 PodService 对外暴露。这条链路里每一步都有专属工具环节工具/命令作用对象登录 Azureaz loginAzure 身份获取集群凭据az aks get-credentials本地 kubeconfig安装 kubectlaz aks install-cli本机可执行文件应用 YAMLkubectl apply -f myapp.yaml集群对象查看状态kubectl get pods / nodes集群对象部署完成后不要直接走人验证步骤很重要。kubectl get nodes 看节点是否 Readykubectl get pods -A 看 Pod 是否 Runningkubectl get svc 看 Service 是否分配到外部 IP。如果 Pod 一直 Pending通常是资源不足或镜像拉取失败如果 CrashLoopBackOff问题在应用启动命令或配置。这些状态码本身就是一道案例题考的不是哪条命令能部署而是部署后怎么判断成功与失败。从题库的复习角度看AKS 这一列要背的并不是 docker run 的参数而是谁能对集群做什么创建集群要用 Azure CLI 或门户连接集群要用 kubeconfig应用发布要用 kubectl。把三个工具按管理面-连接面-数据面分层就不会再在 docker run 这种选项上犹豫。4. AZ-204 易错点复盘四道题背后的判断陷阱与补漏方法这四道题的正确答案不算难难的是干扰项为什么能骗人。把评论区的高赞讨论和投票分布放一起看至少有四个反复出现的易漏点。下面每一条都按易漏点是什么、为什么会漏、怎么补来写写出来的部分可以直接对照自己的做题习惯。4.1 易漏点一题面里的乱码/typo 被当成新考点易漏点第三题题干里 kubectl apply f myapp.yaml 明显是个 typo正确写法是 -f。有人看到引号和奇怪的符号认为命令本身是错的于是选 B。为什么漏题库搬运过程中反引号和引号经常丢失或错位尤其英文双引号在部分编辑器里会变成特殊字符复习者误以为这是故意埋的语法坑。怎么补先还原标准命令形态kubectl apply -f 是 Kubernetes 文档中的标准用法出现异常字符时去查原始命令而不是纠结字符。判断题干问的是方案能否完成部署typo 不影响方案本质。我复习时会先用笔把命令抄一遍规范形式再决定选项这样不会被搬运痕迹带偏。4.2 易漏点二把能操作当成该操作的权限幻觉易漏点第四题的 docker run 选项误选率不低。容器里确实有 azure-cli 镜像看起来可以做 Azure 操作于是一边犹豫一边选了 Yes。为什么漏因为忽略了 docker run 的语法和作用域它启动的是容器不是把命令应用到远程集群。很多人把镜像里有工具等同于工具已经被正确调用了。怎么补把命令拆成动词 目标docker run 的动词是 run目标是本地容器kubectl apply 的动词是 apply目标是集群。目标资源与题干需求不符时不管镜像里装了什么工具方案都不成立。以后再看这类选项先问自己这条命令的默认作用对象到底是哪一层4.3 易漏点三Key Vault 访问策略的权限边界被低估易漏点第二题的题面只问创建什么组件很多人答出 Key Vault 就停了漏掉 Access Policy或者把访问策略当成可选项。为什么漏因为只看到secret 存储没看到读取控制。实际上模板部署失败最常见的原因之一就是执行部署的主体没有对 secret 的 get 权限报错信息还容易被误读成模板格式问题。怎么补把 Key Vault 的使用拆成三个动作创建库、存 secret、授权 get。每次设计时都检查谁来读、他有没有权限、权限是否最小。做题时凡是涉及 secret 引用的选项访问策略几乎一定是配套答案。权限错误常见的提示是Access denied或the client does not have authorization看到这类字样要立刻往访问策略上排查而不是改模板。4.4 易漏点四社区投票分布不能直接当最终答案易漏点第三题评论区投票是 A 60%、B 40%第四题没有太大争议。有人习惯把投票比例当成判题依据哪个高选哪个。为什么漏投票者受 typo 影响、受自己对命令边界的误解影响甚至受旧版本工具链的影响票数高只能说明有争议不能证明逻辑正确。这道题里 A 选对的人很多但 B 的 40% 也不完全是瞎选他们反映的是kubectl 不在 Azure CLI 中这个事实只是没接住题干的问法。怎么补把投票当争议标记看到票数接近的题主动去查该命令的官方定义再用动词-目标-权限框架自行判断。真正稳定的答案是能从文档原文推导出来的而不是从评论区抄出来的。我个人的习惯是评论区只用来收集为什么有人选别的不用于确认最终答案。5. 把题库拆成知识网按服务→操作→命令→权限四层建复习索引单靠背答案应付不了 AZ-204因为同一考点换一个场景选项就会重新组合。更稳的做法是把每道题拆成四层做成自己的复习索引服务层考的是哪个 Azure 服务、操作层题目要你完成什么动作、命令层哪条命令或哪个门户操作能完成、权限层谁需要什么权限。四层都对上这道题才算真正掌握。5.1 四层拆题法的具体用法拆题的时候不要先看选项先看题干最后一句你需要做什么把它标记为操作层再往前找出现的关键服务名词标记为服务层然后凭自己的知识补出命令层和权限层最后才去看四个选项。这样做的好处是即使选项里混入你没见过的名词你也能凭操作层直接排除。用这套题库四道题做例子题目服务层操作层命令层权限层VM 迁移虚拟机把 VM 移到新节点az vm redeploy虚拟机参与者角色模板密码ARM 模板 Key Vault安全引用密码模板 reference部署者对 secret 的 getYAML 部署AKS应用 YAML 清单kubectl apply -fkubeconfig 中的集群权限docker runAKS错误命令识别无docker run 不适用无表格做完之后你会发现自己真正欠缺的是哪一层。比如有人服务层和操作层都懂但命令层只记得门户按钮不记得 CLI 命令有人命令层很熟但权限层从来不管。考试里权限层往往藏在需要确保为了……这样的限定句里拆题时把它单独框出来比通读三遍题干都管用。5.2 用一道题完整演示四层拆解拿第二题走一遍完整流程。题干说下载了一个 ARM 模板用来部署大量 VM模板基于当前 VM但必须改成引用管理密码并确保密码不是明文存储。你要准备创建什么组件。服务层先定位这是一个 ARM 模板部署场景涉及的 Azure 服务是虚拟机、ARM 和 Key Vault。操作层是把明文密码改成安全引用注意题目用了必须确保不是明文说明考的是安全设计不是模板语法。命令层对应的是创建 Key Vault、创建 secret、设置访问策略这是题目直接要求你准备的组件。权限层是谁在部署时读这个 secret谁就要有访问策略。用这个框架去看四个选项会清晰很多。如果选项里有把密码作为参数文件的一部分操作层就冲突因为参数文件仍然是明文如果选项只有创建 Key Vault而没有访问策略权限层就缺失因为模板部署者无法读取。只有Key Vault 访问策略同时覆盖命令层和权限层。这道题评论里有人把它和另一道类似题对照结论一致创建库和授权必须成对出现。拆完之后还可以往前推一步如果模板部署失败你按四层查漏的顺序是什么先查权限层部署者有没有 get再查命令层secret 名拼写对不对、vault id 对不对最后查服务层Key Vault 是否和模板在同一个可用区域。这个顺序和实际排障的性价比是一致的权限问题最隐蔽也最该先排除。5.3 扩展覆盖范围从四道题到 AZ-204 大纲四道题只能覆盖计算、模板、安全和容器四个点AZ-204 大纲里还有存储、消息、监控、身份等模块。建议用同一个四层索引去扫官方技能目标给每个高频服务建一行记录模块核心操作常用命令示例易错权限点存储创建账户、上传 Blobaz storage account create / az storage blob upload存储账户密钥 vs 托管身份消息队列、事件中心az servicebus queue create发送/接收的授权策略监控日志、指标、告警az monitor app-insights component create诊断设置与 Log Analytics 权限身份托管身份、AAD 应用az identity create / az ad app create角色分配范围不能只看资源级建这个表的时候每条只留一行逼自己只写最核心的动作。写完再对照每道题的选项看能不能把选项分类到服务层错误命令层错误权限层错误三类里。能分类就说明你不是在背答案而是在用知识网做题。6. 考前一周的复习清单与自测技巧把四道题变成一张查漏表最后一周不建议再刷新题把已有的题按四层索引复盘一遍就够了。我的做法是准备一张空白表列上大约十个高频服务然后强制自己两分钟内写完一行的四个字段服务名、核心操作、关键命令、权限要求。写不出来或写错的那行就是当天要补的查漏点。补的方法不是看答案而是重新读官方文档对应页面抄一遍命令再自己造一个类似场景复述。自测技巧也可以很简单把每道题的四个选项分别写下来不看正确答案自己标注每个选项错在哪一层。比如选项 B 错在权限层跨订阅移动解决不了节点故障选项 D 错在操作层docker run 的目标资源不是集群。能标出层次比标对答案价值大得多。有印象里我曾经在考前把 kubectl 和 Azure CLI 的关系背得很熟但一道变形题把安装了 kubectl 的容器和docker run混在一起我还是犹豫了很久。从那以后我每次考前都强制走一遍服务→操作→命令→权限四层拆题遇到任何选项先问作用对象是谁再问权限配了没有。这套方法不一定惊艳但至少让我再没在工具像不像这种选项上栽过。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
