手册

在授予业务部门管理自主权的同时，集中计费和策略实施。

→为每个业务部门使用一个Organization节点和对应的Folders。在Folders中创建项目。将所有项目链接到单个Billing Account。

原因: Folders提供管理边界和策略继承。单个Billing Account集中了成本管理并允许获得组织范围的折扣。

参考↗

当项目支出达到预算的特定百分比时通知财务部门。

→在Cloud Billing中，为项目创建一个Budget。设置多个警报阈值规则（例如50%、90%、100%），这些规则将通知发送到Pub/Sub主题或电子邮件。

原因: Budgets用于发出警报，而不是停止支出。要自动限制支出，Pub/Sub通知必须触发一个Cloud Function来禁用计费或关闭资源。

参考↗

分析细粒度的资源级云成本，并按成本中心跟踪支出。

→启用详细的计费导出到BigQuery数据集。对资源应用标签（例如`cost-center: "finance"`）。查询BigQuery表并按标签分组进行分析。

原因: 计费导出到BigQuery提供最详细的成本数据，包括标签，这对于自定义的费用分摊和费用展示模型至关重要。

参考↗

在组织内的所有项目上强制执行安全和配置标准（例如，限制资源位置、要求统一的存储桶访问、禁用公共IP）。

→在Organization或Folder级别应用Organization Policy约束。示例：`gcp.resourceLocations`用于数据驻留，`storage.uniformBucketLevelAccess`用于GCS安全，`compute.vmExternalIpAccess`用于防止公共IP。

原因: Organization policies是继承的，并提供预防性控制，在不合规操作发生之前将其阻止。这比反应性审计更有效。

参考↗

防止关键生产项目被意外删除。

→使用`gcloud alpha resource-manager liens create`对项目设置留置权。

原因: 留置权是一种阻止项目删除的属性。在项目可以被删除之前，必须由具有`resourcemanager.lienModifier`角色的用户明确移除它。

在使用gcloud CLI时，在不同项目和用户账户之间高效切换。

→使用`gcloud config configurations create`为每个项目/账户创建命名配置。使用`gcloud config configurations activate [CONFIG_NAME]`在它们之间切换。

原因: 配置存储了项目、账户、区域和可用区等设置，避免了在每个命令中指定它们的需要。

运行一个无状态、容器化的HTTP微服务，具有可变流量，同时最大限度地减少运营开销和成本。

→将容器部署到Cloud Run。

原因: Cloud Run是完全托管的，可以缩放到零（消除了空闲期的成本），并根据传入请求自动扩展。它非常适合无状态Web服务。

参考↗

以最低成本运行容错、时间灵活的批处理作业。

→在Managed Instance Group中使用Spot VMs（以前称为Preemptible VMs）。

原因: 与按需定价相比，Spot VMs可享受高达91%的折扣。它们适用于可以停止和重启的工作负载，例如许多批处理作业。

部署一个需要高可用性（例如99.9%）和自动扩展的Web应用程序。

→使用带有自动扩展策略的Regional Managed Instance Group (MIG)，部署在全球外部HTTP(S) Load Balancer之后。

原因: Regional MIG自动将实例分布到多个区域以实现容错。自动扩展根据需求调整容量，并且负载均衡器提供单个入口点。

存储数据，该数据在前30天内频繁访问，然后一年内不频繁访问，然后归档。

→存储在Cloud Storage Standard类存储桶中。创建生命周期规则，在30天后将对象转换为Nearline/Coldline，并在365天后转换为Archive。

原因: 生命周期规则通过根据年龄或其他条件将数据移动到更便宜的存储类别来自动化成本优化，无需手动干预。

参考↗

一个全球分布式应用程序需要一个具有横向可扩展性和强一致性的关系型数据库。

→使用Cloud Spanner。

原因: Cloud Spanner是唯一提供全球分布式、强一致性、支持SQL的关系型数据库的服务。Cloud SQL是区域性的。

应用程序需要一个具有99.95%可用性SLA和自动故障转移的托管PostgreSQL或MySQL数据库。

→使用已启用高可用性（HA）配置的Cloud SQL。

原因: HA配置在一个主实例和另一个可用区中的一个备用实例之间创建。数据是同步复制的，并且故障转移是自动的。

为三层应用程序（Web、应用、数据库）设计一个VPC，其中数据库层不能从互联网访问。

→创建一个自定义模式的VPC，每个层都有一个独立的子网。在专用子网中仅使用私有IP地址预配数据库实例。

原因: 在单独的子网中隔离各层允许细粒度的防火墙规则。数据库实例省略外部IP是防止互联网访问最直接的方法。

在GKE上部署需要稳定网络标识符和持久存储的有状态应用程序（例如数据库）。

→使用带有PersistentVolumeClaim模板的StatefulSet。

原因: StatefulSets专为有状态工作负载设计，提供稳定的主机名（例如`pod-0`、`pod-1`）并为每个副本自动预配唯一的PersistentVolume。

对延迟敏感的Cloud Run服务必须避免在流量高峰期间出现冷启动。

→部署服务时，将`--min-instances`标志设置为1或更高。

原因: 设置最小实例数可以使指定数量的容器保持“暖”状态并准备好处理请求，从而消除启动新容器所带来的延迟。

当新文件上传到Cloud Storage存储桶时，自动执行无服务器函数。

→部署一个Cloud Function（第二代），并在指定存储桶上使用Eventarc触发器来响应`google.cloud.storage.object.v1.finalized`事件。

原因: Eventarc提供统一的事件驱动架构。GCS触发器是连接存储事件到无服务器计算的标准管理方式，无需轮询。

部署App Engine应用程序的新版本进行测试，而无需立即将其用于生产流量。

→使用`gcloud app deploy --no-promote`部署新版本。

原因: `--no-promote`标志会创建新版本，但不会将任何流量转移到该版本。您可以使用其版本特定的URL进行测试，并在准备就绪时手动迁移流量。

为在Compute Engine实例上运行的Web应用程序创建全球HTTP(S)负载均衡器。

→按顺序创建以下组件：Instance Group（包含VM）、Health Check、Backend Service（指向IG和HC）、URL Map、Target HTTP(S) Proxy和Global Forwarding Rule（带有公共IP）。

原因: 此顺序正确地从后端（实例）到前端（转发规则）构建负载均衡器。每个组件在路由和健康检查中都有特定的用途。

团队需要协作管理Terraform状态，确保安全并防止并发修改。

→使用Cloud Storage存储桶作为Terraform后端。启用对象版本控制以实现历史记录和恢复。状态锁定由GCS后端自动处理。

原因: 远程GCS后端是GCP上团队协作的标准。它提供锁定以防止状态损坏，并提供版本控制以实现回滚功能。

当组中任何VM的CPU利用率在持续一段时间（例如5分钟）内超过80%时接收通知。

→在Cloud Monitoring中，创建一个Alerting Policy。将条件设置为`Metric: CPU utilization > 80%`，`Duration: 5 minutes`。配置一个通知渠道（例如电子邮件、PagerDuty）。

原因: Cloud Monitoring是创建基于指标的警报的本地服务。持续时间条件对于避免因短暂、正常的利用率峰值而导致的“抖动”警报至关重要。

为合规性保留特定审计日志7年，而其他日志保留30天。

→使用过滤器为审计日志创建一个日志接收器（log sink）。配置该接收器以导出到Cloud Storage存储桶。对存储桶应用7年保留策略。

原因: Cloud Logging的保留期有限（Admin Activity最长400天）。Log sink是将日志路由到长期、更便宜的存储（如GCS）或BigQuery进行分析的机制。

一个GKE pod处于`CrashLoopBackOff`状态。您需要查看容器崩溃前的日志。

→使用命令`kubectl logs [POD_NAME] --previous`。

原因: 当容器崩溃并重启时，`kubectl logs`会显示*新*容器的日志。`--previous`标志对于查看已终止实例的日志以诊断崩溃至关重要。

托管实例组必须自动替换无响应的实例。

→配置健康检查（例如HTTP、TCP）并将其应用于托管实例组的自动修复策略。

原因: MIG根据健康检查定期探测实例。如果实例连续多次检查失败，MIG会自动从模板中删除并重新创建该实例，确保应用程序可用性。

Cloud SQL数据库中发生了数据损坏事件。您需要将数据库恢复到事件发生前5分钟的状态。

→事先确保在该实例上启用了Point-in-Time Recovery (PITR)。执行恢复操作，指定要恢复到的精确时间戳。

原因: PITR依赖于启用二进制日志。它允许在保留窗口内对任何时间点进行精细恢复，这对于最大限度地减少数据丢失（低RPO）至关重要。

自动执行Compute Engine持久磁盘的每日备份并保留14天。

→为磁盘快照创建Resource Policy。配置每日计划和14天保留策略。将此策略附加到目标持久磁盘。

原因: 快照计划是自动化GCE备份的托管式“即用即弃”方式。这比使用cron作业或自定义脚本更可靠和可维护。

Compute Engine实例需要从Cloud Storage存储桶读取并写入BigQuery表。授予所需的最小权限。

→创建自定义服务账户。授予其`roles/storage.objectViewer`和`roles/bigquery.dataEditor`角色。将此服务账户附加到实例。

原因: 使用具有特定、预定义角色的自定义服务账户避免了默认Compute Engine服务账户过于宽松的性质，遵循了最小权限原则。

授予用户管理GCE实例但不能删除它们的权限。

→创建自定义IAM角色。从`roles/compute.instanceAdmin.v1`角色中获取权限，然后移除`compute.instances.delete`权限。

原因: 当预定义角色对于特定职位功能来说过于宽泛或过于严格时，自定义角色提供了授予精确权限集体的灵活性。

根据安全策略，开发人员需要SSH连接到没有外部IP地址的Compute Engine实例。

→授予开发人员`roles/iap.tunnelResourceAccessor`角色。然后他们可以使用`gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap`进行连接。

原因: Identity-Aware Proxy (IAP) TCP转发提供了一种安全、基于身份的方法，可以在没有堡垒主机、VPN或公共IP的情况下访问内部实例。

参考↗

仅允许来自公司办公室IP范围的入站SSH（端口22）流量到特定的VM。

→创建VPC防火墙规则，设置`direction: INGRESS`，`action: ALLOW`，`protocol/ports: tcp:22`，`source ranges: [CORPORATE_IP_CIDR]`，以及`target tags: [例如, "allow-ssh"]`。将标签应用于目标VM。

原因: 结合源范围和目标标签提供了一种精确且可扩展的方式来控制流量。它限制了*谁*可以连接以及*他们可以连接到什么*。

防止敏感BigQuery项目中的数据在有有效凭据的情况下，从受信任网络边界之外被复制或访问。

→配置VPC Service Controls。创建一个服务边界，其中包含敏感项目并限制BigQuery API。

原因: VPC Service Controls创建了一个虚拟“数据边界”，控制API级别的访问，为防火墙规则无法防御的数据泄露提供了强大的防御。

为第三方应用程序提供对Cloud Storage存储桶中特定私有对象的临时、有时限的读取访问权限。

→使用具有读取权限的服务账户，为对象生成一个带有短过期时间（例如15分钟）的Signed URL。

原因: Signed URL授予临时、按对象的访问权限，无需第三方拥有Google账户或IAM权限。这是此用例最安全的方法。

GKE pod需要安全地访问Google Cloud API（例如Pub/Sub），而无需将服务账户密钥存储为Kubernetes secrets。

→在GKE集群上启用Workload Identity。创建Google Service Account (GSA)和Kubernetes Service Account (KSA)。使用IAM策略将KSA绑定到GSA。配置pod以使用KSA。

原因: Workload Identity是GKE应用程序认证到Google Cloud服务的推荐无密钥方式。它将KSA身份映射到GSA身份，这比管理和轮换密钥文件更安全。

参考↗

组织策略要求Cloud Storage存储桶中的所有数据都使用组织控制的加密密钥进行加密。

→在Cloud KMS中创建一个加密密钥。创建Cloud Storage存储桶时，将此密钥指定为客户管理加密密钥 (CMEK)。

原因: CMEK让您可以控制用于加密的密钥，包括轮换和撤销，同时仍然利用Google的托管加密基础设施。

允许员工使用其现有的本地Active Directory凭据访问Google Cloud资源。

→配置Cloud Identity以使用SAML 2.0与Active Directory联邦。用户通过AD进行身份验证，然后AD向Google Cloud断言其身份以进行访问。

原因: 联邦允许单点登录 (SSO) 并将身份管理集中到现有的IdP (Active Directory) 中，避免了在Google Cloud中管理单独密码集的需要。

授予外部承包商对项目的临时访问权限，该权限应在30天后自动过期。

→将承包商添加为具有所需角色的IAM成员。在角色绑定中添加一个带有过期时间戳的条件（`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`）。

原因: IAM Conditions提供基于属性的访问控制。基于时间的条件非常适合临时访问，因为它们会自动撤销权限而无需手动清理。