AZ-400相关技术要点解析

# AZ-400相关技术要点解析 ## 1. 容器与虚拟机对比 运行容器而非虚拟机的一大优势在于容器共享操作系统内核，这使得容器镜像比虚拟机镜像更小，该说法正确。 ## 2. 测试类型范围排序 按测试范围从小到大排序为： 1. 单元测试 2. 集成测试 3. 系统测试 ## 3. 测试相关判断 以下说法正确的有： - 压力测试通过对系统施加不断增加的负载来确定系统的崩溃点。 - 性能测试用于测量系统执行给定任务的速度。 ## 4. Azure DevOps 仪表盘 创建 Azure DevOps 仪表盘以洞察代码质量时，“显示每天签入次数的小部件”不属于此类仪表盘。 ## 5. 合并策略 “Interleave”不是有效的合并策略。 ## 6. OWASP Top 10 “Least Privilege Principle violations”不属于 OWASP Top 10。 ## 7. 容器镜像存储 可用于存储容器镜像的有： - Azure Container Registry - Docker Hub ## 8. 通知配置 在 Azure DevOps 项目中配置电子邮件订阅，可在任何集成构建失败时收到通知。 ## 9. YAML 管道触发 可以在 Azure Artifact 源中的新工件版本可用时触发 YAML 管道。 ## 10. 多阶段 YAML 管道代理使用 可以在多阶段 YAML 管道的同一阶段混合使用托管代理、云中的私有代理和本地代理。 ## 11. 发布管道触发 可以创建一个每周每天同时触发，但排除周日的发布管道。 ## 12. 容器应用共享 开发团队通过 Docker 构建容器镜像并尝试通过 Kubernetes 托管以在互联网上共享，这种方式不正确。 ## 13. 容器镜像存储位置 可存储容器镜像的位置有： - Docker Hub - Azure Container Registry ## 14. 持续交付相关 ### 14.1 生产环境部署规则 公司使用 ServiceNow 作为变更管理系统，要确保在变更管理系统中没有有效变更记录时应用不部署到生产环境，可采取以下措施： - 添加部署门作为生产阶段部署的前置条件。 - 添加部署门作为 QA 阶段完成部署的后置条件。 ### 14.2 应用部署到本地虚拟机 将应用部署到 12 个本地虚拟机（分为 3 个子网），需执行以下操作： 1. 创建新的部署组并添加正确的代理到该组。 2. 在所有需要部署的虚拟机上下载并安装私有代理。 3. 在发布管道中添加部署组作业以执行部署应用所需的任务。 ### 14.3 生产环境部署条件配置 可以使用 Azure DevOps 管道配置发布管道，满足以下条件后再开始向生产环境部署： - 审批委员会的四个成员中至少有两个批准部署。 - 在发布后的第一小时检查 Azure Monitor 是否有警报。 ### 14.4 数据库架构迁移 使用 SQL Server Data Tools (SSDT) 进行数据库架构升级时，应使用基于最终状态的架构迁移。 ### 14.5 无架构数据库 使用无架构数据库并不能完全消除架构管理的问题。 ### 14.6 版本部署审批 团队规定新版本在部署到生产环境前必须由测试经理手动批准，最有意义的更改是在 QA 阶段添加需要测试经理给予的部署后批准。 ### 14.7 发布管道配置值重复使用 创建多个发布管道且许多管道对某些任务使用相同的配置值时，变量组可帮助重复使用这些值。 ### 14.8 自动生成发布说明 仅使用 Azure DevOps 的内置功能无法自动从部署完成的故事中生成发布说明。 ### 14.9 应用部署到 Azure Service Fabric 从 Azure DevOps 部署应用到 Azure Service Fabric 不需要安装扩展任务。 ### 14.10 Kubernetes 部署更新命令 在 Kubernetes 中应用部署更新应使用 `kubectl apply` 命令。 ### 14.11 Azure DevOps 部署容器到 Azure Kubernetes 在 Azure DevOps 中使用“Kubernetes Manifest”任务将容器部署到 Azure Kubernetes。 ### 14.12 部署资源到 Kubernetes 集群的文件 最适合将资源部署到 Kubernetes 集群的文件是 YAML 部署文件。 ## 15. 依赖管理 ### 15.1 共享 NuGet 包 使用 Azure Artifacts 托管 NuGet 包，要将一个包共享给组织内其他团队，以下解决方案有效： - 创建新的源并允许组织内任何用户使用该源的包，将共享包移动到该源。 - 在现有源中创建新视图，将共享包发布到该视图，并配置组织内所有成员可以从该视图读取包。 ### 15.2 拆分解决方案的理由 将解决方案拆分为多个较小的解决方案并使用共享包或库组装完整应用的有效理由有： - 代码库变得太大，编译和/或运行单元测试开始花费太长时间。 - 团队变得太大并分成两个，拆分解决方案可明确每个团队的所有权。 ### 15.3 Azure Artifacts 支持的上游源 Azure Artifacts 支持 Python 和 Maven 的上游源。 ### 15.4 消费公共 NuGet 包 通过现有源消费公共 NuGet 库时，可使用上游源。 ### 15.5 团队内共享库 团队内两个应用共享一个库的最佳策略是将库放在单独的存储库中，使用构建管道构建库并将其作为 NuGet 包上传到 Azure Artifacts，然后在两个应用中使用。 ### 15.6 通用包分发 可以使用通用包从 Azure DevOps 向不同的部署编排器分发应用组件。 ## 16. 应用基础设施 ### 16.1 应用多区域部署 应用要部署到两个不同的 Azure 区域以实现故障转移，有效的解决方案有： - 创建一个 ARM 模板和两个参数文件（分别对应两个区域），使用 ARM 模板更新基础设施。 - 先更新一个区域的基础设施，然后部署应用，成功后再更新另一个区域的基础设施并部署应用。 ### 16.2 部署 ARM 模板到资源组 使用 Azure DevOps 管道将 Azure Resource Manager 模板部署到 Azure 资源组，且部分参数存储在 Azure Key Vault 中，“给 Azure Active Directory 服务主体授予正确 Azure Key Vault 的 Reader RBAC 角色”不是完整解决方案的必要部分。 ### 16.3 创建和配置虚拟机 在 Azure 中创建和配置多个虚拟机，可使用 Azure Automation DSC 和 ARM 模板。 ### 16.4 服务主体 RBAC 角色分配 为从 Azure DevOps 管道进行部署的预创建服务主体分配“Contributor”RBAC 角色以部署资源。 ### 16.5 团队 RBAC 角色分配 设置团队的 RBAC 角色分配，遵循最小权限原则并确保需要的人可以访问团队资源，最佳解决方案是创建一个新的 Azure Active Directory 组，将用于部署的服务主体添加到该组，为该组分