简介：AZ-204 2022最新题库是微软Azure开发人员认证的备考资料，面向正在准备AZ-204考试的开发者、运维人员及需要熟悉Azure云开发的工程师，用于快速摸排自身薄弱环节。内容摘录自真实考试场景，重点覆盖Azure虚拟机迁移与重新部署、通过Azure Resource Manager模板结合Key Vault安全传递管理员密码等高频考点；在虚拟机问题上，正确做法是从Redeploy刀片执行重新部署，使VM迁移到新的基础节点并维持原有配置，而管理员密码则需借助Key Vault将其保存为机密，并通过访问策略限定读取权限，从而避免模板中出现明文。每个题目均附有参考答案、简洁解释和官方文档链接，同时保留了社区投票分布及考友评论，能直观看出易错选项。资源包非常小巧，仅有1个PDF文件，压缩包大小221KB，适合随手打开阅读或打印复习。目前已有338人学习下载，答案准确度获得多数考友认可。通过该题库，可熟悉典型题目的解答思路，强化对Azure资源管理、安全与部署流程的掌握，为顺利通过AZ-204打下基础。

1. 一份 AZ-204 模拟题，别急着背答案

考 AZ-204 的工程师大多有个共同习惯：拿到题库先把答案背下来，再回头翻文档对知识点。结果往往是背了半个月，遇到原题换了问法照样翻车。这份 AZ-204 2022 最新题库的特别之处在于，它不仅仅是答案加参考链接，还保留了每道题下面的社区讨论和最终投票分布。我看到 Topic 1 前几题的时候就明显感觉到，这类题考的不是“你会不会点按钮”，而是“你知道不知道 Azure 底层发生了什么”。比如虚拟机迁移那道题，四个选项里三个都是误导项，真正的考点是 Redeploy 的机制；再比如 AKS 部署 YAML 那道，社区对答案的投票居然僵持在 60% 和 40%，这种争议恰恰是理解 kubectl、Azure CLI、Docker 三者边界的最好素材。这份题库适合两类人：一类是准备 AZ-204 认证、想系统过一遍 Azure 开发核心考点的开发者，另一类是已经做过 Azure 项目、想看看官方考试怎么把这些日常操作变成陷阱题的从业者。我建议你先不要看答案，把每道题的选项当成一次技术评审来分析，然后再对照社区讨论，收获会大得多。

2. 虚拟机迁移：Redeploy 考点与“换订阅”干扰项

2.1 题目场景还原与四个选项的意图

原题描述的是两个 Hyper-V 主机 Host1 和 Host2，Host1 上有一台通过自定义 Azure Resource Manager 模板部署的虚拟机 VM1，要求把 VM1“移动”到 Host2。选项 A 是从 Update management 刀片点击 Enable，选项 B 是从 Overview 刀片把 VM1 移到另一个订阅，选项 C 是从 Redeploy 刀片点击 Redeploy，选项 D 是从 Profile 刀片修改 usage location。先别急着选，这道题最大的坑在于“移动”这个词。日常我们说的移动 VM，要么是迁移到另一台物理宿主机，要么是换订阅、换区域，但 Azure 术语里的 Redeploy 和这些完全是两码事。

Redeploy 的中文含义是“重新部署”，操作上就是把虚拟机从当前所在的 Azure 基础设施节点上释放，再调度到一个新节点上重新启动。整个过程中虚拟机的配置、托管磁盘、网络接口和关联资源都不会丢，但底层宿主机一定会换。官方文档里明确提到，当遇到虚拟机所在节点硬件故障、宿主机需要维护，或者你觉得 VM 卡在某种异常状态时，可以通过 Redeploy 触发一次底层迁移来尝试修复。选项 B 的“移动到不同订阅”是 Azure 里的“转移订阅”操作，它改变的是资源的管理边界，不是底层宿主机位置；选项 D 的 usage location 是删除资源时用的区域信息，跟宿主机毫无关系；选项 A 更离谱，Update management 是用于补丁管理的，跟节点迁移没有任何交集。所以正确选项是 C，这一点社区投票也是 100% 一致。

2.2 用 Azure CLI 复现 Redeploy 的真实行为

这道题虽然考的是门户刀片操作，但作为开发人员，实际工作里很少只依赖门户。你大概率是在 Azure CLI 或者 PowerShell 里完成排查和操作。Redeploy 对应的 Azure CLI 命令是az vm redeploy，它有两个必填参数：--resource-group和--name，分别指定资源组和虚拟机名称。在跑这条命令之前，一个值得养成的习惯是先查一下虚拟机当前的实例视图，确认它的运行状态和故障状态。

# 查看虚拟机当前运行状态、provisioningState 和故障信息 az vm get-instance-view \ --resource-group rg-app-prod \ --name vm-app-01 \ --output table # 执行重新部署，把 VM 迁移到新的 Azure 基础设施节点 az vm redeploy \ --resource-group rg-app-prod \ --name vm-app-01 \ --no-wait

第一个命令里--output table是为了让人快速扫一眼状态列，provisioningState如果是 Succeeded 才建议继续操作。第二个命令加了--no-wait，它的作用是让命令立即返回，不在终端里阻塞等待操作完成，因为 Redeploy 一般要几分钟，期间虚拟机会经历“停止-迁移-启动”三个阶段。去掉--no-wait的话，CLI 会一直挂在那里直到操作结束，适合你在 CI 脚本里需要同步确认结果的场景。需要注意的是，Redeploy 触发后虚拟机会先进入 Stopping 状态，然后被调度到新节点，最后重新开机，公网 IP 如果用的是动态分配，可能会变化，临时磁盘上的数据会全部清空。这就是为什么生产环境做 Redeploy 前，必须先确认应用数据不在临时盘，也不依赖动态公网 IP。

2.3 为什么“换订阅”是最容易上头的干扰项

很多做过 Azure 管理的人看到“把 VM1 移到 Host2”的第一反应，就是“要用 Azure Resource Move 或者换订阅”。这种直觉来自日常运维惯性——跨宿主机迁移、跨订阅迁移、跨区域复制，这些操作在 Azure 里都存在，但对应的服务完全不一样。跨订阅移动用的是az resource move或者门户的“移动”按钮，作用是改变资源的归属订阅；跨区域复制用的是 Azure Site Recovery 或者磁盘快照加重新创建，作用是改变资源的部署地；而题干里这个“Host1 到 Host2”根本不是跨区域也不是跨订阅，它只发生在同一个 Azure 区域内部。理解这一点之后再回头看这道题，你会发现它考的不是操作入口，而是你对 Azure 底层故障处理机制的理解程度。

补充一个我在实际项目里踩过的细节：Redeploy 不是 Restart，这是两个完全不同的操作。Restart 是在同一节点上关机和开机，底层宿主机不变；Redeploy 则一定会换节点。如果虚拟机是因为某个节点上的硬件问题导致反复重启，你执行 Restart 多少次都没用，必须 Redeploy。判断该用哪个的关键指标是看 Azure 门户里虚拟机状态是否出现“Stopped (deallocated)”之外的异常，或者事件日志里是否有底层宿主机维护通知。az vm redeploy在执行时如果遇到主机故障，会把虚拟机迁移到健康的节点，这个行为在以 PaaS 方式部署的自建 CI 集群里特别有用，我自己的 Jenkins 控制节点就靠它救回过两次。

3. 保存管理员密码：ARM 模板、Key Vault 与访问策略

3.1 题目知识点拆解：为什么明文密码一定会翻车

第二道题是个拖拽题，题干说你已经下载了一个 ARM 模板，模板基于现有虚拟机生成，现在要往模板里塞一个管理员密码，并且确保密码不是明文存储，问你应该创建哪些组件。正确选项很明确：Key Vault 加 Access Policy。这道题的底层逻辑其实来自 ARM 模板的参数处理机制——模板里所有的值最终会以 JSON 文本的形式出现在部署请求中，任何写死在parameters里的字符串都等于明文。就算你用了个变量去引用它，只要变量值本身是字符串，资源管理器执行部署时它依然会出现在部署历史里，任何有资源组读取权限的人都能看到。所以唯一合规的做法是把密码存在 Key Vault 的 secret 里，模板部署时通过参数引用动态取出来。

顺便说一个很多开发人员理解错的地方：Access Policy 不是 Key Vault 实例的访问总开关，而是针对某个主体（用户、服务主体或安全组）的细粒度授权。你在创建 Key Vault 时如果不配置 Access Policy，哪怕你自己是订阅管理员，调用 Azure CLI 设置 secret 也可能被拒绝，因为新创建的 Key Vault 默认启用的是 Azure RBAC 和旧 Access Policy 的双模式，权限需要显式授予。这道题让你同时创建 Key Vault 和 Access Policy，本质上是在考“存储在哪”和“谁有权限读”这两件事。

3.2 最小可用实现：创建 Key Vault、写入 secret、在模板中引用

我在实际项目里通常是这么操作的。先创建一个 Key Vault，再把密码写入 secret，然后修改 ARM 模板的parameters部分，把它声明成securestring的引用对象。下面这段命令序列是可以在本地真实跑通的，我按顺序解释每一步的用途。

# 1. 创建资源组（如果还没有） az group create \ --name rg-arm-demo \ --location eastasia # 2. 创建 Key Vault，启用软删除以防误删 az keyvault create \ --name kv-arm-demo-001 \ --resource-group rg-arm-demo \ --location eastasia \ --enable-soft-delete true \ --retention-days 7 # 3. 把管理员密码写入 Key Vault，作为 secret az keyvault secret set \ --vault-name kv-arm-demo-001 \ --name vm-admin-password \ --value "P@ssw0rd!2024#Secure"

第一步没什么好说的，资源组是部署的容器。第二步里有个容易忽略的细节：--retention-days 7表示软删除的保留期是 7 天，这个配置在出事故时很重要，如果后续有人误删了 Key Vault，你会有一个星期的后悔药可以恢复，而不是彻底失去凭据。第三步把密码写入 secret，--name是 secret 的名称，--value是密码本身。请注意，往 secret 里存密码之后，最好在程序里或者运维流程里禁止再以明文形式出现这个密码的“第二份拷贝”，否则 Key Vault 的存在就失去了意义。

有了 Key Vault 之后，ARM 模板那边的写法是这样的：

{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "adminPassword": { "type": "securestring", "metadata": { "description": "Admin password, referenced from Key Vault" } } }, "resources": [ { "type": "Microsoft.Compute/virtualMachines", "apiVersion": "2022-03-01", "name": "vm-app-01", "location": "[resourceGroup().location]", "properties": { "osProfile": { "computerName": "vm-app-01", "adminUsername": "azureuser", "adminPassword": "[parameters('adminPassword')]" } } } ] }

这段模板的关键在于type: securestring和adminPassword的引用方式。securestring类型的参数在模板部署日志里不会以明文显示，但它的取值在部署时依然必须被解析出来，这就引出了一个问题：部署的时候这个值从哪来？答案是在部署命令的--parameters里通过 Key Vault 的 secret 引用传入，而不是直接填字符串。部署命令是这样：

az deployment group create \ --resource-group rg-arm-demo \ --template-file azuredeploy.json \ --parameters \ adminPassword=$(az keyvault secret show \ --vault-name kv-arm-demo-001 \ --name vm-admin-password \ --query value \ --output tsv)

这里$(az keyvault secret show ...)是命令替换，它会先调用 Azure CLI 从 Key Vault 里读出密码，然后作为参数传给模板部署。这个做法的优点是简单直接，密码不会出现在部署命令的历史记录里（因为你没有把密码硬编码在命令行里）；缺点是这个命令是在本地 shell 执行的，如果本地机器有恶意的进程在监测环境变量或 shell 历史，依然有泄露风险。更合规的方式是把 Key Vault 引用直接写进参数文件（parameters.json），用 ARM 模板原生的reference语法，让 Azure 资源管理器在服务端完成取值，本地全程不接触明文密码。

3.3 用 parameters.json 实现服务端引用

如果你走的是完整合规路线，做法是创建一个azuredeploy.parameters.json，里面的adminPassword不填实际密码，而是填一个 Key Vault 的引用对象：

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

这个写法眼尖的人会发现，参数文件本身没有包含密码，只有 Key Vault 的资源 ID 和 secret 名称。部署时 ARM 服务端会用自己的身份去 Key Vault 读取 secret，前提是在 Key Vault 的 Access Policy 里给“Azure Resource Manager 服务”配置读取权限。实际操作中，默认情况下资源管理器服务主体对用户创建的 Key Vault 并没有自动读取权限，所以你需要手动加一条：

az keyvault set-policy \ --name kv-arm-demo-001 \ --resource-group rg-arm-demo \ --secret-permissions get \ --object-id $(az ad sp show --id "http://Microsoft.Azure.ResourceManager" --query id --output tsv)

这段命令的作用是把get权限授予 ARM 服务主体。有经验的工程师看到这里应该会心一笑——这道概率题从表面看只是问“创建什么组件”，实际上背后藏着的是整个部署链路里的权限设计。真到了生产环境，你还要额外考虑 Key Vault 的软删除保护、Purge Protection、网络访问限制（VNet 规则或 Private Endpoint），但这些在考试层面不会展开，知道 Key Vault + Access Policy 的搭配逻辑就足够拿分了。

另外一个必须强调的细节：如果模板里有多个 VM 需要共用同一个密码，secret 只需要写一份，参数的引用可以在每个 VM 资源里重复使用，不要给每台 VM 创建独立的 secret，那会增加管理成本而且容易在轮换密码时漏掉某一份。

4. AKS 部署命令：kubectl apply 正误题的答案分歧

4.1 第三题：Azure CLI 与 kubectl 的边界之争

第三题的完整场景是一家公司有自己的 AKS 集群，管理员设备已经加入 Azure AD，开发者用容器镜像打包了一个叫 MyApp 的应用，现在需要部署 YAML 清单文件。题干给出的方案是：在设备上安装 Azure CLI，运行kubectl apply -f myapp.yaml，问是否满足需求。社区投票是 A 60%、B 40%，这个分歧本身就值得深挖。

分歧的本质是：题目文本里有个明显的语法问题。杠精版答案是 B，理由是 Azure CLI 内部不包含 kubectl 命令，直接跑kubectl apply会失败，必须先执行az aks install-cli安装 kubectl；审题宽泛版答案是 A，理由是“you install the Azure CLI... and run kubectl apply -f myapp.yaml”这句话里已经说明在这台设备上同时存在 Azure CLI 和 kubectl，那跑kubectl apply当然没问题。微软官方 AKS 部署文档里的操作步骤是：先az aks get-credentials拉取集群凭据，然后kubectl apply -f myapp.yaml部署。后者的核心是先获取访问凭据。也就是说，如果你的设备能成功连接集群，kubectl 命令本身是合法且有效的。

我的判断是，考试应该选 A。因为题干描述的是“安装 Azure CLI”和“运行 kubectl apply”这两个动作，它并没有混淆 Azure CLI 和 kubectl，题干关键在于考察你有没有部署 Kubernetes 应用的常识。B 选项支持者主要的论点是“Azure CLI 没有自带 kubectl”，但这个问题在真实操作中早就被az aks install-cli解决了。题目没提供安装 kubectl 的步骤，但不代表它禁止你安装。考试永远考的是“哪个选项能达到目标”，而不是“哪个选项能省掉一条命令”。这道题最终会选 A 还有一个佐证：同样的场景在第四题里，方案变成了“安装 docker client 并运行 docker run”，那个答案明确是 No，因为 docker run 根本不具备部署 Kubernetes YAML 的能力，两者等级完全不一样。

4.2 从零到部署：完整命令序列

不管考试怎么选，作为工程师我们日常在 AKS 里部署应用时,步骤是固定的。下面这段序列是我在多个项目里反复用的标准操作，每一步都有明确的目的。先装上 kubectl，再拿集群凭据，最后 apply YAML。

# 步骤 1：安装 kubectl 命令行工具（Azure CLI 不包含它） az aks install-cli # 步骤 2：获取 AKS 集群的访问凭据，并合并到本地 kubeconfig az aks get-credentials \ --resource-group rg-aks-prod \ --name aks-prod-01 \ --overwrite-existing # 步骤 3：检查集群节点状态，确认连接到正确集群 kubectl get nodes # 步骤 4：部署 YAML 清单文件 kubectl apply -f myapp.yaml # 步骤 5：观察部署结果，确认 Pod 没有 CrashLoop kubectl get pods -o wide

az aks install-cli这个命令很多人不知道，因为它在 Azure CLI 的文档里藏得比较深。它的作用是根据当前操作系统架构下载对应版本的 kubectl 二进制文件并安装到本地。第二步的--overwrite-existing参数很关键，如果本机 kubeconfig 里已经存在同名集群的旧凭据，不加这个参数就可能出现上下文冲突，导致 kubectl 连到旧集群的 IP 上去。第四步的kubectl apply是声明式命令，它会把 YAML 中定义的期望状态发送给 API Server，由控制面负责协调实际资源状态，这与kubectl create的“命令式创建”有本质区别——apply可以用于更新，create碰到已存在的资源会直接报错。

4.3 第四题：docker run 为什么必然不行

第四题的方案是安装 docker client，然后执行docker run -it microsoft/azure-cli:0.10.17。这个答案几乎是送分题，选 No 就对了，因为 docker run 是做容器运行时管理的，它启动的是一个交互式容器，这个容器里就算带了 azure-cli 工具，运行起来之后你依然要手敲 kubectl，而且这个镜像版本 0.10.17 都老得掉渣了。拉取镜像的过程中，如果本机没有缓存，还会先经历一次镜像下载，整个方案从效率到语义都不符合题目目标。更关键的考点是：docker run 启动命令执行完就结束了，它不会读取任何 Kubernetes 清单文件，也无法向 AKS API Server 提交期望状态。

把这两道题放在一起看，你就能看出微软出题的套路了：它想考的是“你知道不知道每个工具的定位”。Azure CLI 是用来管理 Azure 资源的，kubectl 是用来管理 Kubernetes 资源的，Docker CLI 是用来管理容器镜像和容器的，三者工作在不同抽象层。同一件事，用对了工具链就是可行方案，用错了工具就是无效操作。考试里的拖拽题和场景题都倾向于把“看似相关但不是正确选择”的干扰项做得非常有迷惑性，区分它们的最好方法是回到工具本身的官方文档，看它声称能做什么，而不是看它名字里带不带“cloud”或者“azure”。

5. 避坑排查：题库里最容易带偏的 5 个细节

5.1 现象：题目里的kubectl apply命令被打了反引号

原题里出现过类似kubectl apply"f myapp.yaml的写法，反引号在 Markdown 里是代码标记，但这个位置明显是格式错乱，实际命令应该是kubectl apply -f myapp.yaml`。

原因：这是 ExamTopics 这类题库站点的 Markdown 解析问题，-f前后的文字被误处理成了代码标记，导致显示出来的命令看起来多了个反引号。

解决：做题的时候遇到命令格式“看着不对劲”的情况，先去官方文档或者本机试一下，不要因为命令格式错误就否定整道题的逻辑。判断命令可用性最稳的方式是看官方文档的语法描述，而不是看题目里的字符排列。

5.2 现象：Redeploy 被误解成“换区域”或“跨订阅迁移”

有人看到“把 VM1 从 Host1 移到 Host2”就开始想 Azure Site Recovery 怎么做复制、怎么配置容灾，然后选出一个根本不存在的选项。

原因：题目里的 Host1 和 Host2 指的是底层 Azure 基础设施节点，不是地理区域。没有认真读题干的人会把这两个 Host 想象成两台本地 Hyper-V 服务器，从而套用自己的本地迁移经验。

解决：AZ-204 是 Azure 开发认证，不是本地运维认证，它考的是在 Azure 平台内实现解决方案的能力。凡是在题目里看到“虚拟机”“新节点”这类词，第一时间先想 Azure 平台对应的服务语义，Redeploy 就是处理“节点级故障”的标准答案。我通常会额外检查一下az vm redeploy的官方文档确认它不是跨区域操作，加深对这道题的理解。

5.3 现象：Key Vault 创建了却没有配置 Access Policy，部署失败

很多人照着教程创建完 Key Vault，把 secret 写入成功，但部署 ARM 模板时报错，提示无权访问 Key Vault 里的 secret。

原因：创建 Key Vault 之后，默认情况下并不是所有主体都能读写 secret。如果你通过门户直接创建 secret，门户会自动帮你加上当前用户的管理权限，但如果你用 ARM 模板在服务端引用，ARM 服务主体需要显式的get权限。

解决：在部署之前先用az keyvault set-policy配置好针对 ARM 服务主体的读取权限，或者更稳妥的做法是直接给部署操作者的服务主体授权。这个坑在考试不会直接出现，但在项目里几乎 70% 的人会踩一次。

5.4 现象：社区投票分布已经变成 60% 对 40%，却依然坚持 B

原因：有些人在社区讨论里看到反对意见就直接被带着走，忽略了反对意见本身的论证基础。那个说必须选 B 的人，论据是“Azure CLI 不包含 kubectl”，但这个论据并不能证明kubectl apply这个命令在完成目标上无效。

解决：先看题目给的目标“部署 YAML 清单文件”，再看方案“安装 Azure CLI + 运行 kubectl apply”，最后判断这个方案能否达成目标。只要 kubectl 可用、凭据可获取、YAML 路径正确，方案就是可行的。工具链是否“内置”从来不是判断可行性的依据，考试考察的是结果。以后做任何题目，都先锁定目标，再核对方案，最后才查工具细节。

5.5 现象：备考时发现题目里的参考链接已失效或跳转到了别的认证页面

原因：Azure 文档更新频繁，很多题目的官方参考链接在几个月后就会因为文档重组织而迁移到新的 URL。比如 AKS 部署文档在 2023 年就被整合过一轮，旧链接直接 404。

解决：遇到参考链接失效，不要慌，也不要在评论区抱怨。直接搜题目的核心操作关键词，比如kubectl apply、az keyvault secret set、az vm redeploy，找到微软官方文档的最新地址，再结合当前文档内容判断旧答案是否依然成立。这是备考任何云厂商认证都要具备的基本能力，题库是起点不是终点。

6. 把答案跑一遍：az 与 kubectl 命令级验证

备考 AZ-204 这段时间，我养成了一个习惯：所有的题目答案，只要涉及具体命令，都必须在本机真实跑一遍，哪怕只是--help看一下参数列表，也算完成一次验证。这个方法帮我避开了很多不必要的踩坑。

第一类验证是虚机迁移考点。我不会真的去生产环境执行 Redeploy，但我至少会执行一下az vm redeploy --help，确认参数名称和含义，再用az vm list -g <rg> --query "[].{name:name, resourceGroup:resourceGroup}"确认我的资源组里有没有测试机可以演练。如果条件允许，我会在非生产环境里找一台测试 VM 真实执行一次 Redeploy，整个过程观察az vm show -g <rg> -n <vm>里的provisioningState变化。亲手跑过一次之后，这道题就再也不会错了，因为你会记住 Redeploy 会先把 VM 停止，再迁移节点，最后重新开机，这和 Restart 的瞬间重启体验完全不同。

第二类验证是 Key Vault 引用。我会把 3.2 节那段命令在测试环境完整执行一遍，特别注意az keyvault secret show的输出格式。这里有一个很隐蔽的坑：--query value --output tsv拿出来的值可能在 Windows PowerShell 里出现编码问题，导致 YAML 文件解析失败。为了彻底避免这个问题，我在生产环境里一定优先选择 parameters.json 服务端引用的方式，而不是本地命令替换。你可以用一个简单的脚本循环测试这两种方式的可重复性——服务端引用在 CI 里永远稳定，本地替换则容易受 shell 类型和转义字符影响。

第三类验证是 kubectl。很多工程师觉得本地没装 kubectl 就没法验证，其实不需要。你可以用az aks install-cli --dry-run看这个命令支持的参数，也可以直接去 Kubernetes 官网下载对应版本的 kubectl 二进制，然后对着myapp.yaml文件执行kubectl apply --dry-run=client -f myapp.yaml。这个--dry-run=client参数的作用是只做客户端本地校验，检查 YAML 内容是否符合 Kubernetes API 的基本格式，不会真的把请求发给集群。

# 校验 YAML 语法和基本资源定义（无需连接集群） kubectl apply --dry-run=client -f myapp.yaml -o yaml # 如果本机有 kubeconfig 且已连接集群，可以使用服务端校验 kubectl apply --dry-run=server -f myapp.yaml

--dry-run=client和--dry-run=server的区别值得单独记一下：前者是纯本地语法检查，适合在代码提交前快速过滤低级别的编写错误；后者会把请求发送到 API Server，由 Kubernetes 控制面的准入控制器做实际校验（比如检查镜像仓库是否存在、服务名是否合法、命名空间是否存在），适合在正式 apply 之前做最终门禁。我一般本地验证用 client 模式，CI 流水线里用 server 模式。只有跑通这两步之后，才是真正的kubectl apply部署。

再给你一个治本的建议：把这三类验证写成一组 Azure CLI 的 Notebook 或者 shell 脚本，放在自己常用的工程目录里。里面可以留一个README.md，记录每次验证时用的订阅 ID、资源组名和有代表性的输出信息。从那以后，我备考任何云厂商认证都强制自己走一遍这个流程：先看答案争议，再核对官方文档，最后在本机跑通命令。这个过程不仅能帮你形成正确的路径依赖，还能在面试时拿出“我不仅知道选 C，还知道 Redeploy 之后动态公网 IP 会变”这样的实战细节。希望帮到你。

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