Associate Cloud Engineer 练习题 — 云工程师 - 助理级

题目的核心需求有三点，一是运维团队成员需要Compute Engine实例的服务器管理权限，二是凭据部署效率要适配大量实例的管理场景，三是可审计追溯特定实例的访问人员，且前置条件是所有员工均已拥有Google账号。选项C采用Google Cloud原生的OS Login方案，将用户SSH公钥与个人Google账号绑定，通过为团队Google群组授予统一IAM角色的方式批量分配权限，无需逐实例配置密钥，部署效率极高，所有实例访问日志都会关联对应用户的Google账号，完美匹配所有需求，符合Google Cloud安全和运维最佳实践。 各选项分析： A. 错误。所有成员共用同一SSH密钥对，无法区分具体访问人，不满足溯源要求，私钥多人持有存在极高泄露风险，且逐实例配置公钥运维效率极低，不适配大量实例的管理场景。 B. 错误。手动收集各成员公钥后通过配置工具逐实例部署，运维成本高，后续人员入职离职需要批量更新所有实例的密钥配置，效率极低，且密钥与Google账号无原生绑定，溯源和权限管控的灵活性远低于OS Login方案。 C. 正确。该方案使用OS Login功能，用户将公钥添加到个人Google账号后，仅需为团队群组授予compute.osAdminLogin角色，即可批量开通所有成员的实例管理员权限，无需额外配置实例，部署高效，所有访问操作均可通过Google账号审计追溯，完全符合题目所有要求。 D. 错误。所有成员共用同一密钥对，无法追溯具体访问人员，不符合安全团队的审计要求，且共用私钥存在严重的安全隐患。 关键知识点： 1. OS Login功能：Google Cloud提供的Compute Engine访问管控功能，将用户SSH密钥与Google账号/Cloud Identity账号绑定，通过IAM角色统一管控实例访问权限，简化大规模场景下的SSH密钥管理，支持原生访问审计。 2. compute.osAdminLogin IAM角色：该角色授予用户以管理员身份，也就是拥有sudo权限，登录Compute Engine实例的权限，符合服务器运维的权限需求。 3. SSH密钥管理最佳实践：大规模实例运维场景下，优先使用OS Login替代手动维护实例/项目级SSH元数据的方案，可提升运维效率、降低安全风险、满足审计要求。 参考资料： 关于OS Login | Compute Engine 文档 | Google Cloud, https://cloud.google.com/compute/docs/oslogin Compute Engine IAM 角色 | Compute Engine 文档 | Google Cloud, https://cloud.google.com/compute/docs/access/iam#os_login_roles

本题要求创建自定义VPC下范围尽可能大的单个子网，首先VPC子网必须使用RFC1918定义的私有IP地址段，不能使用公网或特殊保留地址。CIDR地址块的大小由前缀位数决定，前缀位数越少，地址空间越大。RFC1918规定的三个私有地址段中，10.0.0.0/8的前缀位数最少，地址空间最大，完全符合Google Cloud VPC子网的地址使用规范，因此选择该选项。 各选项分析： A. 0.0.0.0/0是代表所有IP地址的默认路由CIDR，属于特殊保留段，禁止作为VPC子网的地址范围使用，因此错误。 B. 10.0.0.0/8是RFC1918定义的A类私有地址段，包含16777216个IP地址，是三个私有地址段中范围最大的，完全满足GCP VPC子网的使用要求，符合题目尽可能大的需求，因此正确。 C. 172.16.0.0/12是RFC1918定义的B类私有地址段，仅包含1048576个IP地址，地址范围远小于10.0.0.0/8，不符合尽可能大的要求，因此错误。 D. 192.168.0.0/16是RFC1918定义的C类私有地址段，仅包含65536个IP地址，是三个私有地址段中范围最小的，不符合题目要求，因此错误。 关键知识点： 1. RFC1918私有地址规范，明确了三类可用于私有网络包括云VPC的IP地址段，是云网络地址规划的核心依据。 2. Google Cloud VPC子网地址要求，规定VPC子网必须使用合规的私有IP段，禁止使用0.0.0.0/0等特殊保留段作为子网CIDR。 3. CIDR地址块大小计算规则，CIDR前缀的数字越小，对应的地址块包含的IP数量越多，地址范围越大。 参考资料： Google Cloud VPC子网概述, https://cloud.google.com/vpc/docs/subnets Google Cloud VPC IP地址规划指南

首先梳理题目所有需求点，包括经济高效的关系型数据方案、单一地理位置部署、承载少量运营数据、支持时间点恢复。首先从数据库选型角度，Cloud SQL是GCP提供的托管轻量级关系型数据库服务，适配单区域中小规模负载，成本远低于Cloud Spanner，完全匹配少量数据、单地域、经济高效的要求。针对时间点恢复需求，Cloud SQL for MySQL的时间点恢复能力依赖二进制日志的启用，开启后即可实现指定时间范围内的任意时间点数据恢复，完全满足所有需求，因此正确答案为A。 各选项分析： A. 选项A正确，Cloud SQL是适配单区域少量运营数据的高性价比托管关系型数据库，Cloud SQL for MySQL的时间点恢复功能必须基于二进制日志启用才能实现，该配置完全覆盖题目所有要求。 B. 选项B错误，故障转移副本的作用是提升实例高可用性，避免单实例故障导致服务中断，无法实现时间点恢复的需求，同时额外部署故障转移副本会增加成本，不符合经济高效的要求。 C. 选项C错误，Cloud Spanner是面向大规模分布式高一致性负载的企业级关系型数据库，单位资源成本远高于Cloud SQL，针对少量运营数据的场景会造成成本浪费，不符合经济高效的选型要求。 D. 选项D错误，首先多区域实例不符合题目单一地理位置的部署要求，其次多区域Cloud Spanner成本进一步提升，完全不匹配少量数据、经济高效的需求。 关键知识点： 1. Cloud SQL for MySQL的时间点恢复实现逻辑：时间点恢复功能依赖二进制日志的启用，最多支持恢复到过去7天内的任意时间点。 2. GCP关系型数据库选型规则：中小规模、单区域的常规关系型负载优先选择成本更低的Cloud SQL，大规模、全球分布、需要强一致高可用的负载选择Cloud Spanner。 3. 时间点恢复与故障转移的功能差异：时间点恢复用于解决数据误操作、数据损坏等逻辑故障的回溯需求，故障转移用于解决实例硬件/区域故障导致的服务不可用问题，二者适用场景完全不同。 参考资料： Cloud SQL for MySQL 时间点恢复官方文档, https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr GCP 数据库服务选型指南

本题的核心需求是实现无响应虚拟机的自动重建，且操作步骤最少。Google Cloud中只有托管实例组（MIG）原生支持自动修复功能，无需依赖额外服务即可实现根据运行状况检查结果重建故障实例。你可以在托管实例组的自动修复配置中自定义运行状况检查参数，比如设置检查间隔为10秒、连续3次检查失败即判定实例不健康，触发自动重建，完全匹配题目要求，同时不需要额外配置多余组件，符合步骤最少的要求。 各选项分析： A. 错误。HTTP负载均衡的健康检查仅用于判断实例是否可以接收流量，只会将不健康的实例移出流量分发列表，不会触发实例的自动重建操作，无法满足自动修复的需求。 B. 错误。设置负载均衡的最大RPS阈值是用于控制流量分发的策略，和实例自动修复完全无关，且负载均衡本身不具备重建实例的能力，无法满足需求。 C. 正确。托管实例组的自动修复功能专门用于故障实例的自动重建，你可以为其绑定HTTP类型的运行状况检查，自定义设置检查间隔10秒、连续3次失败即触发重建，完全满足题目所有需求，且不需要额外配置其他组件，步骤最少。 D. 错误。自动伸缩功能是根据负载情况动态调整实例组的实例数量，和故障实例的自动修复没有关联，仅启用自动伸缩不会自动重建无响应的虚拟机，无法满足需求。 关键知识点： 1. 托管实例组自动修复功能：Google Cloud托管实例组支持基于运行状况检查结果自动重建不健康的实例，保障工作负载的可用性，是实现实例自愈的核心方案。 2. 运行状况检查配置规则：运行状况检查支持自定义间隔时间、成功阈值、失败阈值等参数，可适配不同业务的故障判定规则。 3. 负载均衡与MIG健康检查的区别：负载均衡的健康检查仅用于流量调度，不会修改实例本身，MIG自动修复关联的健康检查才会触发不健康实例的重建操作。 参考资料： 托管实例组自动修复不健康实例, 运行状况检查概览

本题考察GCP中GKE集群本地配置的管理能力，首先明确gcloud CLI的配置和kubectl的Kubernetes访问配置是两套独立的体系，已配置的GKE集群的访问信息全部存储在kubeconfig文件中，由kubectl相关命令管理。题目要求尽可能少的步骤查看非活动的已配置GKE集群，首先通过kubectl config use-context切换到该非活动集群对应的上下文，再通过kubectl config view即可查看该集群的完整配置信息，无需修改gcloud的活动配置，操作步骤最少且精准命中需求。 各选项分析： A. gcloud config configurations describe命令用于查看指定gcloud配置的属性集合，仅包含gcloud CLI的默认项目、区域、账号等配置，不存储GKE集群的访问配置信息，无法查看目标集群，因此错误。 B. 激活gcloud配置再查看gcloud配置列表的操作，仅能获取gcloud CLI本身的配置，无法得到GKE集群的配置信息，且操作步骤冗余，因此错误。 C. kubectl config get-contexts仅能列出kubeconfig中所有上下文的简要元数据（上下文名、集群名、用户名等），无法查看集群的完整配置细节，不满足查看已配置集群的需求，因此错误。 D. kubectl config use-context可以直接切换到目标非活动GKE集群对应的上下文，无需修改gcloud的活动配置，再通过kubectl config view即可获取该集群的完整配置信息，步骤最少且符合需求，因此正确。 关键知识点： 1. gcloud配置与kubectl的kubeconfig配置相互独立，gcloud配置管理gcloud CLI的默认行为，kubeconfig管理所有Kubernetes集群的访问凭证与端点配置。 2. kubectl config系列命令中，get-contexts用于列出上下文简要信息，view用于查看完整kubeconfig配置，use-context用于切换当前生效的上下文。 3. 已完成访问配置的GKE集群信息会持久化存储在本地kubeconfig文件中，无需对应gcloud配置处于活动状态即可通过kubectl命令管理其配置。 参考资料： 配置对GKE集群的访问权限, https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl kubectl上下文与配置, https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration