企业官网建设流程全解析

简介：面向微软 AZ-204 认证备考者的 2022 版题库 PDF，适合 Azure 开发人员用于考前刷题、考点自查与薄弱环节定位，内容覆盖 Azure 资源管理、计算、存储、网络、监控以及身份与访问管理等认证领域。资源包共 1 个 PDF 文件，大小约 221KB，单文件结构轻量，便于在电脑或移动设备上随时查阅和标注。题库节选可见单选、拖拽等题型，并配有参考答案、官方文档参考链接及社区投票解析，涉及虚拟机重新部署到新节点、ARM 模板借助 Key Vault 与访问策略安全传递管理员密码、AKS 集群使用 kubectl 部署 YAML 清单等典型场景，可帮助读者把题目与 Azure 治理、安全和部署流程对应起来。已有约 340 人学习，适合需要借助真实题目梳理考点、验证理解并进行针对性查漏补缺的考生。

1. 知识地图：AZ-204 这张卷子先看清它把 Azure 拆成了哪几块

AZ-204 在 Microsoft certificate 体系里对应 Azure 开发者方向，题干从来不给按钮路径，而是给一个业务场景，让你在几个技术上都能跑通的方案里挑出最合适的那个。所以它真正考的不是记忆力，是「限定词敏感度」——题干里一旦出现 AD-joined device、不以明文存储、保留所有配置这类短语，答案基本就被锁死了。

复习时最省力的做法是先铺地图再填细节：计算与容器、安全与身份、存储与数据、消息与集成、监控与排错，五块地基上压着 App Service、AKS、Key Vault、Blob、Cosmos DB、Service Bus、Application Insights 这七八个高频面孔。这张地图适合已经上手过 Azure、正在系统过一遍的人；纯新手直接刷题会很痛苦，因为每道题的干扰项都建立在「你知道另外三个服务是干什么的」之上。

2. 计算与容器：VM 重部署、App Service 与 AKS 的边界

计算类的题有个固定套路：题干给你一个「想把 A 变成 B」的动作，四个选项里只有一个真正做了这件事，其余三个都在别的层面操作，而且看起来都很像「正经的管理动作」。VM 重部署那道题就是标准模板，把它拆开看，后面遇到 App Service 和 AKS 的题就能套同一套拆法。

2.1 那道 100% 选 C 的题：重部署到底动了什么

题干是这样的：两台 Hyper-V 宿主机 Host1 和 Host2，Host1 上跑着一台用自定义 ARM 模板部署出来的 VM1，现在要把 VM1 挪到 Host2。四个选项分别是更新管理刀片点启用、概览刀片把 VM 移到其他订阅、重新部署刀片点重新部署、配置文件刀片改使用位置。

把每个选项的「真实作用域」列出来，干扰项立刻现形：

正确答案是重新部署，理由是它把 VM 迁到基础设施里的新节点后重新开机，配置项和关联资源一个都不丢。这里最容易搞混的是「迁移」这个词——题目说的挪到 Host2，不是让你做一次跨宿主的可控迁移，而是用平台侧的重新部署把实例重新调度一遍。落到实际运维里，这类操作有明确的代价：整个过程是一次重启，业务一定有中断窗口；静态分配的公网 IP 不变，动态分配的公网 IP 有概率换掉；如果 VM 承载的是有状态服务，停机前先做一次应用层检查比什么都强。生产上更稳的做法是把实例放进可用性集或虚拟机规模集，靠多实例分摊单点重启的影响。

命令行里这条操作长得非常朴素，参数少到容易被忽略：

# 把 VM 重新部署到 Azure 基础设施中的新节点 # --resource-group 资源组名，--name 虚拟机名，两者共同定位目标 VM az vm redeploy \ --resource-group rg-demo \ --name vm1

执行完不会返回新的连接信息，因为配置没变；它解决的是「这台 VM 所在的物理节点有问题，但我又不想重建」这类故障。要注意它和另外三个动作的区别，这四个东西在题干里经常互相伪装：

看到「保留所有配置」「换节点」两个关键词同时出现，直接锁定重新部署，不用再往下想。

2.2 App Service：计划层级、部署槽与「改配置不改代码」

App Service 的题几乎都围绕一个矛盾转：怎么在不影响线上的前提下换版本。答案通常是部署槽加交换，但槽不是每个计划层级都有，所以第一件事是把层级表背下来：

Standard 起步才有槽，这条在题干里经常藏在「公司预算有限」这种描述后面。槽的工作机制值得单独记一遍：部署到 staging 槽 → 触发预热（应用真正启动、连接串加载、缓存预热）→ 交换 → 出问题再换回来。交换本身是「先预热再切流」，所以它不是一次重启，而是一次流量切换，这也是它比直接重新部署更安全的原因。

真正让人翻车的地方在配置上。应用设置分两种：普通设置会跟着交换一起走，槽设置（deployment slot setting）会粘在槽上不动。判断标准很简单——这个值在两个槽之间是否应该不同。数据库连接串、第三方沙箱密钥、环境名，都该是槽设置；日志级别这种可以跟着走的，用普通设置就行。

# --slot-settings 写入的值在交换时"粘"在槽上，不会跟着换到生产槽 # --settings 写入的值会随交换一起迁移，适合与环境无关的通用配置 az webapp config appsettings set \ --resource-group rg-demo \ --name app-demo \ --slot staging \ --slot-settings ASPNETCORE_ENVIRONMENT=Staging

很多人第一次做交换会发现 staging 的连接串跑到了生产上，原因就是把连接串写成了普通设置。命令里两个参数长得很像，区别只在一个--slot-前缀，记不住的话就记一句话：只有槽设置才能在交换后保持各槽不同。

再往下是缩放。纵向扩（scale up）换的是计划层级和单价，横向扩（scale out）换的是实例数。自动缩放规则要盯两个参数：最小实例数和冷却时间。最小实例数设成 0 省钱，但冷启动会让第一个请求超时；冷却时间设太短，指标抖动会让实例反复启停，账单和稳定性双输。规则想稳一点，就看队列长度而不是 CPU，CPU 对 I/O 型应用几乎没有指示性。

2.3 AKS 与容器：kubectl apply 和 docker run 是两条工具链

这一组是典型的一题两问、答案相反。第一问：在已加入 Azure AD 的设备上，装好 Azure CLI 后执行kubectl apply -f myapp.yaml部署清单，能不能达成目标？答案是可以，因为这条命令就是从文件或标准输入应用配置变更的标准方式。第二问：装好 docker 客户端后执行docker run -it microsoft/azure-cli:0.10.17来部署 YAML，能不能达成目标？答案是不行，因为这是启动一个带 CLI 的容器，容器里既没有集群凭据，也没有针对 YAML 的部署动作，跑完等于什么都没发生。

这两题背后是同一条判据：命令属于哪条工具链，决定它能不能干这件事。

实际敲的时候顺序不能颠倒，先拿凭据再 apply，否则连不上集群：

# 1) 把 AKS 的访问凭据写进本机 kubeconfig，后续 kubectl 才知道连哪 az aks get-credentials --resource-group rg-demo --name aks-demo # 2) 声明式应用清单：存在则更新，不存在则创建，可反复执行 kubectl apply -f myapp.yaml # 3) 如果机器上还没装 kubectl，Azure CLI 可以代装（这一步很多题默认已完成） az aks install-cli

这里有个备考时必须知道的现实差异：Azure CLI 本身不内置 kubectl，把它当成「装了 az 就有 kubectl」是错的；但考试判断的是「这个方案能否达成目标」，默认工具链齐备，所以第一问答案仍是「能」。这个分歧在题库里被争论了几百条评论，本质是把「方案对不对」和「环境齐不齐」两件事混成了一个问题。真到了考场上，看到「Solution: 执行某条标准命令」这种句式，先判断命令语义对不对，再判断环境。

容器类题目还会问选型，三者的边界记住一句话就够：要快、要一次性、不想管编排，用容器实例；要滚动发布、要服务发现、要副本管理，用 AKS；只是把现成镜像跑起来并且要平台的槽、缩放、认证集成，用 App Service 的容器方式。

3. 安全与身份：Key Vault 引用、托管标识与最小权限

安全这块的题几乎都能归结成一句反问：这个秘密放在哪、谁能读、读的时候有没有留在日志里。模板传密码那道题就是最经典的入口。

3.1 模板里的密码为什么不能明文：Key Vault 引用机制

题干描述：用 ARM 模板批量部署虚拟机，模板基于一台现有 VM 改出来，需要引用管理员密码，且密码不能以明文存储。正确答案是创建 Key Vault 加访问策略，把密码存成密钥库里的机密，模板只引用不保存。

为什么不能写在参数文件里，理由很实在：参数文件通常跟着代码一起进仓库，模板部署历史里也会留一份完整参数快照，密码写进去等于同时泄了两个地方，而且事后极难彻底清理。Key Vault 引用把「值」留在密钥库里，部署时由平台去取，模板和部署记录里只有机密名称。

{ "type": "Microsoft.Compute/virtualMachines", "apiVersion": "2023-03-01", "name": "vm-demo", "properties": { "osProfile": { "adminUsername": "azureuser", "adminPassword": { "reference": { "keyVault": { "id": "/subscriptions/<sub-id>/resourceGroups/rg-demo/providers/Microsoft.KeyVault/vaults/kv-demo" }, "secretName": "vm-admin-password" } } } } }

这段 JSON 的关键只有一件事：adminPassword不再是字符串，而是一个reference对象，指向某个密钥库里的某个机密名。keyVault.id必须写完整资源 ID，secretName是机密名称而不是值。部署时 ARM 会拿部署者的身份去读这个机密，所以还有一步前置开关必须打开：

# 允许 ARM 模板在部署时读取该密钥库中的机密和密钥 # 这一步不开，模板部署会直接报 KeyVaultParameterReference 相关错误 az keyvault update \ --name kv-demo \ --resource-group rg-demo \ --enabled-for-template-deployment true

这个开关是整道题最容易漏的前提——题库里所有讨论「答案为什么是 Key Vault + 访问策略」的高赞解释，都在补这一句。只建了密钥库、只存了机密、只配了策略，模板依然读不到，因为模板部署访问是独立开关。

3.2 访问策略与 Azure RBAC：同一把锁的两种钥匙

密钥库有两种权限模型：访问策略模型和 Azure RBAC 模型。同一个密钥库只能启用其中一种，切换之后旧的授权全部失效，这是实操里最容易踩的一脚。

考试里出现「用访问策略允许某应用读取机密」这种描述，指的就是第一种模型，不要跟角色分配混着答。托管标识则解决「应用用什么身份去读」的问题，本身不解决「能读什么」。

代码里最省事的写法是不写任何密钥，靠凭据链自己找身份：

// DefaultAzureCredential 依次尝试：环境变量里的服务主体、托管标识、开发者本机登录态 // 本机调试走登录态，线上自动走托管标识，代码一行都不用改 var client = new SecretClient( new Uri("https://kv-demo.vault.azure.net/"), new DefaultAzureCredential()); KeyVaultSecret secret = await client.GetSecretAsync("vm-admin-password"); string password = secret.Value;

参数说明只有一处值得强调：DefaultAzureCredential不是「万能凭据」，它依赖前面某一环真的可用。线上跑在托管标识下却没分配「Key Vault 机密读取者」这类角色，报错会是权限不足而不是凭据找不到，排查时要先看角色分配再看代码。多个环境共用一个用户分配标识时，记得它的权限是并集，一个应用放开会把共用它的应用一起放开。

3.3 SAS 与连接字符串：临时授权的分寸

存储的访问凭证有一张很实用的对照表，考试里经常拿来出「最合适」的题：

用户委托 SAS 的好处在于它不依赖账户密钥，签名用的是 AAD 身份换来的委托密钥，撤销身份权限就等于撤销了后续签发能力。

// 先向存储服务申请一段用户委托密钥，有效期覆盖 SAS 本身 UserDelegationKey key = await blobServiceClient.GetUserDelegationKeyAsync( DateTimeOffset.UtcNow.AddMinutes(-5), DateTimeOffset.UtcNow.AddHours(2)); var builder = new BlobSasBuilder { BlobContainerName = "uploads", Resource = "c", // c 表示容器级，b 表示单个 blob ExpiresOn = DateTimeOffset.UtcNow.AddHours(2) }; builder.SetPermissions(BlobSasPermissions.Read); // 只给读，别顺手给写 builder.UserDelegationKey = key; // 关键一步：挂上委托密钥

Resource写c还是b决定授权范围是整个容器还是单个对象，写错的表现是链接能生成但访问 403。ExpiresOn别为了省事设成几天，考试里凡是问「最安全」的选项，基本都是「最小权限 + 最短有效期 + 用户委托」。另外，SAS 一旦签发，在过期前无法单独吊销，只能靠撤销委托密钥或轮换账户密钥来间接失效，这个特性决定了过期时间必须保守。

4. 存储、消息与可观测：分层策略、一致性级别和异步选型

这一块是 AZ-204 里最像「架构题」的部分，因为几乎每道题都在问同一个问题：这几个服务都能存/都能传消息，你为什么选它。

4.1 Blob 访问层与生命周期：省钱省在分层上

最小存储期是最容易被忽略的收费规则：在 30 天内把冷层数据删掉或挪走，会按剩余天数补齐费用。所以生命周期规则不是「越早挪越好」，得先估算数据的实际访问曲线。存档层还有个额外的坑，读取前必须先解冻，标准优先级要几小时，高优先级也要更短但更贵，把交互式接口的备份放存档层属于自找麻烦。

{ "rules": [ { "name": "tier-old-logs", "type": "Lifecycle", "definition": { "filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["logs/"] }, "actions": { "baseBlob": { "tierToCool": { "daysAfterModificationGreaterThan": 30 }, "tierToArchive": { "daysAfterModificationGreaterThan": 180 }, "delete": { "daysAfterModificationGreaterThan": 365 } } } } } ] }

三个参数的含义分别是：prefixMatch限定只对logs/前缀生效；tierToCool的 30 天刚好卡在最小存储期上，不浪费；delete放到一年，避免和合规要求打架。规则是按修改时间算的，不是按创建时间，所以频繁被覆写的日志永远进不了冷层，这点在设计日志写入路径时就要想到。

冗余策略一起记：本地冗余最便宜但扛不住区域故障；区域冗余扛单区故障；异地冗余跨区复制，读访问型异地冗余额外提供只读副本端点；多区域地理冗余适合对区域级丢失也不能接受的场景。题目里出现「成本最低且能扛机房级故障」，答案通常是区域冗余，不是异地冗余。

4.2 Cosmos DB 的五种一致性：别把「最强」当默认

关键规则两条：一致性上限设在账户级别，客户端只能往下调不能往上调；分区键一旦选定几乎不能改，选错就得重建容器。热点分区是性能题的常见答案来源，比如按日期做分区键，写入全压在当天那个分区上，横向扩展等于白做。

// 账户上限是“会话”，客户端这里只能选等于或更弱的一致性 // ApplicationPreferredRegions 决定故障时的读取顺序，别把写区域写在最前面 var client = new CosmosClient(connectionString, new CosmosClientOptions { ConsistencyLevel = ConsistencyLevel.Session, ApplicationPreferredRegions = new[] { "East Asia", "Southeast Asia" } });

实际项目里选强一致的代价不只是延迟，还有跨区域写入能力的取舍，写区域多了冲突处理就得上手。考试遇到「既要全球分布又要强一致」这类描述，通常正确答案是提高一致性级别但限制写区域，而不是无脑选强一致。

4.3 队列、事件与消息：三种异步不能混用

记忆锚点：事件网格管「发生了什么」的离散事件，事件中心管「源源不断的流」，服务总线管「必须被处理一次的业务消息」，存储队列管「便宜好用但对语义没要求」。题目问「订单支付成功后要通知三个下游，且下游可独立重试」，答案在服务总线主题；问「VM 创建完成后触发一个函数」，答案在事件网格。

// 用 SessionId 把同一订单的消息绑到同一个消费者，保证会话内按序处理 // MessageId 配合重复检测窗口做幂等，防止重试产生重复扣款 await using ServiceBusSender sender = client.CreateSender("orders"); var message = new ServiceBusMessage(BinaryData.FromString(payload)) { SessionId = orderId, MessageId = orderId }; await sender.SendMessageAsync(message);

会话有序和重复检测都要在队列上先开启，代码里设了但队列没开，行为等于没设。死信队列不是异常，是设计的一部分：消费端连续失败到达投递上限后消息会进死信，巡检死信队列长度比巡检普通队列更能提前发现线上问题。

4.4 可观测：采样率是排查时的第一现场

Application Insights 的题喜欢问「日志为什么少了」。默认开启的自适应采样会在流量高时按比例丢弃遥测，目的是控成本，代价是排查时以为请求没到。所以看到「部分请求在日志里查不到」先看采样率与采样项，再看代码。

// 按操作名聚合近 1 小时的失败量与 P95 耗时，快速定位是哪个接口在拖 requests | where timestamp > ago(1h) | summarize total = count(), failed = countif(success == false), p95 = percentile(duration, 95) by name | where failed > 0 | order by failed desc

countif(success == false)统计失败次数，percentile(duration, 95)看长尾而不是平均值——平均值会把偶发的超时抹平。埋点侧还有一条常考区别：新项目用连接字符串而不是埋点密钥，后者是旧格式；分布式追踪靠的是同一个操作 ID 贯穿服务边界，手动埋点时如果没把父级上下文传下去，跨服务的调用链就会断成两截，看起来像两个独立请求。

5. 易错点：五个最容易被绕进去的地方

刷完一圈题会发现，错题很少错在「不知道」，大多错在「知道但用错了层」。下面这五条按「易漏点 → 为什么漏 → 怎么补」写，都是社区讨论里反复出现的。

5.1 命令与工具类的坑

把命令归属当成命令能力。易漏点：看到kubectl apply -f就怀疑「Azure CLI 里有 kubectl 吗」，于是把「能达成目标」判成「不能」。为什么漏：平时确实要先az aks install-cli才有 kubectl，把环境准备和方案判断混成了一件事。怎么补：判断顺序固定成两步，先看命令语义对不对（apply 就是应用清单），再看题干有没有明确说「未安装任何工具」「只装了 Azure CLI 且不允许再装」。题干没说，就按工具齐备算。

忘记密钥库的模板部署开关。易漏点：建了 Key Vault、存了机密、配了访问策略，就以为引用能生效，漏掉enabledForTemplateDeployment。为什么漏：这个开关在门户里不在显眼位置，文档里也只在参数说明中提一句。怎么补：把这套流程当固定动作背——建库、存密、开模板部署访问、配授权、模板写 reference，五步缺一不可。

5.2 配置与计费类的坑

重新部署、调整大小、移动、捕获四件事混着答。易漏点：题干说「挪到另一台宿主」，选项里有「移动到其他订阅」，看着都是「移」，就选了后者。为什么漏：中文里「移动」和「迁移」是同一个词，但资源层面的 Move 换的是管理边界，不动物理宿主。怎么补：只认两个关键词，「保留配置换节点」对应重新部署，「换资源组或订阅」对应移动，两者互斥。

部署槽设置和普通设置搞反。易漏点：交换之后发现生产的连接串变成了 staging 的。为什么漏：门户里两种设置在同一个页面，只有一个勾选框的区别。怎么补：建一个判断习惯——这个值在两个槽之间「应该不同吗」，应该不同就是槽设置，命令行加--slot-settings。

存储分层忽略最小存储期。易漏点：算成本时只比存储单价，得出「全部挪到存档层最省」。为什么漏：提前删除和提前移层的补齐费用不在单价表里。怎么补：把 30 / 90 / 180 三个天数写进规则注释，删改规则前先看数据的实际访问曲线，别让规则跑在真实访问模式前面。

6. 复习清单：把地图变成一周能过一遍的动作

到这一步，知识点已经是散的，需要一份能照着执行、又能快速自检的清单。我自己的做法是「三遍过」：第一遍只看模块边界，第二遍只做错题归因，第三遍只默写命令和参数。

第一遍用一张表定位薄弱模块，每格问自己一句话就能判断有没有底：

第二遍专攻错题，但不要重做，而是给每道错题贴一个标签：是「概念没建立」「动作作用域搞错」还是「题干限定词读漏」。三类错题的补法完全不同，概念没建立就回去补那一节的定义，作用域搞错就把那一组动作列成对照表，限定词读漏就养成先圈限定词再读选项的习惯。贴完标签你会发现错题集中在两三个格子里，这时候集中火力比均匀复习快得多。

第三遍是默写。命令和参数这一层骗不了人，能写出来才算记住：

# 重新部署：换节点保留配置 az vm redeploy -g rg-demo -n vm1 # 拉取 AKS 凭据后再应用清单 az aks get-credentials -g rg-demo -n aks-demo kubectl apply -f myapp.yaml # 打开密钥库的模板部署访问 az keyvault update -n kv-demo -g rg-demo --enabled-for-template-deployment true # 把连接串写成槽设置，交换时不跟着走 az webapp config appsettings set -g rg-demo -n app-demo \ --slot staging --slot-settings ConnectionStrings__Default=...

默写时给每条命令加一句中文注释，注释写不出来，说明这条命令只是眼熟。这个方法比反复看解析有效，因为考试里真正会卡住人的不是选项，是你根本不知道那条命令在干什么。

最后补一个查漏的动作：把题库里同一 Topic 的题按上面的模块重新分一次组，你会发现有很多题其实在考同一条判据，比如「保留配置换节点」出现了不止一次，「不以明文存储」也换了三四种问法。按判据归类之后，需要背的东西会从几百道题压缩成几十条判断规则，剩下的就是熟练度问题。

从那以后我每次开始刷题前，都会先把第 5 章那五条易错点默读一遍再动手，正确率的波动明显小了——不是题变简单了，是读完题干就知道该往哪条判据上靠。希望帮到你。

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