从入门到精通：AZ-104五大考试模块全面解析与实战演练

第一章：Azure Administrator Associate（AZ-104）备考指南

考试概述与目标受众

Azure Administrator Associate（AZ-104）是微软认证体系中的核心角色认证之一，面向负责在云环境中实施、管理及监控Microsoft Azure资源的IT专业人员。该认证验证考生是否具备管理Azure身份与治理、存储、虚拟网络、虚拟机及备份等核心服务的能力。

关键知识领域

准备AZ-104考试需掌握以下核心模块：

• Azure身份管理与访问控制（如Azure AD、RBAC）
• 虚拟网络配置与网络安全组（NSG）规则管理
• 存储账户类型选择与数据复制策略（LRS、GRS等）
• 虚拟机部署、扩展与高可用性设置
• 监控与备份解决方案（如Azure Monitor、Recovery Services）

常用命令示例

在日常管理中，Azure CLI是高效操作的重要工具。以下命令用于创建资源组并部署Linux虚拟机：

# 创建资源组
az group create --name MyResourceGroup --location eastus

# 创建基于Ubuntu的虚拟机
az vm create \
  --resource-group MyResourceGroup \
  --name MyVM \
  --image Ubuntu2204 \
  --admin-username azureuser \
  --generate-ssh-keys

# 开放SSH端口
az vm open-port --port 22 --resource-group MyResourceGroup --name MyVM

上述命令依次完成资源分组、虚拟机初始化和网络访问配置，适用于快速搭建测试环境。

学习路径建议

阶段	内容	推荐资源
基础学习	Azure核心服务概念	Microsoft Learn模块AZ-104
实践操作	动手实验与沙盒环境	Azure Free Account + Labs
模拟测试	评估知识盲区	Whizlabs或MeasureUp题库

graph TD A[开始备考] --> B(学习身份与治理) B --> C[掌握存储与网络] C --> D[部署与管理计算资源] D --> E[实施监控与备份] E --> F[参加模拟考试] F --> G[预约正式考试]

第二章：管理Azure标识与访问控制

2.1 Azure AD用户、组与角色权限管理理论解析

在Azure Active Directory（Azure AD）中，用户、组与角色构成了身份与访问管理的核心支柱。通过精细化的权限分配，组织能够实现最小权限原则和职责分离。

核心概念解析

• 用户：代表个体身份，可分配许可证与权限。
• 组：用于批量管理用户，支持动态成员规则。
• 角色：定义权限集合，如“全局管理员”或“应用管理员”。

角色绑定示例

{
  "roleDefinitionId": "f28a1f50-f6e7-4cb0-a1eb-9b1344a9ad62",
  "principalId": "a1b2c3d4-1234-5678-90ab-cdef12345678",
  "scope": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

该JSON片段表示将指定角色（如“贡献者”）分配给特定用户（principalId）在订阅级别上的资源操作权限。scope决定了权限的作用范围，支持层级继承。

权限模型层次结构

角色类型	权限范围	典型使用场景
全局管理员	全服务最高权限	初始配置与紧急恢复
用户管理员	管理用户与组	HR协作账户管理
应用管理员	应用注册与策略	开发者自助服务

2.2 基于RBAC的资源访问控制实战配置

在Kubernetes环境中，基于角色的访问控制（RBAC）是保障集群安全的核心机制。通过定义角色与绑定关系，实现对用户或服务账户对资源的精细化权限管理。

角色与角色绑定配置示例

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

上述配置在default命名空间中创建名为pod-reader的角色，允许对Pod执行获取、列举和监听操作。通过RoleBinding将该角色授予用户alice，实现最小权限原则下的资源访问控制。verbs字段定义操作类型，resources指定受控资源，apiGroups标识API组，确保策略精准生效。

2.3 多因素认证与条件访问策略应用

在现代身份安全架构中，多因素认证（MFA）是抵御账户劫持的关键防线。通过结合密码、设备状态与生物特征等多种验证方式，显著提升访问安全性。

条件访问策略配置示例

{
  "displayName": "Require MFA for Remote Access",
  "state": "enabled",
  "conditions": {
    "signInRisk": "medium",
    "clientAppTypes": ["browser", "mobileApps"],
    "locations": { "includeLocations": ["AllTrusted"] }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

上述策略表示：当用户登录风险为“中等”且来自受信任位置时，必须完成MFA才能获得访问权限。其中，signInRisk依赖于AI驱动的风险评估引擎，builtInControls定义强制控制动作。

策略执行流程

用户请求 → 身份验证 → 风险评估 → 条件匹配 → 执行控制（允许/阻止/MFA）

通过动态策略决策，系统可在不同风险场景下自动调整安全要求，实现安全与可用性的平衡。

2.4 管理企业级应用程序与服务主体

在企业级系统中，应用程序与服务主体的管理是身份权限控制的核心环节。通过精细化配置，可实现资源访问的安全性与灵活性统一。

服务主体注册与权限分配

每个企业应用需在身份平台注册，生成唯一的服务主体（Service Principal），作为其在目录中的安全标识。

• 服务主体绑定具体的应用注册信息
• 通过角色分配授予最小必要权限
• 支持多租户环境下的跨组织资源访问

使用 Microsoft Graph API 管理应用

POST https://graph.microsoft.com/v1.0/applications
Content-Type: application/json

{
  "displayName": "EnterpriseApp-OrderProcessing",
  "signInAudience": "AzureADMultipleOrgs"
}

该请求创建一个新的企业应用。参数 `displayName` 定义应用名称，`signInAudience` 指定支持多组织登录，适用于SaaS场景。创建后系统返回应用对象ID和服务主体ID，用于后续权限绑定与身份验证配置。

2.5 标识保护与安全风险监控演练

动态令牌与访问控制策略

在身份标识保护中，采用短时效的JWT令牌可有效降低泄露风险。通过设置合理的过期时间与刷新机制，确保用户会话安全。

// 生成带过期时间的JWT令牌
func GenerateToken(userID string) (string, error) {
    claims := jwt.MapClaims{
        "user_id": userID,
        "exp":     time.Now().Add(time.Minute * 15).Unix(), // 15分钟过期
        "iss":     "auth-system",
    }
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    return token.SignedString([]byte("secret-key"))
}

上述代码生成一个签名的JWT，包含用户ID、过期时间和签发者。密钥应存储于环境变量或密钥管理服务中，避免硬编码。

实时风险行为监控

建立基于规则引擎的行为审计系统，对登录频次、IP异常、设备变更等进行实时检测，并触发多因素认证或会话终止。

• 异常登录地点：同一账户短时间内从不同地理区域登录
• 高频访问敏感接口：超出阈值时记录并告警
• 令牌重放尝试：通过唯一JTI防止重放攻击

第三章：虚拟网络与通信架构设计

3.1 虚拟网络规划、子网划分与对等互连原理

在构建云上基础设施时，虚拟网络规划是确保资源隔离与通信的基础。合理的子网划分能够提升网络安全性并优化地址利用率。

子网划分示例

以一个 /24 网段为例，通过 CIDR 划分多个子网：

# 划分 192.168.10.0/24 为 4 个子网
Subnet 1: 192.168.10.0/26 → 可用地址：1-62
Subnet 2: 192.168.10.64/26 → 可用地址：65-126
Subnet 3: 192.168.10.128/26 → 可用地址：129-190
Subnet 4: 192.168.10.192/26 → 可用地址：193-254

该划分方式使用 2 位扩展网络前缀，实现四等分子网，每个子网支持最多 62 台主机。

虚拟网络对等互连

对等互连允许两个虚拟网络间直接通信。配置时需确保路由表正确更新，并禁用源目标检查。

• 跨区域对等需启用全局对等功能
• 对等连接是非传递性的，需通过中间枢纽中转
• 安全组和网络ACL仍适用于对等流量控制

3.2 公共与专用DNS配置及流量路由实践

在混合云架构中，合理配置公共与专用DNS是实现精准流量路由的关键。通过区分内外网解析策略，可有效提升服务访问效率与安全性。

DNS区域划分策略

• 公共DNS：面向互联网用户提供解析，通常托管于云厂商或第三方（如Cloudflare）
• 专用DNS：用于私有网络内部通信，如AWS Route 53 Private Hosted Zones

核心配置示例

# 示例：CoreDNS中配置split-horizon DNS
zone example.com {
    # 公共解析规则
    forward . /etc/resolv.conf
}
 
zone internal.example.com {
    # 内部专用解析
    file /etc/coredns/zones/internal.example.com
}

上述配置实现了域名的分流解析：外部请求走默认上游，内部域则由本地文件响应，确保私有服务不暴露于公网。

流量路由控制表

请求来源	查询域名	解析结果
公网用户	api.example.com	公网负载均衡IP
VPC内实例	api.example.com	内部服务发现地址

3.3 网络安全组与Azure防火墙策略部署

在Azure云环境中，网络安全组（NSG）和Azure防火墙是实现网络分段与流量控制的核心组件。NSG适用于子网或网络接口层级的访问控制，而Azure防火墙则提供集中化、可跨虚拟网络复用的高级威胁防护。

网络安全组基础规则配置

NSG规则按优先级顺序评估入站和出站流量。以下示例展示如何通过ARM模板定义允许SSH访问的规则：

{
  "priority": 100,
  "access": "Allow",
  "protocol": "Tcp",
  "direction": "Inbound",
  "sourcePortRange": "*",
  "sourceAddressPrefix": "Internet",
  "destinationPortRange": "22",
  "destinationAddressPrefix": "*"
}

该规则允许来自互联网的SSH连接，优先级为100，确保早于拒绝规则生效。* 表示通配符匹配，实际生产环境应限制源IP范围。

Azure防火墙策略集成

Azure防火墙支持基于FQDN、IP前缀和应用规则的精细化控制。可通过策略继承机制实现多订阅统一管理，提升运维效率。

第四章：计算资源与高可用性架构管理

4.1 Azure虚拟机创建、规模集与自定义映像操作

虚拟机快速部署

通过Azure CLI可高效创建虚拟机。以下命令示例展示如何部署Ubuntu服务器：

az vm create \
  --resource-group myRG \
  --name myVM \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username azureuser

该命令指定资源组、名称、镜像、实例大小及管理员账户。Standard_B2s为低成本入门级配置，适合开发测试。

虚拟机规模集弹性扩展

使用规模集（VMSS）实现应用层自动伸缩。核心配置包括：

• 实例数量：初始部署5台
• 自动缩放规则：基于CPU使用率
• 负载均衡器：集成标准LB分发流量

自定义映像的封装与复用

将已配置的VM通用化后捕获为托管映像，用于跨环境一致部署：

az vm deallocate -g myRG -n myVM
az vm generalize -g myRG -n myVM
az image create -g myRG --source myVM --name myCustomImage

此流程确保操作系统处于可复制状态，适用于标准化生产环境批量部署。

4.2 托管磁盘与可用性集/区域容灾设计实战

在高可用架构设计中，Azure托管磁盘与可用性集（Availability Set）或可用性区域（Availability Zone）的组合使用，是保障虚拟机持久化数据可靠性的核心手段。

部署跨区域冗余的VM集群

通过资源管理器模板可定义跨可用性区域的虚拟机部署，结合ZRS（Zone-Redundant Storage）托管磁盘，实现磁盘级别的区域容灾：

{
  "type": "Microsoft.Compute/virtualMachines",
  "apiVersion": "2022-08-01",
  "zones": ["1"],
  "properties": {
    "storageProfile": {
      "osDisk": {
        "managedDisk": {
          "storageAccountType": "Standard_ZRS"
        }
      }
    }
  }
}

上述配置将OS磁盘存储于具备跨区域复制能力的ZRS存储中，确保单个区域故障时磁盘仍可挂载。"zones": ["1"] 指定虚拟机部署在第一可用区，配合负载均衡器可构建多区高可用架构。

容灾策略对比

策略	容灾级别	成本
可用性集	机架级冗余	低
可用性区域	区域级容灾	中高

4.3 Azure Kubernetes Service（AKS）基础集成

在构建云原生应用时，Azure Kubernetes Service（AKS）提供了高度可扩展的容器编排能力。通过Azure CLI可快速部署集群：

az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --node-count 2 \
  --enable-addons monitoring \
  --generate-ssh-keys

上述命令创建包含两个节点的AKS集群，并启用监控附加组件。参数 `--resource-group` 指定资源组，`--name` 定义集群名称，`--node-count` 控制初始节点数量。

集群访问配置

部署完成后，需获取Kubernetes凭证以连接集群：

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

该命令将集群配置合并至本地 kubeconfig 文件，使 kubectl 能够管理AKS集群。

核心优势一览

• 自动节点升级与自愈能力
• 与Azure Monitor、Azure AD深度集成
• 支持虚拟节点与无服务器Pod运行

4.4 监控虚拟机性能与自动化扩展策略

性能监控指标采集

虚拟机性能监控依赖于对CPU、内存、磁盘I/O和网络流量的持续采集。常用工具如Prometheus配合Node Exporter可实现多维度指标抓取。

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['192.168.1.10:9100']

该配置定义了Prometheus从目标虚拟机的9100端口拉取节点指标，适用于Linux系统资源监控。

自动化扩展触发机制

基于监控数据，可通过阈值判断动态扩展实例数量。常见策略包括：

• CPU使用率持续5分钟超过80%
• 内存利用率高于75%
• 请求延迟超过设定阈值

弹性伸缩策略配置示例

在云平台中，自动扩展组（Auto Scaling Group）结合告警规则可实现自动增减实例。

策略类型	触发条件	动作
扩容	CPU > 80%	增加2个实例
缩容	CPU < 30%	减少1个实例

第五章：总结与展望

技术演进的实际路径

现代后端系统正朝着云原生与服务网格深度整合的方向发展。以 Istio 为例，其通过 Sidecar 模式实现流量透明劫持，显著提升了微服务可观测性。以下为典型虚拟服务配置片段：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: user-service-route
spec:
  hosts:
    - user-api.example.com
  http:
    - route:
        - destination:
            host: user-service.prod.svc.cluster.local
          weight: 90
        - destination:
            host: user-service.canary.svc.cluster.local
          weight: 10

架构优化的决策依据

在高并发场景中，数据库分片策略直接影响系统吞吐能力。某电商平台通过用户 ID 哈希值进行水平拆分，将订单表从单库单表扩展至 64 个分片，QPS 提升近 7 倍。

分片数	平均响应延迟 (ms)	最大吞吐 (TPS)
1	142	850
16	43	4200
64	29	5900

未来可扩展方向

边缘计算与 AI 推理的融合正在重塑应用部署模型。通过 Kubernetes 的 KubeEdge 扩展，可在工厂产线部署轻量级推理服务，实现毫秒级缺陷检测反馈。该方案已在某新能源电池质检系统中验证，误检率下降至 0.3%。