拓冰网站定制 
简介AZ-104备考题库对应微软MCP认证体系中Azure解决方案专家方向专为准备参加Azure管理员认证考试的IT从业者设计尤其适合云运维与架构人员快速验证知识掌握程度。PDF内含经过专家验证的在线题目支持自定义视图设置并附带社区投票分布可快速了解各选项的支持率与易错点。内容紧密围绕Azure资源管理实战覆盖虚拟机标签分组、Azure AD条件访问策略等高频考点例如通过为虚拟机分配标签关联部门而不是调整资源组或管理组还考察了从不受信任位置连接时如何为全局管理员配置多因素认证与Azure AD加入设备要求。整个压缩包为单个PDF文件约45.55MB便于按章节刷题与打印目前已有120人学习使用适合需要结合真题进行考前自测、查漏补缺的Azure认证备考生。1. 刷完这份 AZ-104 题库我先把标签、条件访问和 ARM 模板这三块彻底弄懂了拿到这份 AZ-104 题库 PDF 的时候我本来以为又是一堆复制粘贴的旧题翻了一遍发现里面全是 Azure 管理员日常最容易模棱两可的操作点。比如说怎么按部门归拢一堆 VM很多人第一反应是建资源组或者管理组但正确答案其实是打标签再比如条件访问策略不是你在 MFA 页面改改用户设置就能满足“全局管理员从不受信任位置必须 MFA Azure AD Joined 设备”这种要求的。这些题目背后全是 Azure 资源管理、身份治理和 ARM 部署的实际逻辑考的不只是记忆而是你平时干活有没有踩过这些坑。这份题库适合两类人一类是准备 AZ-104 认证考试的另一类是已经在用 Azure 但想系统补一遍运维短板的。接下来我把每个知识点的原理、选型理由和坑都拆开讲。2. 用标签而不是资源组区分 VM为什么多数人会选错2.1 管理组、资源组和标签的分工边界题目背景是一家公司有多个部门每个部门一批 VM全部塞在同一个叫 RG1 的资源组里现在要按部门把 VM 关联起来。A 选项说给每个部门建 Azure Management GroupsB 选项说给每个部门建资源组D 选项说改 VM 的设置C 选项才是给 VM 打标签。先说管理组。Azure Management Groups 是用来做订阅层级治理的管理组下面挂的是订阅不是 VM 这种具体资源。如果一个部门需要独立的订阅范围、独立的策略继承和独立的权限边界才考虑管理组。部门再多只要大家共用同一个订阅管理组就派不上用场。这里题目明确说了公司只有一个订阅RG1 里放着所有 VM所以 A 直接排除。再来说资源组。把每个部门单独建一个资源组然后把 VM 迁过去这种方式从管理上看是可行的但题目问的是“关联 VM 与其部门”而不是“重构资源归属”。资源组是资源的容器一个 VM 只能属于一个资源组如果一台 VM 同时要被业务线、项目、环境、成本中心多个维度区分资源组根本不够用。而且把全部 VM 迁到新资源组涉及停机窗口和依赖关系调整为了一个纯标识需求去动资源组成本太高。典型的做法是当你想按部门隔离权限、独立管理生命周期时才拆资源组只是想打标记做筛选、做成本分摊就用标签。标签是 Azure Resource Manager 层面的键值对挂在资源上不影响资源组归属不造成停机也不需要迁移。你可以同时给一台 VM 打上 DepartmentFinance、EnvironmentProduction、CostCenterCC-102 三组标签然后通过成本分析按标签维度做部门费用拆分。这正是这道题最想考的标签是资源分类和关联的最佳工具。2.2 标签的实际操作与查询方式给 VM 打标签门户上直接在 VM 的“Tags”边栏添加键值对就行批量操作则建议用 PowerShell 或 CLI。以下是 PowerShell 批量给多台 VM 打标签的脚本$resourceGroup RG1 $tagName Department $tagValue Finance $vms Get-AzVM -ResourceGroupName $resourceGroup foreach ($vm in $vms) { $tags $vm.Tags if (-not $tags) { $tags {} } $tags[$tagName] $tagValue Update-AzTag -ResourceId $vm.Id -Tag $tags -Operation Merge }这段脚本先通过 Get-AzVM 拿到 RG1 下全部 VM然后遍历读取每台 VM 现有的 Tags 哈希表。如果 VM 之前没有标签Tags 会是空的就初始化为一个空的哈希表再往里面添加 Department 键。Update-AzTag 的 -Operation Merge 表示合并而不是覆盖意思是只新增或修改你指定的键其他已有标签保留不变。这里有个参数细节值得注意Update-AzTag 是针对 ARM 标签操作的 cmdlet它的 -ResourceId 直接接收 VM 的资源 ID不需要你先做 Get-AzResource 转换。而 -Tag 传的是完整的哈希表如果某台 VM 原本有 Environment 标签你用 Merge 操作传进去的哈希表里没带 Environment这个标签依然会保留。如果你改用 -Operation Replace那就会把 VM 上所有旧标签清掉只留下你新传的这些。生产环境批量打标签我一般都用 MergeReplace 只在你确认要清理全部旧标签时才用。CLI 方式也可以完成同样的事az vm update --resource-group RG1 --name VM01 --set tags.DepartmentFinance这条命令直接在现有 tags 对象上设置 Department 键等价于 Merge 语义。要注意的是 az vm update 的 --set 语法如果 VM 原本没有 tags 对象这条命令会自动创建。但如果标签键名本身包含特殊字符比如连字符或点号--set tags.My-TagValue 这种写法需要额外转义。稳妥起见键名尽量只用字母、数字和下划线。2.3 标签策略与常见失败场景有些环境里管理员会开启“标签继承”策略把订阅或资源组的标签自动继承到新建资源上。这看起来方便但有个坑Azure Policy 的继承生效有延迟新建的 VM 可能过几分钟才带上继承标签自动化脚本如果刚创建完 VM 就立刻按标签筛选会漏掉这些资源。我一般会做一次 retry等 3 到 5 分钟再查。还有个更隐蔽的问题。如果公司启用了“Require a tag on resources”策略而不是“Add or replace a tag on resources”那么创建 VM 时如果没传标签整个部署会被策略直接拒绝。这时候你看到的报错不是“缺少标签”这么直白而是一条 resource policy 违规的 403 错误开头通常是 “The resource VM01 was disallowed by policy”。解决方式是在部署模板的 parameters 里添加符合策略的默认标签而不是去跟策略硬扛。标签值的规范化也是个常见议题。建议建立一套标签命名规范比如 Environment 只允许 Production、Staging、Development 三选一CostCenter 用固定编号格式。这个可以用 Azure Policy 的 allowedValues 约束超出范围的取值直接拒绝。没有规范的时候FinOps 团队做成本分析会非常痛苦同一个部门今天叫 Finance明天叫 Finance-APAC成本报表就全乱了。3. 条件访问策略MFA 与 Azure AD Join 设备是组合拳不是单选题3.1 三个相似题目的差异点在哪里这份题库里连续有三道题题干完全一样要求全局管理员从不受信任位置连接 Azure AD 时必须使用 MFA 并且必须使用 Azure AD Join 设备登录。三道题分别给了三个不同的方案改 MFA 用户设置、改会话控制、改授予控制。答案是 B、B、A。先说第一道为什么错。解决方案写的是“访问多因素认证页面来修改用户设置”这说的是 MFA 的 per-user 设置页面也就是针对用户逐个配置 MFA 状态的地方它跟条件访问完全是两套体系。Per-user MFA 是静态的要么开启、要么关闭、要么强制它不感知位置不知道用户是从公司 IP 还是从咖啡店连进来的。条件访问策略则是在用户试图访问应用或登录时由 Azure AD 的策略引擎根据信号实时评估。信号包括位置、设备合规状态、风险等级、应用敏感度评估之后才决定允许访问还是要求额外验证。题干明确要求“来自不受信任位置”时附加条件per-user MFA 做不到这件事所以 B。再说第二道。修改会话控制指的是在条件访问策略里调整“Use app enforced restrictions”这类会话级别的控制项它管的是用户进去之后能做什么比如限制下载、阻止打印它不管用户进之前有没有做过 MFA、设备是不是合规。把 MFA 要求写在会话控制里概念上就不对。会话控制解决的是访问后的行为约束授予控制解决的才是访问前要满足的身份验证和合规条件两者不是一回事。第三道考的是正确定位。修改授予控制就是条件访问策略里的 Grant 部分把“Require multi-factor authentication”和“Require Azure AD joined device”勾选上这就是让用户从不受信任位置访问时先过身份验证和设备校验。答 Yes 是对的。这三道题的价值在于让你分清条件访问的三个层面谁触发条件、允不允许进授予控制、进了能干什么会话控制。很多人第一次接触条件访问会在策略配置界面里找不到 MFA 选项原因是 Azure AD 的“条件访问”边栏入口路径比较深Azure Active Directory → Security → Conditional Access → New policy。新建策略时先配置 Assignments 里的 Users and groups 和 Conditions再到 Access controls 里的 Grant 勾选需要满足的控制项。3.2 一个条件访问策略的最小配置下面用一个具体的最小策略来演示针对 Global Administrators 组来自不受信任位置时要求 MFA 和 Azure AD Joined 设备。# 先创建命名位置把公司办公网段定义为可信位置 az rest --method put \ --uri https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations \ --headers Content-Typeapplication/json \ --body { displayName: Corp-Office, ipRanges: [ {cidrAddress: 203.0.113.0/24} ], isTrusted: true, odata.type: #microsoft.graph.ipNamedLocation }创建命名位置这一步经常被忽视。条件访问要判断“不受信任位置”前提是你先定义了哪些位置是受信任的。上面这段创建的是基于 IP 范围的命名位置把 203.0.113.0/24 定义为可信办公网段isTrusted 设为 true。只有把公司出口网段配置进去了策略引擎才知道流量是来自可信位置其他所有 IP 默认都算不受信任。接下来创建条件访问策略本体az rest --method post \ --uri https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies \ --headers Content-Typeapplication/json \ --body { displayName: Require MFAJoin for GlobalAdmins from untrusted locations, state: enabled, conditions: { users: { includeUsers: [], includeRoles: [Global Administrator], excludeUsers: [] }, applications: { includeApplications: [All] }, locations: { includeLocations: [All], excludeLocations: [Corp-Office] } }, grantControls: { operator: AND, builtInControls: [mfa, domainJoinedDevice] } }这段配置里最关键的是 conditions.locations 部分。includeLocations 设为 All表示所有位置都纳入策略范围但 excludeLocations 里排除了刚创建的 Corp-Office 命名位置效果就是“除办公室外所有位置都触发策略”。users 部分用 includeRoles 而不是 includeUsers因为策略要求的是针对全局管理员这个角色而不是单独几个用户账号。这样以后新增的全局管理员也会自动落进策略范围不需要手动维护用户列表。grantControls 里 operator 为 AND意味着用户必须同时满足 mfa 和 domainJoinedDevice 两个条件才能访问。如果这里写成 OR那就变成“要么 MFA、要么设备加入”安全语义完全变了。有一类经典错误就是为了省事把条件放宽成 OR结果用户在外面用自己的个人电脑照样进得去只要他做了 MFA 就行设备是不是企业管理的就无所谓了。这跟需求里“必须使用 Azure AD Join 设备”是冲突的。还有一个要注意的细节策略里的域设备控制项在英文界面里叫 “Require Azure AD joined device”不是 “Require compliant device”也不是 “Require Hybrid Azure AD joined device”。这三个选项在文档里经常被混淆。Require Azure AD joined device 要求设备已经注册到 Azure ADRequire compliant device 要求设备通过 Intune 或 MDM 的策略合规检查意味着设备不仅要加入还得满足全盘加密、系统补丁等条件Hybrid Azure AD joined 则针对本地 AD 加域设备。按题干的字面要求“Azure AD-joined device”就是第一个选项别选成另外两个。3.3 MFA 使用模型切换的隐藏限制题库里还有一组关于 MFA 使用模型的题当前配置的是 Per Authentication 模式收购了一家公司后新员工也要开启 MFA需求是改成 Per Enabled User 模式。方案一改现有 provider 的模型方案二用 Azure CLI 改方案三创建新的 provider 并备份旧数据答案分别是 B、B、A。这里面的硬知识是MFA Provider 的 usage model 一旦创建就不能改。Per Authentication 按认证次数计费Per Enabled User 按启用的用户数计费两种计费模型在底层就不是同一套逻辑Azure 不提供原地切换的功能。要想换模型只能新建一个对应模型的 Provider然后用新 Provider 的激活凭证重新激活 MFA Server。这个操作意味着你要重新配置连接期间相关用户可能短暂无法使用 MFA 服务生产环境需要安排维护窗口。用 Azure CLI 改也一样做不到因为 REST API 层就不存在修改 usage model 的接口。你调 PATCH 接口去更新 provider 的 properties返回的要么是 400 要么是 405。这个坑在真实工作中很常见有些运维同学接手了一个已经跑了一年的 MFA 环境想从按认证次数改成按用户数查了半天文档才发现根本改不了最后只能新开 Provider 做迁移。4. DirSync 与 Azure AD Connect 手动同步立即生效的命令和无效操作4.1 为什么 Active Directory 站点复制不能触发 Azure AD 同步题目场景是一家公司配置了混合环境本地 AD 与 Azure AD 通过 DirSync 服务器同步。管理员在本地 AD 中新建了一个用户现在要立刻把用户信息复制到 Azure AD。三个方案分别是运行 Start-ADSyncSyncCycle 强制同步、用 AD 站点和服务强制复制全局编录到域控、重启域控的 NetLogon 服务。答案是 A、B、B。首先理清 DateiSync 的机制。本地 AD 和 Azure AD 之间没有实时的双向复制通道只有 Azure AD ConnectDirSync 是它的旧称按照默认每 30 分钟一次的调度周期把增量变更同步到 Azure AD。AD 站点和服务里强制复制全局编录影响的是本地域控制器之间的复制它解决的是“这台 DC 上新建的用户有没有同步到另一台 DC”的问题而 Azure AD Connect 同步的是本地 AD 整个目录里已经存在的对象。换句话说不管本地复制多快Azure AD Connect 调度器不动Azure AD 侧就收不到新用户。重启 NetLogon 服务更离谱NetLogon 管的是域成员认证和安全通道跟目录同步没有直接关系。没有 NetLogon 服务域控之间的通信都要出问题更不可能触发 Azure AD 同步。这两个错误选项在考试里属于“用本地 AD 思维解决云端同步问题”的典型陷阱。4.2 强制同步的 PowerShell 命令与参数选择正确答案是运行 PowerShell cmdletImport-Module ADSync Start-ADSyncSyncCycle -PolicyType Initial这段命令里的 ADSync 模块是 Azure AD Connect 服务器上自带的只能在装有 Azure AD Connect 的那台服务器上运行不能在普通工作站上装这个模块然后远程调用。所以前提条件是管理员先通过 RDP 或者本地控制台登录到 Azure AD Connect 服务器上用管理员身份打开 PowerShell 窗口再执行 Import-Module 和 Start-ADSyncSyncCycle。-PolicyType 参数有两个可选值Initial 和 Delta。Initial 会做一次完整同步遍历全部目录对象耗时较长适合首次部署或者对象数量出现异常偏差的时候使用。Delta 只同步上次同步之后发生的变更速度快日常强制同步用 Delta 就够了。题目里说“立刻复制新建的用户”Delta 就足够但给出的命令是 Initial这也不影响正确性因为 Initial 包含 Delta 的所有工作全量同步肯定能带上新用户。如果只想要最快速度用Start-ADSyncSyncCycle -PolicyType Delta更合适。还有一种方式是调度器层面的Set-ADSyncScheduler -SyncCycleEnabled $true Start-ADSyncSyncCycle第一句确保调度器没有被暂停有些运维同学为了防止同步故障排查期间再次出问题会把调度器暂停掉然后忘记恢复导致新建用户迟迟不出现。第二句直接触发一次同步周期不指定 PolicyType 时默认按 Delta 执行。4.3 同步失败时怎么定位问题实际环境中强制同步跑完一批新用户只同步了部分到 Azure AD是比较常见的问题。最常见原因有三个一是安全管理器跳过了某些 OUAzure AD Connect 的域和 OU 过滤配置里有一份排除清单新建用户在排除的 OU 里同步自然不执行。确认方式是打开 Synchronization Service Manager切到 “Metaverse Search” 界面搜索该用户如果搜索不到说明本地 AD Connector 空间里就没被过滤进来。二是过滤规则冲突新用户的某个属性同时匹配了两条不同的同步规则一条映射到 Azure AD一条标记为无效地址结果用户对象直接进了一堆 provisioning 错误。三是邮箱属性和本地域不匹配导致软匹配失败DirSync 在 Azure AD 里找不到可以匹配的现有对象也不会创建新对象。排查同步错误的标准路径是先看 Windows 事件日志里 ADSync 来源的警告和错误再去 Synchronization Service Manager 里看 “Connectors” 面板中的 “Import” 和 “Export” 状态。如果 Export 阶段报 “directory synchronization” 错误通常要打开报错的目录对象详情里面会给出具体是哪个属性冲突。5. 存储冗余选型、ARM 模板回溯和可用性集扩容三道题的三个坑5.1 RA-GRS 与 GRS、ZRS、LRS 的边界题目要求两个数据中心配置为地理集群站点实现站点级恢复能力。需求有三条数据必须存储在多个节点上、数据必须存储在多个地理位置、既然后台地理复制好了还要能直接从次要位置读取数据。四个选项是 GRS、RA-GRS、ZRS、LRS正确答案是 RA-GRS。要理解为什么不是 GRS得先搞清楚 GRS 和 RA-GRS 的差别。GRS异地冗余存储会把数据从主区域复制到配对的次要区域数据确实存在两个地理位置但次要区域的数据是不可读的。如果主区域发生故障在故障转移完成之前你只能等微软完成重定向期间的读写都不可用。RA-GRS 在 GRS 基础上额外提供了读访问权你随时可以用特制的端点直接读取次要区域的数据这意味着即使主区域挂了应用还能切换到次区域做只读业务部分避免全站停服的风险。ZRS区域冗余存储把数据复制到同一区域内的多个可用区节点分布是不同的物理机房但三个可用区都在同一个地理区域里。洛杉矶和纽约这种跨地理位置的需求 ZRS 根本满足不了它的冗余边界只是同一个区域内的故障域。LRS本地冗余存储更不用说了同一数据中心内的同一机架里维持多个副本虽然能解决磁盘损坏级别的故障但整个机柜或整个机房一挂数据就完蛋。选型的判断逻辑应该是单区域内抗硬件故障选 LRS单区域内抗机房级故障选 ZRS跨地域容灾选 GRS跨地域容灾还想读次区域数据选 RA-GRS。还有一种参数叫 GZRS/RA-GZRSZRS 加跨区域复制的组合2022 年以后才主推如果考试里遇到它按同等级别的增强选项理解即可。5.2 从 Portal 和 CLI 回溯 ARM 模板的正确路径另一组题是同事用一个 ARM 模板部署了虚拟机和一个存储账号让你找到他用的模板。三个方案分别是从虚拟机关联的边栏、从容器边栏、从资源组分页里的部署记录查看答案是 B、B、A。ARM 模板的部署历史是挂在资源组下面的。每次执行模板部署无论你是用 Portal 的“部署自定义模板”功能、PowerShell 的 New-AzResourceGroupDeployment 还是 CLI 的 az deployment group create都会在资源组的 Architecture → Deployments 列表里留下一条记录点进去之后可以查看参数输入、操作输出以及整个模板的原始 JSON。虚拟机和存储账号边栏里没有这种部署历史功能因为一个资源可能是多个模板叠加的结果也可能是直接通过门户手动构建的没有部署记录不代表资源不能正常使用。Portal 的路径是进入资源组 → 左侧菜单选 “部署Deployments” → 找到对应部署记录 → 点击查看说明和“模板”选项卡。如果需要把模板直接导出成参数化的 ARM 文件资源组边栏的 “Automation → Export template” 也能做到但它导出的是这个资源组当前所有资源的完整状态不是某一次部署的明细。这两者要区分Deployments 里看的是历史部署Export template 里看的是当前资源快照。CLI 下查看部署历史az deployment group show \ --resource-group RG1 \ --name myVMTemplateDeployment \ --query properties.template \ --output json这条命令把指定名称的部署记录里的模板 JSON 直接导出来。--name 参数对应部署操作的名称不是你虚拟机的名字。如果你不知道部署名称先用az deployment group list --resource-group RG1 --output table列出所有部署记录看清楚 name 列再回填。很多同学在这一步会把 VM 的资源名称当成部署名称传进去然后报错找不到部署记录这就是没搞清楚层级关系。5.3 可用性集内 VM 扩容必须全停还是停一台最后一组场景题是可用性集里有三台 VM其中一台要扩容报错原因是 allocation failure问应该怎么办。答案是停止所有三台 VM 再扩容。这个问题的底层原因在于可用性集约束了 VM 的物理分布位置。可用性集里的 VM 会分布在不同的容错域和更新域中Fault Domain 对应物理机架和电源Update Domain 对应同时重启的粒度。当你要给其中一台 VM 扩到一个需要不同物理硬件形态的 VM Size 时比如从 D 系列升到 E 系列Azure 需要找到一台同时满足以下条件的宿主机能提供目标 VM Size 的规格、还有剩余的容量、并且和可用性集里其他 VM 服务器的硬件类型兼容。如果其他 VM 还在运行Azure 会优先把新 VM 放在与它们相同的物理集群上否则就打破了故障域的约束条件。这个集群上没有足够的资源就会报 allocation failure。把所有 VM 停掉之后虚拟机已经不再占用集群资源Azure 调度器可以重新选择任意一个满足新规格和可用性集约束的集群来放置整个可用性集。所以这个操作本质上是“释放旧的硬件约束重新调度整组虚拟机”。真实场景中的建议是先确认新 VM Size 是否与可用性集里其他 VM 的当前 Size 属于同一代际和同一硬件系列。如果是同代际的小幅升级比如从 Standard_D2s_v3 升到 Standard_D4s_v3只要当前集群资源充足不停机也能直接改只有当跨系列或者目标 Size 的资源耗尽时才需要全停。另一个做法是把虚拟机从可用性集里移出来再扩容但这会破坏可用性集的故障域保护生产环境不建议这么干除非你有把握通过独立 VM 或 Virtual Machine Scale Sets 重新建立容错能力。6. 避坑指南这份题库里反复出现的四类模糊陷阱6.1 混淆 Azure AD 身份管理和 Azure AD 条件访问最常见的一道错题是公司需要全局管理员从不受信任位置使用 MFA 登录方案直接去 MFA 页面改用户状态。现象题目答案选 Yes错误理解 MFA 为“只管开关”。原因MFA 页面上的 per-user MFA 开关不感知位置也没法和设备加入状态联动。解决条件访问策略必须在 Azure Active Directory → Security → Conditional Access 里配置把位置和 MFA 控制绑定在同一个策略中。从那以后我做任何 MFA 需求都会先问一句“这个策略的评估信号是什么”而不是直接开开关。6.2 拿本地 AD 逻辑猜同步行为现象在本地 AD 建了新用户用 AD Sites and Services 强制复制之后发现 Azure AD 里依然没有该用户。原因AD 站点复制和 Azure AD Connect 同步是两套完全独立的管线前者影响本地 DC 之间的数据一致性后者独立拉取目录变更。解决登录 Azure AD Connect 服务器执行Start-ADSyncSyncCycle -PolicyType Delta。如果用户还是不出来检查 Synchronization Service Manager 里是否有域/OU 过滤规则把用户所在的容器给排除了。注意你无法从本地普通 Windows 工作站连接 Azure AD Connect必须直接登录那台服务器才能运行 ADSync 模块命令。6.3 把部署历史和管理视图混为一谈现象同事用 ARM 模板部署了 VM 和存储账号你想看原始模板进了 VM 的边栏翻来翻去找不到。原因VM 资源配置页只展示资源本身属性不会存储部署时的模板。解决去资源组的 Deployments 列表找部署记录或使用 CLI 的az deployment group show --query properties.template直接拉取模板 JSON。如果你需要的是当前资源组的可部署模板而不是历史部署时的快照用资源组的 Export template 功能导出结果为当前状态注意两者存在差异。6.4 可用性集扩容不停机直接改现象在可用性集中某一台 VM 上调大 SizeAzure 提示 allocation failure扩容没办法继续。原因可用性集要求所有 VM 驻留在同一物理集群目标 Size 在当前集群上没有容量。解决将可用性集中所有 VM 停止再执行扩容扩容完成后重新启动全部 VM。如果业务不允许全部停止可以考虑创建新的可用性集来接纳这台扩容后的 VM并将它从原可用性集移除前提是应用侧设计了跨可用性集的容错逻辑。如果遇到“停止所有 VM 后依然报错”检查是否用的是 Spot VM 或 Azure Reserved Instance预留实例的容量与 VM 型号绑定型号不匹配时会限制你的调配。7. 题库的高阶用法用社区投票分布反推争议题的出题意图把这份题库当“背题资料”用是浪费它真正值钱的地方在每道题附带的 Community vote distribution。这个投票分布直接暴露了一道题是有共识还是存在争议。比如某题的投票是 B93%7%说明这道题在考生群体中有一致答案大概率对应一个官方文档里写得明确的机制点刷题时只要把那个机制点理解透就行。如果投票分布呈四六开或者五五开情况就完全不同意味着这道题本身存在文字歧义或者考试界的理解有分化这种题恰恰是出题人最爱设坑的地方。以第二到第四题为例三题题干一样但答案不同这种排列在真实考试中也常见。考试时你看到的题序可能是乱序的三题的答案也不一定按 A、B、B 排。如果你只是背了答案而没理解解法逻辑换一种答案分布就很容易翻车。正确做法是遇到重复题干的题目横向对比各题的“Solution”部分的差异尤其是关键动词比如“alter grant control”和“alter session control”这两处的区别决定了整个答案走向。我刷题时会单独建一个 Excel把题干相同而解法不同的题放在同一行解法差异写在备注列用这个方式强制自己区分概念边界。题库里的 Reference 链接也值得单独处理。每道题下面挂的微软官方文档地址是很多题目的直接出处比如条件访问策略、存储冗余、ARM 模板导出页面。我习惯把链接按主题分类整理到自己的知识库刷题遇到不确定的选项时先回官方文档确认再回来看题库解析。官方文档的优点是描述精确缺点是不讲场景题库正好补上了场景化部分两者的配合效果远好于只刷任一一种。验证自己是否真正掌握这些知识点的方法不是把题库从头到尾过一遍而是把每道题的“错误选项”改成“正确操作”然后想清楚为什么原来的做法是错的。比如 MFA 那道题错误项是“去 MFA 页面改用户设置”你如果能说清楚“per-user MFA 停止工作、条件访问策略还依赖它、失败时怎么排查”那你就真正理解了。说不上来也没关系回到对应章节的原文再走一遍实操命令然后用自己的话写一段操作笔记。从那以后我每次刷这类题库都会强制走一遍“正确答案 → 官方文档 → 身边云环境验证”的流程确实能避掉那些背答案带来的知识盲区希望帮到你。本文还有配套的精品资源点击获取 AZ-104题库精讲：标签、条件访问与ARM模板的实战避坑指南
简介AZ-104备考题库对应微软MCP认证体系中Azure解决方案专家方向专为准备参加Azure管理员认证考试的IT从业者设计尤其适合云运维与架构人员快速验证知识掌握程度。PDF内含经过专家验证的在线题目支持自定义视图设置并附带社区投票分布可快速了解各选项的支持率与易错点。内容紧密围绕Azure资源管理实战覆盖虚拟机标签分组、Azure AD条件访问策略等高频考点例如通过为虚拟机分配标签关联部门而不是调整资源组或管理组还考察了从不受信任位置连接时如何为全局管理员配置多因素认证与Azure AD加入设备要求。整个压缩包为单个PDF文件约45.55MB便于按章节刷题与打印目前已有120人学习使用适合需要结合真题进行考前自测、查漏补缺的Azure认证备考生。1. 刷完这份 AZ-104 题库我先把标签、条件访问和 ARM 模板这三块彻底弄懂了拿到这份 AZ-104 题库 PDF 的时候我本来以为又是一堆复制粘贴的旧题翻了一遍发现里面全是 Azure 管理员日常最容易模棱两可的操作点。比如说怎么按部门归拢一堆 VM很多人第一反应是建资源组或者管理组但正确答案其实是打标签再比如条件访问策略不是你在 MFA 页面改改用户设置就能满足“全局管理员从不受信任位置必须 MFA Azure AD Joined 设备”这种要求的。这些题目背后全是 Azure 资源管理、身份治理和 ARM 部署的实际逻辑考的不只是记忆而是你平时干活有没有踩过这些坑。这份题库适合两类人一类是准备 AZ-104 认证考试的另一类是已经在用 Azure 但想系统补一遍运维短板的。接下来我把每个知识点的原理、选型理由和坑都拆开讲。2. 用标签而不是资源组区分 VM为什么多数人会选错2.1 管理组、资源组和标签的分工边界题目背景是一家公司有多个部门每个部门一批 VM全部塞在同一个叫 RG1 的资源组里现在要按部门把 VM 关联起来。A 选项说给每个部门建 Azure Management GroupsB 选项说给每个部门建资源组D 选项说改 VM 的设置C 选项才是给 VM 打标签。先说管理组。Azure Management Groups 是用来做订阅层级治理的管理组下面挂的是订阅不是 VM 这种具体资源。如果一个部门需要独立的订阅范围、独立的策略继承和独立的权限边界才考虑管理组。部门再多只要大家共用同一个订阅管理组就派不上用场。这里题目明确说了公司只有一个订阅RG1 里放着所有 VM所以 A 直接排除。再来说资源组。把每个部门单独建一个资源组然后把 VM 迁过去这种方式从管理上看是可行的但题目问的是“关联 VM 与其部门”而不是“重构资源归属”。资源组是资源的容器一个 VM 只能属于一个资源组如果一台 VM 同时要被业务线、项目、环境、成本中心多个维度区分资源组根本不够用。而且把全部 VM 迁到新资源组涉及停机窗口和依赖关系调整为了一个纯标识需求去动资源组成本太高。典型的做法是当你想按部门隔离权限、独立管理生命周期时才拆资源组只是想打标记做筛选、做成本分摊就用标签。标签是 Azure Resource Manager 层面的键值对挂在资源上不影响资源组归属不造成停机也不需要迁移。你可以同时给一台 VM 打上 DepartmentFinance、EnvironmentProduction、CostCenterCC-102 三组标签然后通过成本分析按标签维度做部门费用拆分。这正是这道题最想考的标签是资源分类和关联的最佳工具。2.2 标签的实际操作与查询方式给 VM 打标签门户上直接在 VM 的“Tags”边栏添加键值对就行批量操作则建议用 PowerShell 或 CLI。以下是 PowerShell 批量给多台 VM 打标签的脚本$resourceGroup RG1 $tagName Department $tagValue Finance $vms Get-AzVM -ResourceGroupName $resourceGroup foreach ($vm in $vms) { $tags $vm.Tags if (-not $tags) { $tags {} } $tags[$tagName] $tagValue Update-AzTag -ResourceId $vm.Id -Tag $tags -Operation Merge }这段脚本先通过 Get-AzVM 拿到 RG1 下全部 VM然后遍历读取每台 VM 现有的 Tags 哈希表。如果 VM 之前没有标签Tags 会是空的就初始化为一个空的哈希表再往里面添加 Department 键。Update-AzTag 的 -Operation Merge 表示合并而不是覆盖意思是只新增或修改你指定的键其他已有标签保留不变。这里有个参数细节值得注意Update-AzTag 是针对 ARM 标签操作的 cmdlet它的 -ResourceId 直接接收 VM 的资源 ID不需要你先做 Get-AzResource 转换。而 -Tag 传的是完整的哈希表如果某台 VM 原本有 Environment 标签你用 Merge 操作传进去的哈希表里没带 Environment这个标签依然会保留。如果你改用 -Operation Replace那就会把 VM 上所有旧标签清掉只留下你新传的这些。生产环境批量打标签我一般都用 MergeReplace 只在你确认要清理全部旧标签时才用。CLI 方式也可以完成同样的事az vm update --resource-group RG1 --name VM01 --set tags.DepartmentFinance这条命令直接在现有 tags 对象上设置 Department 键等价于 Merge 语义。要注意的是 az vm update 的 --set 语法如果 VM 原本没有 tags 对象这条命令会自动创建。但如果标签键名本身包含特殊字符比如连字符或点号--set tags.My-TagValue 这种写法需要额外转义。稳妥起见键名尽量只用字母、数字和下划线。2.3 标签策略与常见失败场景有些环境里管理员会开启“标签继承”策略把订阅或资源组的标签自动继承到新建资源上。这看起来方便但有个坑Azure Policy 的继承生效有延迟新建的 VM 可能过几分钟才带上继承标签自动化脚本如果刚创建完 VM 就立刻按标签筛选会漏掉这些资源。我一般会做一次 retry等 3 到 5 分钟再查。还有个更隐蔽的问题。如果公司启用了“Require a tag on resources”策略而不是“Add or replace a tag on resources”那么创建 VM 时如果没传标签整个部署会被策略直接拒绝。这时候你看到的报错不是“缺少标签”这么直白而是一条 resource policy 违规的 403 错误开头通常是 “The resource VM01 was disallowed by policy”。解决方式是在部署模板的 parameters 里添加符合策略的默认标签而不是去跟策略硬扛。标签值的规范化也是个常见议题。建议建立一套标签命名规范比如 Environment 只允许 Production、Staging、Development 三选一CostCenter 用固定编号格式。这个可以用 Azure Policy 的 allowedValues 约束超出范围的取值直接拒绝。没有规范的时候FinOps 团队做成本分析会非常痛苦同一个部门今天叫 Finance明天叫 Finance-APAC成本报表就全乱了。3. 条件访问策略MFA 与 Azure AD Join 设备是组合拳不是单选题3.1 三个相似题目的差异点在哪里这份题库里连续有三道题题干完全一样要求全局管理员从不受信任位置连接 Azure AD 时必须使用 MFA 并且必须使用 Azure AD Join 设备登录。三道题分别给了三个不同的方案改 MFA 用户设置、改会话控制、改授予控制。答案是 B、B、A。先说第一道为什么错。解决方案写的是“访问多因素认证页面来修改用户设置”这说的是 MFA 的 per-user 设置页面也就是针对用户逐个配置 MFA 状态的地方它跟条件访问完全是两套体系。Per-user MFA 是静态的要么开启、要么关闭、要么强制它不感知位置不知道用户是从公司 IP 还是从咖啡店连进来的。条件访问策略则是在用户试图访问应用或登录时由 Azure AD 的策略引擎根据信号实时评估。信号包括位置、设备合规状态、风险等级、应用敏感度评估之后才决定允许访问还是要求额外验证。题干明确要求“来自不受信任位置”时附加条件per-user MFA 做不到这件事所以 B。再说第二道。修改会话控制指的是在条件访问策略里调整“Use app enforced restrictions”这类会话级别的控制项它管的是用户进去之后能做什么比如限制下载、阻止打印它不管用户进之前有没有做过 MFA、设备是不是合规。把 MFA 要求写在会话控制里概念上就不对。会话控制解决的是访问后的行为约束授予控制解决的才是访问前要满足的身份验证和合规条件两者不是一回事。第三道考的是正确定位。修改授予控制就是条件访问策略里的 Grant 部分把“Require multi-factor authentication”和“Require Azure AD joined device”勾选上这就是让用户从不受信任位置访问时先过身份验证和设备校验。答 Yes 是对的。这三道题的价值在于让你分清条件访问的三个层面谁触发条件、允不允许进授予控制、进了能干什么会话控制。很多人第一次接触条件访问会在策略配置界面里找不到 MFA 选项原因是 Azure AD 的“条件访问”边栏入口路径比较深Azure Active Directory → Security → Conditional Access → New policy。新建策略时先配置 Assignments 里的 Users and groups 和 Conditions再到 Access controls 里的 Grant 勾选需要满足的控制项。3.2 一个条件访问策略的最小配置下面用一个具体的最小策略来演示针对 Global Administrators 组来自不受信任位置时要求 MFA 和 Azure AD Joined 设备。# 先创建命名位置把公司办公网段定义为可信位置 az rest --method put \ --uri https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations \ --headers Content-Typeapplication/json \ --body { displayName: Corp-Office, ipRanges: [ {cidrAddress: 203.0.113.0/24} ], isTrusted: true, odata.type: #microsoft.graph.ipNamedLocation }创建命名位置这一步经常被忽视。条件访问要判断“不受信任位置”前提是你先定义了哪些位置是受信任的。上面这段创建的是基于 IP 范围的命名位置把 203.0.113.0/24 定义为可信办公网段isTrusted 设为 true。只有把公司出口网段配置进去了策略引擎才知道流量是来自可信位置其他所有 IP 默认都算不受信任。接下来创建条件访问策略本体az rest --method post \ --uri https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies \ --headers Content-Typeapplication/json \ --body { displayName: Require MFAJoin for GlobalAdmins from untrusted locations, state: enabled, conditions: { users: { includeUsers: [], includeRoles: [Global Administrator], excludeUsers: [] }, applications: { includeApplications: [All] }, locations: { includeLocations: [All], excludeLocations: [Corp-Office] } }, grantControls: { operator: AND, builtInControls: [mfa, domainJoinedDevice] } }这段配置里最关键的是 conditions.locations 部分。includeLocations 设为 All表示所有位置都纳入策略范围但 excludeLocations 里排除了刚创建的 Corp-Office 命名位置效果就是“除办公室外所有位置都触发策略”。users 部分用 includeRoles 而不是 includeUsers因为策略要求的是针对全局管理员这个角色而不是单独几个用户账号。这样以后新增的全局管理员也会自动落进策略范围不需要手动维护用户列表。grantControls 里 operator 为 AND意味着用户必须同时满足 mfa 和 domainJoinedDevice 两个条件才能访问。如果这里写成 OR那就变成“要么 MFA、要么设备加入”安全语义完全变了。有一类经典错误就是为了省事把条件放宽成 OR结果用户在外面用自己的个人电脑照样进得去只要他做了 MFA 就行设备是不是企业管理的就无所谓了。这跟需求里“必须使用 Azure AD Join 设备”是冲突的。还有一个要注意的细节策略里的域设备控制项在英文界面里叫 “Require Azure AD joined device”不是 “Require compliant device”也不是 “Require Hybrid Azure AD joined device”。这三个选项在文档里经常被混淆。Require Azure AD joined device 要求设备已经注册到 Azure ADRequire compliant device 要求设备通过 Intune 或 MDM 的策略合规检查意味着设备不仅要加入还得满足全盘加密、系统补丁等条件Hybrid Azure AD joined 则针对本地 AD 加域设备。按题干的字面要求“Azure AD-joined device”就是第一个选项别选成另外两个。3.3 MFA 使用模型切换的隐藏限制题库里还有一组关于 MFA 使用模型的题当前配置的是 Per Authentication 模式收购了一家公司后新员工也要开启 MFA需求是改成 Per Enabled User 模式。方案一改现有 provider 的模型方案二用 Azure CLI 改方案三创建新的 provider 并备份旧数据答案分别是 B、B、A。这里面的硬知识是MFA Provider 的 usage model 一旦创建就不能改。Per Authentication 按认证次数计费Per Enabled User 按启用的用户数计费两种计费模型在底层就不是同一套逻辑Azure 不提供原地切换的功能。要想换模型只能新建一个对应模型的 Provider然后用新 Provider 的激活凭证重新激活 MFA Server。这个操作意味着你要重新配置连接期间相关用户可能短暂无法使用 MFA 服务生产环境需要安排维护窗口。用 Azure CLI 改也一样做不到因为 REST API 层就不存在修改 usage model 的接口。你调 PATCH 接口去更新 provider 的 properties返回的要么是 400 要么是 405。这个坑在真实工作中很常见有些运维同学接手了一个已经跑了一年的 MFA 环境想从按认证次数改成按用户数查了半天文档才发现根本改不了最后只能新开 Provider 做迁移。4. DirSync 与 Azure AD Connect 手动同步立即生效的命令和无效操作4.1 为什么 Active Directory 站点复制不能触发 Azure AD 同步题目场景是一家公司配置了混合环境本地 AD 与 Azure AD 通过 DirSync 服务器同步。管理员在本地 AD 中新建了一个用户现在要立刻把用户信息复制到 Azure AD。三个方案分别是运行 Start-ADSyncSyncCycle 强制同步、用 AD 站点和服务强制复制全局编录到域控、重启域控的 NetLogon 服务。答案是 A、B、B。首先理清 DateiSync 的机制。本地 AD 和 Azure AD 之间没有实时的双向复制通道只有 Azure AD ConnectDirSync 是它的旧称按照默认每 30 分钟一次的调度周期把增量变更同步到 Azure AD。AD 站点和服务里强制复制全局编录影响的是本地域控制器之间的复制它解决的是“这台 DC 上新建的用户有没有同步到另一台 DC”的问题而 Azure AD Connect 同步的是本地 AD 整个目录里已经存在的对象。换句话说不管本地复制多快Azure AD Connect 调度器不动Azure AD 侧就收不到新用户。重启 NetLogon 服务更离谱NetLogon 管的是域成员认证和安全通道跟目录同步没有直接关系。没有 NetLogon 服务域控之间的通信都要出问题更不可能触发 Azure AD 同步。这两个错误选项在考试里属于“用本地 AD 思维解决云端同步问题”的典型陷阱。4.2 强制同步的 PowerShell 命令与参数选择正确答案是运行 PowerShell cmdletImport-Module ADSync Start-ADSyncSyncCycle -PolicyType Initial这段命令里的 ADSync 模块是 Azure AD Connect 服务器上自带的只能在装有 Azure AD Connect 的那台服务器上运行不能在普通工作站上装这个模块然后远程调用。所以前提条件是管理员先通过 RDP 或者本地控制台登录到 Azure AD Connect 服务器上用管理员身份打开 PowerShell 窗口再执行 Import-Module 和 Start-ADSyncSyncCycle。-PolicyType 参数有两个可选值Initial 和 Delta。Initial 会做一次完整同步遍历全部目录对象耗时较长适合首次部署或者对象数量出现异常偏差的时候使用。Delta 只同步上次同步之后发生的变更速度快日常强制同步用 Delta 就够了。题目里说“立刻复制新建的用户”Delta 就足够但给出的命令是 Initial这也不影响正确性因为 Initial 包含 Delta 的所有工作全量同步肯定能带上新用户。如果只想要最快速度用Start-ADSyncSyncCycle -PolicyType Delta更合适。还有一种方式是调度器层面的Set-ADSyncScheduler -SyncCycleEnabled $true Start-ADSyncSyncCycle第一句确保调度器没有被暂停有些运维同学为了防止同步故障排查期间再次出问题会把调度器暂停掉然后忘记恢复导致新建用户迟迟不出现。第二句直接触发一次同步周期不指定 PolicyType 时默认按 Delta 执行。4.3 同步失败时怎么定位问题实际环境中强制同步跑完一批新用户只同步了部分到 Azure AD是比较常见的问题。最常见原因有三个一是安全管理器跳过了某些 OUAzure AD Connect 的域和 OU 过滤配置里有一份排除清单新建用户在排除的 OU 里同步自然不执行。确认方式是打开 Synchronization Service Manager切到 “Metaverse Search” 界面搜索该用户如果搜索不到说明本地 AD Connector 空间里就没被过滤进来。二是过滤规则冲突新用户的某个属性同时匹配了两条不同的同步规则一条映射到 Azure AD一条标记为无效地址结果用户对象直接进了一堆 provisioning 错误。三是邮箱属性和本地域不匹配导致软匹配失败DirSync 在 Azure AD 里找不到可以匹配的现有对象也不会创建新对象。排查同步错误的标准路径是先看 Windows 事件日志里 ADSync 来源的警告和错误再去 Synchronization Service Manager 里看 “Connectors” 面板中的 “Import” 和 “Export” 状态。如果 Export 阶段报 “directory synchronization” 错误通常要打开报错的目录对象详情里面会给出具体是哪个属性冲突。5. 存储冗余选型、ARM 模板回溯和可用性集扩容三道题的三个坑5.1 RA-GRS 与 GRS、ZRS、LRS 的边界题目要求两个数据中心配置为地理集群站点实现站点级恢复能力。需求有三条数据必须存储在多个节点上、数据必须存储在多个地理位置、既然后台地理复制好了还要能直接从次要位置读取数据。四个选项是 GRS、RA-GRS、ZRS、LRS正确答案是 RA-GRS。要理解为什么不是 GRS得先搞清楚 GRS 和 RA-GRS 的差别。GRS异地冗余存储会把数据从主区域复制到配对的次要区域数据确实存在两个地理位置但次要区域的数据是不可读的。如果主区域发生故障在故障转移完成之前你只能等微软完成重定向期间的读写都不可用。RA-GRS 在 GRS 基础上额外提供了读访问权你随时可以用特制的端点直接读取次要区域的数据这意味着即使主区域挂了应用还能切换到次区域做只读业务部分避免全站停服的风险。ZRS区域冗余存储把数据复制到同一区域内的多个可用区节点分布是不同的物理机房但三个可用区都在同一个地理区域里。洛杉矶和纽约这种跨地理位置的需求 ZRS 根本满足不了它的冗余边界只是同一个区域内的故障域。LRS本地冗余存储更不用说了同一数据中心内的同一机架里维持多个副本虽然能解决磁盘损坏级别的故障但整个机柜或整个机房一挂数据就完蛋。选型的判断逻辑应该是单区域内抗硬件故障选 LRS单区域内抗机房级故障选 ZRS跨地域容灾选 GRS跨地域容灾还想读次区域数据选 RA-GRS。还有一种参数叫 GZRS/RA-GZRSZRS 加跨区域复制的组合2022 年以后才主推如果考试里遇到它按同等级别的增强选项理解即可。5.2 从 Portal 和 CLI 回溯 ARM 模板的正确路径另一组题是同事用一个 ARM 模板部署了虚拟机和一个存储账号让你找到他用的模板。三个方案分别是从虚拟机关联的边栏、从容器边栏、从资源组分页里的部署记录查看答案是 B、B、A。ARM 模板的部署历史是挂在资源组下面的。每次执行模板部署无论你是用 Portal 的“部署自定义模板”功能、PowerShell 的 New-AzResourceGroupDeployment 还是 CLI 的 az deployment group create都会在资源组的 Architecture → Deployments 列表里留下一条记录点进去之后可以查看参数输入、操作输出以及整个模板的原始 JSON。虚拟机和存储账号边栏里没有这种部署历史功能因为一个资源可能是多个模板叠加的结果也可能是直接通过门户手动构建的没有部署记录不代表资源不能正常使用。Portal 的路径是进入资源组 → 左侧菜单选 “部署Deployments” → 找到对应部署记录 → 点击查看说明和“模板”选项卡。如果需要把模板直接导出成参数化的 ARM 文件资源组边栏的 “Automation → Export template” 也能做到但它导出的是这个资源组当前所有资源的完整状态不是某一次部署的明细。这两者要区分Deployments 里看的是历史部署Export template 里看的是当前资源快照。CLI 下查看部署历史az deployment group show \ --resource-group RG1 \ --name myVMTemplateDeployment \ --query properties.template \ --output json这条命令把指定名称的部署记录里的模板 JSON 直接导出来。--name 参数对应部署操作的名称不是你虚拟机的名字。如果你不知道部署名称先用az deployment group list --resource-group RG1 --output table列出所有部署记录看清楚 name 列再回填。很多同学在这一步会把 VM 的资源名称当成部署名称传进去然后报错找不到部署记录这就是没搞清楚层级关系。5.3 可用性集内 VM 扩容必须全停还是停一台最后一组场景题是可用性集里有三台 VM其中一台要扩容报错原因是 allocation failure问应该怎么办。答案是停止所有三台 VM 再扩容。这个问题的底层原因在于可用性集约束了 VM 的物理分布位置。可用性集里的 VM 会分布在不同的容错域和更新域中Fault Domain 对应物理机架和电源Update Domain 对应同时重启的粒度。当你要给其中一台 VM 扩到一个需要不同物理硬件形态的 VM Size 时比如从 D 系列升到 E 系列Azure 需要找到一台同时满足以下条件的宿主机能提供目标 VM Size 的规格、还有剩余的容量、并且和可用性集里其他 VM 服务器的硬件类型兼容。如果其他 VM 还在运行Azure 会优先把新 VM 放在与它们相同的物理集群上否则就打破了故障域的约束条件。这个集群上没有足够的资源就会报 allocation failure。把所有 VM 停掉之后虚拟机已经不再占用集群资源Azure 调度器可以重新选择任意一个满足新规格和可用性集约束的集群来放置整个可用性集。所以这个操作本质上是“释放旧的硬件约束重新调度整组虚拟机”。真实场景中的建议是先确认新 VM Size 是否与可用性集里其他 VM 的当前 Size 属于同一代际和同一硬件系列。如果是同代际的小幅升级比如从 Standard_D2s_v3 升到 Standard_D4s_v3只要当前集群资源充足不停机也能直接改只有当跨系列或者目标 Size 的资源耗尽时才需要全停。另一个做法是把虚拟机从可用性集里移出来再扩容但这会破坏可用性集的故障域保护生产环境不建议这么干除非你有把握通过独立 VM 或 Virtual Machine Scale Sets 重新建立容错能力。6. 避坑指南这份题库里反复出现的四类模糊陷阱6.1 混淆 Azure AD 身份管理和 Azure AD 条件访问最常见的一道错题是公司需要全局管理员从不受信任位置使用 MFA 登录方案直接去 MFA 页面改用户状态。现象题目答案选 Yes错误理解 MFA 为“只管开关”。原因MFA 页面上的 per-user MFA 开关不感知位置也没法和设备加入状态联动。解决条件访问策略必须在 Azure Active Directory → Security → Conditional Access 里配置把位置和 MFA 控制绑定在同一个策略中。从那以后我做任何 MFA 需求都会先问一句“这个策略的评估信号是什么”而不是直接开开关。6.2 拿本地 AD 逻辑猜同步行为现象在本地 AD 建了新用户用 AD Sites and Services 强制复制之后发现 Azure AD 里依然没有该用户。原因AD 站点复制和 Azure AD Connect 同步是两套完全独立的管线前者影响本地 DC 之间的数据一致性后者独立拉取目录变更。解决登录 Azure AD Connect 服务器执行Start-ADSyncSyncCycle -PolicyType Delta。如果用户还是不出来检查 Synchronization Service Manager 里是否有域/OU 过滤规则把用户所在的容器给排除了。注意你无法从本地普通 Windows 工作站连接 Azure AD Connect必须直接登录那台服务器才能运行 ADSync 模块命令。6.3 把部署历史和管理视图混为一谈现象同事用 ARM 模板部署了 VM 和存储账号你想看原始模板进了 VM 的边栏翻来翻去找不到。原因VM 资源配置页只展示资源本身属性不会存储部署时的模板。解决去资源组的 Deployments 列表找部署记录或使用 CLI 的az deployment group show --query properties.template直接拉取模板 JSON。如果你需要的是当前资源组的可部署模板而不是历史部署时的快照用资源组的 Export template 功能导出结果为当前状态注意两者存在差异。6.4 可用性集扩容不停机直接改现象在可用性集中某一台 VM 上调大 SizeAzure 提示 allocation failure扩容没办法继续。原因可用性集要求所有 VM 驻留在同一物理集群目标 Size 在当前集群上没有容量。解决将可用性集中所有 VM 停止再执行扩容扩容完成后重新启动全部 VM。如果业务不允许全部停止可以考虑创建新的可用性集来接纳这台扩容后的 VM并将它从原可用性集移除前提是应用侧设计了跨可用性集的容错逻辑。如果遇到“停止所有 VM 后依然报错”检查是否用的是 Spot VM 或 Azure Reserved Instance预留实例的容量与 VM 型号绑定型号不匹配时会限制你的调配。7. 题库的高阶用法用社区投票分布反推争议题的出题意图把这份题库当“背题资料”用是浪费它真正值钱的地方在每道题附带的 Community vote distribution。这个投票分布直接暴露了一道题是有共识还是存在争议。比如某题的投票是 B93%7%说明这道题在考生群体中有一致答案大概率对应一个官方文档里写得明确的机制点刷题时只要把那个机制点理解透就行。如果投票分布呈四六开或者五五开情况就完全不同意味着这道题本身存在文字歧义或者考试界的理解有分化这种题恰恰是出题人最爱设坑的地方。以第二到第四题为例三题题干一样但答案不同这种排列在真实考试中也常见。考试时你看到的题序可能是乱序的三题的答案也不一定按 A、B、B 排。如果你只是背了答案而没理解解法逻辑换一种答案分布就很容易翻车。正确做法是遇到重复题干的题目横向对比各题的“Solution”部分的差异尤其是关键动词比如“alter grant control”和“alter session control”这两处的区别决定了整个答案走向。我刷题时会单独建一个 Excel把题干相同而解法不同的题放在同一行解法差异写在备注列用这个方式强制自己区分概念边界。题库里的 Reference 链接也值得单独处理。每道题下面挂的微软官方文档地址是很多题目的直接出处比如条件访问策略、存储冗余、ARM 模板导出页面。我习惯把链接按主题分类整理到自己的知识库刷题遇到不确定的选项时先回官方文档确认再回来看题库解析。官方文档的优点是描述精确缺点是不讲场景题库正好补上了场景化部分两者的配合效果远好于只刷任一一种。验证自己是否真正掌握这些知识点的方法不是把题库从头到尾过一遍而是把每道题的“错误选项”改成“正确操作”然后想清楚为什么原来的做法是错的。比如 MFA 那道题错误项是“去 MFA 页面改用户设置”你如果能说清楚“per-user MFA 停止工作、条件访问策略还依赖它、失败时怎么排查”那你就真正理解了。说不上来也没关系回到对应章节的原文再走一遍实操命令然后用自己的话写一段操作笔记。从那以后我每次刷这类题库都会强制走一遍“正确答案 → 官方文档 → 身边云环境验证”的流程确实能避掉那些背答案带来的知识盲区希望帮到你。本文还有配套的精品资源点击获取