AZ-305最新考纲变动解读：这些新增内容90%考生都忽略了！

第一章：AZ-305考试概览与核心能力要求

Azure Solutions Architect Expert 认证的 AZ-305 考试旨在评估考生在设计可扩展、高可用性和安全的 Microsoft Azure 解决方案方面的专业能力。该考试面向具备丰富云架构经验的技术人员，要求其能够根据业务需求制定合理的云资源配置、网络架构、身份管理及数据保护策略。

考试目标领域

• 设计身份、治理和监控解决方案
• 设计数据存储解决方案，涵盖关系型与非关系型数据库
• 设计业务连续性，包括备份、灾难恢复与区域部署策略
• 设计基础设施，如虚拟网络、计算资源与集成服务

核心技能要求

能力领域	关键技能点
身份与访问管理	使用 Azure AD 设计多租户应用访问控制
网络架构设计	规划 VNet 拓扑、DNS、负载均衡与混合连接
安全性与合规性	实施 Azure Policy、Private Link 和密钥管理

典型设计场景示例

在跨区域高可用架构设计中，常需配置异地复制的存储账户与自动故障转移机制。以下为启用读取访问地理冗余存储（RA-GRS）的 ARM 模板片段：

{
  "type": "Microsoft.Storage/storageAccounts",
  "apiVersion": "2023-01-01",
  "name": "[variables('storageAccountName')]",
  "location": "[resourceGroup().location]",
  "sku": {
    "name": "Standard_RAGRS" // 启用读取访问的地理冗余
  },
  "kind": "StorageV2",
  "properties": {
    "accessTier": "Hot"
  }
}

上述配置确保数据在主区域不可用时仍可通过备用区域进行读取操作，适用于对容灾能力要求较高的企业级应用。

graph TD A[用户请求] --> B{流量入口} B --> C[Azure Front Door] B --> D[Application Gateway] C --> E[区域1应用服务] C --> F[区域2应用服务] E --> G[(RA-GRS 存储)] F --> G

第二章：身份与访问管理的深度解析

2.1 Azure AD中的多租户架构设计原理

Azure AD的多租户架构允许多个独立组织（租户）共享同一服务实例，同时保证数据隔离与安全边界。每个租户拥有独立的身份命名空间，通过全局唯一的租户ID进行区分。

租户隔离机制

系统在逻辑层通过租户上下文路由请求，并结合访问令牌中的tid（Tenant ID）声明实施策略控制，确保跨租户资源访问被严格限制。

应用注册与权限模型

多租户应用需在发布者租户中注册并配置为“支持多租户”。用户首次登录时触发OAuth 2.0许可流程，授权应用访问其所在租户的资源。

GET https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize?
client_id=6c5b8de6-10d2-4e1a-a9cf-1b7e2ba3f0d4
&response_type=code
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&response_mode=query
&scope=https://graph.microsoft.com/User.Read
&state=12345

该请求引导用户至目标租户的身份验证端点，其中{tenant-id}可为具体租户ID或organizations通配符，表示接受任意工作或学校账户登录。

2.2 基于角色的访问控制（RBAC）策略实践

在现代系统安全架构中，基于角色的访问控制（RBAC）通过将权限与角色绑定，简化了用户权限管理。一个典型的角色定义如下：

{
  "role": "admin",
  "permissions": [
    "user:create",
    "user:delete",
    "resource:modify"
  ]
}

上述 JSON 定义了名为 `admin` 的角色，具备用户和资源操作权限。系统在鉴权时，先查询用户所属角色，再获取对应权限集合。

核心组件设计

RBAC 系统通常包含三个核心元素：

• 用户（User）：系统操作者。
• 角色（Role）：权限的逻辑分组。
• 权限（Permission）：对特定资源的操作许可。

权限映射表

角色	可访问资源	操作权限
viewer	/api/data	GET
editor	/api/data	GET, POST, PUT

2.3 条件访问策略在企业安全中的实战应用

基于风险的访问控制

现代企业面临日益复杂的网络威胁，条件访问策略通过动态评估用户登录上下文（如位置、设备状态、风险级别）来决定是否授予访问权限。例如，在 Azure AD 中可配置策略仅允许合规设备且位于可信 IP 范围内访问关键应用。

典型策略配置示例

{
  "displayName": "Require MFA for High Risk Sign-ins",
  "conditions": {
    "signInRiskLevels": ["high"],
    "applications": {
      "includeApplications": ["Office365"]
    }
  },
  "accessControls": {
    "grantControls": ["mfa"]
  }
}

上述策略表示：当系统检测到高风险登录尝试时，强制要求多因素认证（MFA），有效降低账户被盗用的风险。其中 signInRiskLevels 由 Azure Identity Protection 动态计算，grantControls 定义了访问授权条件。

• 仅限公司托管设备接入核心系统
• 阻止来自非标准地理位置的敏感数据访问
• 对异常时间登录触发实时审批流程

2.4 托管身份在PaaS资源中的集成方案

在Azure平台中，托管身份（Managed Identity）为PaaS服务提供了安全访问其他资源的机制，无需管理凭据。通过系统或用户分配的托管身份，应用服务、函数应用等可直接与Key Vault、存储账户等资源交互。

启用托管身份的典型配置

{
  "identity": {
    "type": "SystemAssigned"
  },
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2021-02-01",
      "name": "my-web-app",
      "identity": {
        "type": "SystemAssigned"
      }
    }
  ]
}

该ARM模板片段启用了应用服务的系统托管身份。部署后，Azure自动在AD中注册服务主体，并可在其他资源的RBAC权限中引用。

访问密钥保管库的授权流程

1. 在Key Vault中配置访问策略，授予托管身份“Get”权限
2. 应用通过MSI endpoint获取访问令牌
3. 使用令牌调用Key Vault API获取机密

2.5 身份治理与权限生命周期管理最佳实践

统一身份源与自动化同步

建立集中式身份存储是权限治理的基础。通过将企业AD或LDAP作为权威身份源，结合SCIM协议实现向SaaS应用的自动用户同步。

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "alice@company.com",
  "active": true,
  "emails": [{
    "value": "alice@company.com",
    "type": "work"
  }]
}

该SCIM用户对象示例包含标准化字段，active状态控制账户启用，确保离职员工即时禁用。

权限生命周期阶段化管理

• 入职：基于岗位角色自动分配最小权限集
• 在职：定期执行权限审查，识别过度授权
• 转岗：触发权限再认证流程（Access Recertification）
• 离职：自动触发去激活与资源解绑

第三章：数据平台与存储解决方案设计

3.1 非结构化数据存储选型：Blob vs Data Lake

核心特性对比

Azure Blob Storage 是一种高可用、低成本的对象存储服务，适用于静态文件如图片、日志和备份。而 Data Lake Storage（基于 Blob 构建）在此基础上增加了分层命名空间和高级安全控制，专为大规模数据分析场景设计。

• Blob：适合简单读写、生命周期管理明确的非结构化数据
• Data Lake：支持目录级权限、与大数据生态（如 Spark、Databricks）无缝集成

权限模型差异

<!-- Blob 使用基于 SAS 或 RBAC 的扁平授权 -->
<AccessPolicy>
  <Permission>rwd</Permission>
</AccessPolicy>

<!-- Data Lake 支持 ACL 细粒度控制 -->
<acl>user::rwx,group::r--,other::---</acl>

上述配置体现 Data Lake 在多租户分析场景下的安全优势，可对目录和文件设置 POSIX 风格访问控制。

典型应用场景

场景	Blob	Data Lake
备份归档	✓	△
机器学习训练	△	✓
日志存储	✓	✓

3.2 数据冗余与高可用性策略配置实战

数据同步机制

在分布式存储系统中，数据冗余通过多副本机制保障高可用。以Raft共识算法为例，写入操作需在多数节点确认后提交。

// 配置Raft副本数量
config := &raft.Config{
    ID:              1,
    ElectionTimeout: 1000,  // 选举超时时间（毫秒）
    HeartbeatTimeout: 500,  // 心跳间隔
    MaxLogEntries:   1024,   // 最大日志条目
}

上述配置确保在节点故障时能快速触发领导者选举，维持集群可用性。

高可用部署模式

常见部署策略包括主从复制与多活架构。下表对比二者特性：

策略	数据一致性	故障恢复	适用场景
主从复制	强一致	较快	读多写少
多活架构	最终一致	即时	跨区域部署

3.3 数据加密与密钥管理的端到端实现

加密策略设计

在端到端通信中，采用混合加密机制：使用RSA进行密钥交换，AES-256-GCM执行数据加密。该方案兼顾安全性与性能。

// 生成AES密钥并使用RSA公钥加密
ciphertext, _ := rsa.EncryptOAEP(
    sha256.New(),
    rand.Reader,
    &publicKey,
    aesKey,
    nil)

上述代码实现密钥封装，aesKey为会话密钥，publicKey为接收方RSA公钥，确保密钥传输安全。

密钥生命周期管理

• 密钥生成：使用加密安全随机数生成器（CSPRNG）
• 存储保护：主密钥由HSM（硬件安全模块）托管
• 轮换机制：每90天自动更新数据加密密钥

密钥类型	算法	有效期
主密钥	RSA-4096	5年
数据密钥	AES-256	90天

第四章：混合云与网络架构设计要点

4.1 Azure Virtual WAN在全局网络中的部署实践

Azure Virtual WAN 提供集中式枢纽架构，简化全球分支与云资源的互联。通过自动化连接管理，实现站点到站点、点到站点及VNet间的高效通信。

核心组件与拓扑设计

部署时需规划虚拟中心（Virtual Hub）、连接网关和路由表。虚拟中心自动跨区域对等，确保低延迟互通。

组件	功能说明
Virtual Hub	跨区域网络枢纽，集成防火墙与路由功能
Site-to-Site Gateway	支持IPsec连接本地分支机构

配置示例：创建虚拟WAN

az network vwan create \
  --name myVirtualWAN \
  --resource-group rg-network \
  --location eastus \
  --type Standard

该命令创建标准版Virtual WAN实例，--type Standard启用高级路由与防火墙集成能力，适用于企业级多站点场景。

4.2 混合连接与Azure Arc集成的技术路径分析

在混合云架构中，Azure Hybrid Connections 与 Azure Arc 的协同为跨环境资源管理提供了统一入口。通过轻量级代理部署，Azure Arc 可将本地或第三方云资源注册到 Azure 资源管理器中，实现集中策略控制与监控。

连接建立流程

• 在目标服务器安装 Azure Connected Machine Agent
• 代理通过 HTTPS 出站连接至 Azure 元数据服务
• 完成身份验证后，资源以“已启用 Arc”状态出现在 Azure 门户

代码示例：部署Arc代理

# 下载并安装Connected Machine Agent
wget https://aka.ms/azcmagent.sh -O install_linux_azcm_agent.sh
sudo bash install_linux_azcm_agent.sh --connectivity-type proxy --proxy "{proxy-url}" \
  --resource-group "myRG" \
  --location "eastus" \
  --tenant-id "xxx-xxxx" \
  --subscription-id "xxx-xxxx"

该脚本通过指定代理配置实现受限网络环境下的连接，参数--connectivity-type proxy确保混合环境中通信可达，而--tenant-id和--subscription-id实现资源归属精准绑定。

集成优势对比

特性	Hybrid Connection	Azure Arc
协议支持	TCP/HTTP	HTTPS双向通道
管理粒度	应用级	主机级全栈管理

4.3 网络安全组与Azure防火墙协同防护设计

在Azure云环境中，网络安全组（NSG）与Azure防火墙的协同使用可实现分层防御。NSG部署于子网或网卡层级，提供基于IP、端口和协议的五元组访问控制，适用于东西向流量的基础过滤。

协同架构设计

通过将NSG作为第一道防线，阻止明显恶意流量，再由Azure防火墙执行应用层检测和集中策略管理，形成纵深防御体系。例如，NSG可拒绝非80/443端口入站请求，仅允许特定子网流量进入应用网关。

{
  "priority": 100,
  "sourceAddressPrefix": "*",
  "destinationAddressPrefix": "10.0.1.0/24",
  "destinationPortRange": "80,443",
  "protocol": "Tcp",
  "access": "Allow",
  "direction": "Inbound"
}

上述规则配置于NSG中，优先放行必要的Web流量，其余流量默认拒绝。该规则应设置合理优先级以避免被高优先级拒绝规则覆盖。

策略分工对比

特性	网络安全组	Azure防火墙
层级	网络层	应用层
日志审计	基础流日志	完整应用日志
部署粒度	子网/网卡	虚拟网络中心

4.4 私有链接与服务终结点的安全通信实现

在云环境中，私有链接（Private Link）和服务终结点（Service Endpoint）是实现安全通信的关键技术。它们通过将网络流量限制在私有网络内，避免数据暴露于公共互联网。

私有链接的工作机制

私有链接允许消费者通过私有IP访问服务提供者资源，所有通信均在VPC内部完成。例如，在Azure中配置Private Link Service时，需绑定负载均衡器前端IP：

{
  "privateLinkServiceIpConfigs": [{
    "name": "pl-ip-config",
    "properties": {
      "subnet": { "id": "/subscriptions/.../subnets/pl-subnet" },
      "primary": true,
      "privateIPAddress": "10.0.1.10"
    }
  }]
}

该配置将私有链接服务绑定至特定子网，并分配静态私有IP，确保服务端点的稳定性和可访问性。

服务终结点的优势对比

• 消除公网暴露风险，增强数据安全性
• 支持基于VNet的精细访问控制
• 与NSG和防火墙策略无缝集成

结合使用这两种技术，可在多租户环境中构建端到端的隔离通信链路。

第五章：备考策略与高分通关建议

制定个性化学习计划

成功的备考始于科学的时间管理。建议考生根据自身基础和考试日期倒推，划分三个阶段：基础夯实、专项突破、全真模拟。每日安排至少 2 小时专注学习，并使用番茄工作法提升效率。

高频考点精练与错题复盘

以下为某考生在 Kubernetes 认证（CKA）备考中整理的核心命令示例：

# 查看 Pod 状态并过滤异常
kubectl get pods -A | grep -v Running

# 快速调试节点问题
kubectl describe node controlplane | grep -i taint

# 备份 etcd（需进入控制平面节点）
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /tmp/etcd-backup.db

模拟环境实战演练

推荐搭建与真实考试一致的实验环境。例如，在 CKA 考试中，可使用 kubeadm 快速部署集群，并通过以下步骤验证操作熟练度：

1. 创建命名空间并限制资源配额
2. 配置 NetworkPolicy 实现 Pod 隔离
3. 使用 Helm 安装监控套件 Prometheus
4. 执行滚动更新并回滚验证

时间分配与应试技巧

题型	建议用时	得分权重
集群运维	40 分钟	25%
故障排查	30 分钟	30%
应用部署	25 分钟	20%