google-cloud-recipe-foundation-builder

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Google Cloud Recipe: Foundation Builder

Google Cloud 方案：基础架构构建器

[!WARNING] This skill is currently in a preview state. It will deploy a secure foundation, but does not have all advanced features. Users who want more options should visit Google Cloud Setup.

This skill guides the setup of a secure, enterprise-grade Google Cloud landing zone foundation. It establishes baseline security controls, organizes the initial resource hierarchy, and configures centralized audit logging and cross-environment monitoring.

[!WARNING] 此技能目前处于预览状态。它将部署安全基础架构，但尚未具备所有高级功能。需要更多选项的用户请访问Google Cloud Setup。

本技能指导搭建安全的企业级Google Cloud着陆区基础架构，建立基线安全控制措施，规划初始资源层级，并配置集中式审计日志与跨环境监控。

Overview

概述

The recipe provisions the following core components at the organization root:

Security Guardrails: Enforces 17 baseline Google Cloud Organization Policies to secure the environment (13 Boolean, 4 List constraints).
Resource Hierarchy: Establishes 4 folders (
```
Common
```
,
```
Production
```
,
```
Non-Production
```
,
```
Development
```
) and provisions corresponding projects sequentially with globally unique ID prefixes (
```
logging-
```
,
```
prod-
```
,
```
non-prod-
```
,
```
dev-
```
followed by a shared suffix).
Billing & API Enablement: Links all projects to your billing account and activates critical logging/monitoring services.
Centralized Logging & Monitoring: Deploys a global, centralized log bucket with 30-day retention, configures an organization-wide audit log sink, and sets up a cross-environment metrics scope.

本方案将在组织根节点部署以下核心组件：

安全护栏：强制执行17项Google Cloud基线Organization Policies（13项布尔约束、4项列表约束）以保障环境安全。
资源层级：创建4个文件夹（
```
Common
```
、
```
Production
```
、
```
Non-Production
```
、
```
Development
```
），并按顺序创建带有全局唯一ID前缀的对应项目（前缀为
```
logging-
```
、
```
prod-
```
、
```
non-prod-
```
、
```
dev-
```
，后跟统一后缀）。
账单与API启用：将所有项目关联至您的账单账户，并激活关键日志/监控服务。
集中式日志与监控：部署一个保留期为30天的全局集中式日志桶，配置组织级审计日志接收器，并设置跨环境指标范围。

Clarifying Questions

确认问题

Before executing this recipe, the agent must gather the following details:

Organization ID: Run
```
gcloud organizations list
```
to retrieve the available organizations, present them to the user, and ask them to select the target Organization ID.
Billing Account ID: Run
```
gcloud billing accounts list --filter=open=true
```
to retrieve only the active (open) billing accounts, present them to the user, and ask them to select the active Billing Account ID.
Project ID Suffix: Ask if the user has a preferred prefix or target suffix for Project IDs (default uses prefix + a shared random 8-character string, e.g.,
```
prod-ab12cd34
```
).
Log Bucket Region: Ask for the target region for resources if they want to override the default
```
global
```
log bucket location.

执行本方案前，Agent必须收集以下信息：

Organization ID（组织ID）：运行
```
gcloud organizations list
```
获取可用组织列表，展示给用户并请其选择目标Organization ID。
Billing Account ID（账单账户ID）：运行
```
gcloud billing accounts list --filter=open=true
```
获取仅活跃（开放）的账单账户列表，展示给用户并请其选择活跃Billing Account ID。
Project ID Suffix（项目ID后缀）：询问用户是否有偏好的项目ID前缀或目标后缀（默认使用前缀+8位随机字符串，例如
```
prod-ab12cd34
```
）。
Log Bucket Region（日志桶区域）：询问用户是否要覆盖默认的
```
global
```
日志桶位置，指定资源的目标区域。

Prerequisites

前置条件

Ensure the following prerequisites are met before beginning the deployment:

GCP Identity: You must have a Google Cloud Organization resource set up.
Administrative IAM Roles: The identity executing these commands must hold the required administrative permissions. If any step fails with a
```
Permission Denied
```
error, the agent will attempt to self-remediate by granting the corresponding recommended role as detailed in Phase 2: Error Recovery & Lazy Role Remediation Strategy.
Tools: The
```
gcloud
```
CLI must be installed, authorized with the above identity, and configured for use.

开始部署前，请确保满足以下前置条件：

GCP身份：您已创建Google Cloud组织资源。
管理员IAM角色：执行命令的身份需具备必要的管理员权限。若任何步骤因
```
Permission Denied
```
（权限不足）失败，Agent将尝试通过授予阶段2：错误恢复与延迟角色修复策略中详述的推荐角色进行自我修复。
工具：已安装
```
gcloud
```
CLI，使用上述身份完成授权并配置就绪。

Steps to Complete the Recipe

方案执行步骤

Phase 1: Pre-flight Confirmation

阶段1：预执行确认

Identify the target organization and obtain explicit user approval before making changes.

Identify and Discover Organization: Verify the target organization. If only the display name is known, list organizations to find the ID. Then, retrieve the organization metadata to dynamically calculate the Directory Customer ID and Domain Name:
bash
```
# List to find ID if needed
gcloud organizations list

# Describe the organization to retrieve metadata
gcloud organizations describe [ORGANIZATION_ID]
```
Calculate values:
- Domain Name (
```
[ORG_NAME]
```
  /
```
[YOUR_DOMAIN]
```
  ): Use the
```
displayName
```
  value from the output (e.g.,
```
my-business.com
```
  ).
- Customer ID (
```
[DIRECTORY_CUSTOMER_ID]
```
  ): Use the
```
owner.directoryCustomerId
```
  value from the output (e.g.,
```
C01234567
```
  ).
Present Blueprint Summary: Present the exact details of the blueprint to the user and request confirmation to proceed:
Proposed Foundation Deployment Summary for Organization:
[ORG_NAME]
(
[ORGANIZATION_ID]
)
- Security: Enforce 17 baseline Organization Policies (13 Boolean, 4 List).
- Folders: Create 4 folders sequentially (
```
Common
```
  ,
```
Production
```
  ,
```
Non-Production
```
  ,
```
Development
```
  ).
- Projects: Create 4 projects sequentially with unique IDs (
```
logging-[SUFFIX]
```
  ,
```
prod-[SUFFIX]
```
  ,
```
non-prod-[SUFFIX]
```
  ,
```
dev-[SUFFIX]
```
  ).
- Billing: Link all projects to Billing Account
```
[BILLING_ACCOUNT_ID]
```
  .
- APIs: Enable Logging and Monitoring APIs on the central project.
- Centralized Logging: Deploy a
```
global
```
  log bucket
```
[ORG_NAME]-logging
```
  (30-day retention), configure an organization-level sink
```
[ORGANIZATION_ID]-logbucketsink-[RANDOM_HEX]
```
  , and establish cross-project metrics scopes.
Do you wish to proceed with this deployment? (Yes/No)

[!IMPORTANT] Pause execution and wait for explicit user approval before moving to Phase 2. If the user declines, abort the operation.

确定目标组织并在进行更改前获取用户明确批准。

识别与发现组织：验证目标组织。若仅知晓显示名称，可列出组织以查找ID。然后获取组织元数据，动态计算Directory Customer ID（目录客户ID）与Domain Name（域名）：
bash
```
# 如需查找ID，运行列表命令
gcloud organizations list

# 获取组织元数据
gcloud organizations describe [ORGANIZATION_ID]
```
计算值：
- Domain Name（域名）（
```
[ORG_NAME]
```
  /
```
[YOUR_DOMAIN]
```
  ）：使用输出中的
```
displayName
```
  值（例如
```
my-business.com
```
  ）。
- Customer ID（客户ID）（
```
[DIRECTORY_CUSTOMER_ID]
```
  ）：使用输出中的
```
owner.directoryCustomerId
```
  值（例如
```
C01234567
```
  ）。
展示蓝图摘要：向用户展示蓝图的详细信息并请求确认继续：
组织
[ORG_NAME]
（
[ORGANIZATION_ID]
）的拟议基础架构部署摘要
- 安全：强制执行17项基线Organization Policies（13项布尔约束、4项列表约束）。
- 文件夹：按顺序创建4个文件夹（
```
Common
```
  、
```
Production
```
  、
```
Non-Production
```
  、
```
Development
```
  ）。
- 项目：按顺序创建4个带有唯一ID的项目（
```
logging-[SUFFIX]
```
  、
```
prod-[SUFFIX]
```
  、
```
non-prod-[SUFFIX]
```
  、
```
dev-[SUFFIX]
```
  ）。
- 账单：将所有项目关联至账单账户
```
[BILLING_ACCOUNT_ID]
```
  。
- API：在中心项目启用日志与监控API。
- 集中式日志：部署全局日志桶
```
[ORG_NAME]-logging
```
  （保留期30天），配置组织级接收器
```
[ORGANIZATION_ID]-logbucketsink-[RANDOM_HEX]
```
  ，并建立跨项目指标范围。
是否继续此部署？（是/否）

[!IMPORTANT] 暂停执行，等待用户明确批准后再进入阶段2。若用户拒绝，终止操作。

Phase 2: Error Recovery & Lazy Role Remediation Strategy

阶段2：错误恢复与延迟角色修复策略

To ensure deployment continues smoothly on clean organizations without requiring complex upfront permission checks (which require a quota project), the agent must adopt a "lazy recovery" approach.

Instead of testing permissions in advance, the agent will attempt to execute each step in the recipe. If a step fails with a

Permission Denied

error, the agent will attempt to self-remediate by granting the corresponding recommended administrative group of roles to the deployment identity and retrying the operation.

[!IMPORTANT] When asked about pre-deployment readiness, prerequisites, or checks to run, the agent must explicitly explain that the landing zone deployment adopts a lazy role remediation strategy rather than upfront testing, detailing all of the following in its response: 1. Confirm it will execute deployment commands directly, catching any Permission Denied errors. 2. Confirm it will attempt to self-remediate on failure by running the exact commands
gcloud organizations add-iam-policy-binding
or
gcloud billing accounts add-iam-policy-binding
to grant the entire administrative group of roles to the active identity, and then retry the failed deployment command. 3. List the core administrative groups that it will attempt to grant (Organization Admin Group, Billing Admin Group, and Security Admin Group) mapped to their key roles. 4. Confirm it will halt execution and request manual administrator intervention if the self-remediation grant command fails.

为确保在全新组织中顺利部署，无需复杂的前置权限检查（需配额项目），Agent必须采用“延迟恢复”方法。

Agent不会预先测试权限，而是直接执行方案中的每一步。若步骤因

Permission Denied

失败，Agent将尝试通过为部署身份授予对应推荐管理员角色组并重新执行操作进行自我修复。

[!IMPORTANT] 当被问及部署前准备情况、前置条件或需运行的检查时，Agent必须明确说明着陆区部署采用延迟角色修复策略而非前置测试，并在回复中详述以下内容：1. 确认将直接执行部署命令，捕获任何Permission Denied错误。2. 确认失败时将尝试自我修复，运行
gcloud organizations add-iam-policy-binding
或
gcloud billing accounts add-iam-policy-binding
命令，为当前身份授予完整管理员角色组，然后重试失败的部署命令。3. 列出将尝试授予的核心管理员组（组织管理员组、账单管理员组、安全管理员组）及其对应关键角色。4. 确认若自我修复的授权命令失败，将停止执行并请求管理员手动干预。

Remediation Protocol

修复流程

For any command that fails due to missing permissions:

Identify Required Admin Group: Determine which administrative group is responsible for the failed action. Refer to the Administrative IAM Reference for details.
Attempt Self-Remediation: Grant all roles belonging to that administrative group to the active authenticated account sequentially. Refer to the Administrative IAM Reference Remediation Guide for the copy-pasteable script commands:
- For Organization/Folder level failures (Org Admin Group or Security Admin Group): Run
```
gcloud organizations add-iam-policy-binding
```
  sequentially for each role in the group.
- For Billing level failures (Billing Admin Group): Run
```
gcloud billing accounts add-iam-policy-binding
```
  sequentially for each role in the group.
Halt on Remediation Failure:
- If the grant commands succeed, immediately retry the failed deployment command.
- If any of the grant commands fail (e.g., due to lack of
```
setIamPolicy
```
  admin rights), halt execution and instruct the user to ask their Organization/Billing Administrator to manually grant the entire administrative group of roles.

任何因权限缺失失败的命令：

确定所需管理员组：确定负责失败操作的管理员组。详情请参考Administrative IAM Reference。
尝试自我修复：按顺序为当前认证账户授予该管理员组的所有角色。可参考Administrative IAM Reference Remediation Guide中的可复制脚本命令：
- 组织/文件夹级失败（组织管理员组或安全管理员组）：按顺序为组内每个角色运行
```
gcloud organizations add-iam-policy-binding
```
  命令。
- 账单级失败（账单管理员组）：按顺序为组内每个角色运行
```
gcloud billing accounts add-iam-policy-binding
```
  命令。
修复失败则停止：
- 若授权命令成功，立即重试失败的部署命令。
- 若任何授权命令失败（例如因缺少
```
setIamPolicy
```
  管理员权限），停止执行并指导用户联系组织/账单管理员手动授予完整管理员角色组。

Phase-Specific Remediation Mapping

阶段特定修复映射

Phase 3: Security Guardrails (Org Policies):
- If
```
gcloud org-policies set-policy
```
  fails: Attempt to grant the entire Organization Admin Group (9 roles) at the organization level.
Phase 4: Resource Hierarchy (Folders & Projects):
- If
```
gcloud resource-manager folders create
```
  or
```
gcloud projects create
```
  fails: Attempt to grant the entire Organization Admin Group (9 roles) at the organization level.
Phase 4: Billing Link:
- If
```
gcloud billing projects link
```
  fails: Attempt to grant the entire Billing Admin Group (3 roles) at the billing account level, and ensure the active identity is granted the Organization Admin Group (which contains
```
roles/billing.user
```
  ) at the organization level.
Phase 5: Centralized Logging & Monitoring:
- If
```
gcloud logging sinks create
```
  fails at org level: Attempt to grant the entire Logging/Monitoring Admin Group (2 roles:
```
roles/logging.admin
```
  ,
```
roles/monitoring.admin
```
  ) and the Security Admin Group (9 roles) at the organization level.

阶段3：安全护栏（组织策略）：
- 若
```
gcloud org-policies set-policy
```
  失败：尝试在组织级别授予完整组织管理员组（9个角色）。
阶段4：资源层级（文件夹与项目）：
- 若
```
gcloud resource-manager folders create
```
  或
```
gcloud projects create
```
  失败：尝试在组织级别授予完整组织管理员组（9个角色）。
阶段4：账单关联：
- 若
```
gcloud billing projects link
```
  失败：尝试在账单账户级别授予完整账单管理员组（3个角色），并确保当前身份在组织级别被授予组织管理员组（包含
```
roles/billing.user
```
  角色）。
阶段5：集中式日志与监控：
- 若
```
gcloud logging sinks create
```
  在组织级别失败：尝试在组织级别授予完整日志/监控管理员组（2个角色：
```
roles/logging.admin
```
  、
```
roles/monitoring.admin
```
  ）与安全管理员组（9个角色）。

Phase 3: Security Guardrails (Org Policies)

阶段3：安全护栏（组织策略）

Apply 17 baseline security controls at the organization root.

[!CAUTION] Applying
iam.allowedPolicyMemberDomains
first can lock out the deployment identity if it resides in an unallowed domain. Ensure the deployment identity is safe before enforcing this policy.

Generate the YAML configuration files for the 17 policies. Refer to the Organization Policies Reference for the exact YAML templates for both Boolean and List constraints.

Apply each organization policy sequentially using the

gcloud org-policies

tool:

bash

gcloud org-policies set-policy [POLICY_FILE_NAME].yaml

在组织根节点应用17项基线安全控制措施。

[!CAUTION] 先应用
iam.allowedPolicyMemberDomains
可能会锁定部署身份（若其所在域名未被允许）。执行此策略前请确保部署身份安全。

为17项策略生成YAML配置文件。布尔约束与列表约束的精确YAML模板请参考Organization Policies Reference。

使用

gcloud org-policies

工具按顺序应用每个组织策略：

bash

gcloud org-policies set-policy [POLICY_FILE_NAME].yaml

Phase 4: Resource Hierarchy

阶段4：资源层级

1. Folder Creation

1. 文件夹创建

Check if target folders exist to avoid duplication. The agent must check for all 4 folders: for any folder that already exists (e.g., if

Common

Production

are already present), the agent must locate and reuse them; for any folder that is missing (e.g., if

Non-Production

Development

are not present), the agent must proceed to sequentially create them:

[!IMPORTANT] When explaining how existing resources (folders and projects) are handled to prevent duplication, the agent must explicitly name the remaining missing folders (
Non-Production
and
Development
) and confirm that it will proceed to sequentially create only these missing folders and projects.

bash

undefined

检查目标文件夹是否存在以避免重复。Agent必须检查全部4个文件夹：若任何文件夹已存在（例如

Common

或

Production

已存在），Agent必须找到并复用；若任何文件夹缺失（例如

Non-Production

或

Development

不存在），Agent必须按顺序创建：

[!IMPORTANT] 向用户说明如何处理现有资源（文件夹与项目）以避免重复时，Agent必须明确列出剩余缺失的文件夹（
Non-Production
与
Development
），并确认将仅按顺序创建这些缺失的文件夹与项目。

bash

undefined

Check and Create "Common" Folder

检查并创建"Common"文件夹

gcloud resource-manager folders list --organization=[ORGANIZATION_ID] --filter="display_name=Common"

If not present:

若不存在：

gcloud resource-manager folders create --display-name="Common" --organization=[ORGANIZATION_ID]

Check and Create "Production" Folder

检查并创建"Production"文件夹

gcloud resource-manager folders list --organization=[ORGANIZATION_ID] --filter="display_name=Production"

If not present:

若不存在：

gcloud resource-manager folders create --display-name="Production" --organization=[ORGANIZATION_ID]

Check and Create "Non-Production" Folder

检查并创建"Non-Production"文件夹

gcloud resource-manager folders list --organization=[ORGANIZATION_ID] --filter="display_name=Non-Production"

If not present:

若不存在：

gcloud resource-manager folders create --display-name="Non-Production" --organization=[ORGANIZATION_ID]

Check and Create "Development" Folder

检查并创建"Development"文件夹

gcloud resource-manager folders list --organization=[ORGANIZATION_ID] --filter="display_name=Development"

If not present:

若不存在：

gcloud resource-manager folders create --display-name="Development" --organization=[ORGANIZATION_ID]

undefined

gcloud resource-manager folders create --display-name="Development" --organization=[ORGANIZATION_ID]

undefined

2. Project Creation and Billing Link

2. 项目创建与账单关联

Check if target projects already exist in the folders by matching their display names. If not present, generate a shared 8-character random suffix (e.g.,

ab12cd34

) and create the projects sequentially, linking billing and enabling APIs immediately:

bash

undefined

通过匹配显示名称检查目标文件夹中是否已存在对应项目。若不存在，生成8位随机共享后缀（例如

ab12cd34

）并按顺序创建项目，同时关联账单并立即启用API：

bash

undefined

Check if "central-logging-monitoring" project exists in Common folder

检查Common文件夹中是否存在"central-logging-monitoring"项目

gcloud projects list --filter="parent.id=[COMMON_FOLDER_ID] AND parent.type=folder AND name=central-logging-monitoring"

If not present: Create, link billing, and enable APIs

若不存在：创建、关联账单并启用API

gcloud projects create logging-[SUFFIX] --name="central-logging-monitoring" --folder=[COMMON_FOLDER_ID] gcloud billing projects link logging-[SUFFIX] --billing-account=[BILLING_ACCOUNT_ID] gcloud services enable compute.googleapis.com logging.googleapis.com monitoring.googleapis.com --project=logging-[SUFFIX]

Check if "production" project exists in Production folder

检查Production文件夹中是否存在"production"项目

gcloud projects list --filter="parent.id=[PRODUCTION_FOLDER_ID] AND parent.type=folder AND name=production"

If not present: Create, link billing, and enable APIs

若不存在：创建、关联账单并启用API

gcloud projects create prod-[SUFFIX] --name="production" --folder=[PRODUCTION_FOLDER_ID] gcloud billing projects link prod-[SUFFIX] --billing-account=[BILLING_ACCOUNT_ID] gcloud services enable compute.googleapis.com run.googleapis.com container.googleapis.com artifactregistry.googleapis.com firestore.googleapis.com pubsub.googleapis.com aiplatform.googleapis.com cloudaicompanion.googleapis.com apphub.googleapis.com designcenter.googleapis.com discoveryengine.googleapis.com iam.googleapis.com config.googleapis.com cloudbuild.googleapis.com cloudasset.googleapis.com cloudkms.googleapis.com cloudresourcemanager.googleapis.com --project=prod-[SUFFIX]

Check if "non-production" project exists in Non-Production folder

检查Non-Production文件夹中是否存在"non-production"项目

gcloud projects list --filter="parent.id=[NON_PRODUCTION_FOLDER_ID] AND parent.type=folder AND name=non-production"

If not present: Create, link billing, and enable APIs

若不存在：创建、关联账单并启用API

gcloud projects create non-prod-[SUFFIX] --name="non-production" --folder=[NON_PRODUCTION_FOLDER_ID] gcloud billing projects link non-prod-[SUFFIX] --billing-account=[BILLING_ACCOUNT_ID] gcloud services enable compute.googleapis.com run.googleapis.com container.googleapis.com artifactregistry.googleapis.com firestore.googleapis.com pubsub.googleapis.com aiplatform.googleapis.com cloudaicompanion.googleapis.com apphub.googleapis.com designcenter.googleapis.com discoveryengine.googleapis.com iam.googleapis.com config.googleapis.com cloudbuild.googleapis.com cloudasset.googleapis.com cloudkms.googleapis.com cloudresourcemanager.googleapis.com --project=non-prod-[SUFFIX]

Check if "development" project exists in Development folder

检查Development文件夹中是否存在"development"项目

gcloud projects list --filter="parent.id=[DEVELOPMENT_FOLDER_ID] AND parent.type=folder AND name=development"

If not present: Create, link billing, and enable APIs

若不存在：创建、关联账单并启用API

gcloud projects create dev-[SUFFIX] --name="development" --folder=[DEVELOPMENT_FOLDER_ID] gcloud billing projects link dev-[SUFFIX] --billing-account=[BILLING_ACCOUNT_ID] gcloud services enable compute.googleapis.com run.googleapis.com container.googleapis.com artifactregistry.googleapis.com firestore.googleapis.com pubsub.googleapis.com aiplatform.googleapis.com cloudaicompanion.googleapis.com apphub.googleapis.com designcenter.googleapis.com discoveryengine.googleapis.com iam.googleapis.com config.googleapis.com cloudbuild.googleapis.com cloudasset.googleapis.com cloudkms.googleapis.com cloudresourcemanager.googleapis.com --project=dev-[SUFFIX]


> [!NOTE] **Agentic Parallelism Option**: While the manual runbook enforces
> sequential project execution to avoid terminal race conditions, an AI agent
> with multi-agent orchestration capability may optionally spawn subagents to
> provision the 4 projects in parallel once folder IDs are resolved.


> [!NOTE] **Agent并行执行选项**：手动执行手册要求按顺序创建项目以避免终端竞争条件，但具备多Agent编排能力的AI Agent可在解析文件夹ID后，选择生成子Agent并行部署4个项目。

Phase 5: Centralized Logging and Monitoring

阶段5：集中式日志与监控

Configure centralized audit logging and cross-project monitoring scope in the

logging-[SUFFIX]

project.

Refer to the Centralized Logging and Monitoring Reference for the detailed step-by-step commands to:

Create the central log bucket.
Create the organization-wide log sink.
Grant required IAM permissions to the log sink.
Configure the cross-project monitoring metrics scope.

在

logging-[SUFFIX]

项目中配置集中式审计日志与跨项目监控范围。

详细步骤命令请参考Centralized Logging and Monitoring Reference，包括：

创建中心日志桶。
创建组织级日志接收器。
为日志接收器授予必要的IAM权限。
配置跨项目监控指标范围。

Validation Logic & Checklist

验证逻辑与检查清单

Evaluate the deployment against the following verification checks:

Security Policies: Run
```
gcloud org-policies list --organization=[ORGANIZATION_ID]
```
and verify all 17 target policies are enforced or correctly configured.
Resource Folders: Verify folders
```
Common
```
,
```
Production
```
,
```
Non-Production
```
, and
```
Development
```
exist under the organization root.
Billing Linkage: Run
```
gcloud billing projects list
```
and assert that all 4 newly created projects are linked to your billing account.
Log Bucket & Retention: Verify the log bucket
```
[ORG_NAME]-logging
```
exists in project
```
logging-[SUFFIX]
```
, is located in
```
global
```
, and has a retention period of exactly 30 days.
Log Sink Routing: Run
```
gcloud logging sinks describe
```
at the organization level and confirm the sink routes cloud audit logs to the global bucket and holds standard
```
writerIdentity
```
credentials.
Metrics Scope Linkage: Run
```
gcloud beta monitoring metrics-scopes describe
```
and assert that the
```
dev
```
,
```
non-prod
```
, and
```
prod
```
projects appear in the monitored list of the central
```
logging
```
project.

通过以下验证检查评估部署结果：

安全策略：运行
```
gcloud org-policies list --organization=[ORGANIZATION_ID]
```
，验证所有17个目标策略已生效或配置正确。
资源文件夹：验证
```
Common
```
、
```
Production
```
、
```
Non-Production
```
与
```
Development
```
文件夹存在于组织根节点下。
账单关联：运行
```
gcloud billing projects list
```
，确认所有4个新建项目已关联至您的账单账户。
日志桶与保留期：验证
```
logging-[SUFFIX]
```
项目中存在日志桶
```
[ORG_NAME]-logging
```
，位置为
```
global
```
，且保留期恰好为30天。
日志接收器路由：在组织级别运行
```
gcloud logging sinks describe
```
，确认接收器将云审计日志路由至全局桶，并持有标准
```
writerIdentity
```
凭证。
指标范围关联：运行
```
gcloud beta monitoring metrics-scopes describe
```
，确认
```
dev
```
、
```
non-prod
```
与
```
prod
```
项目出现在中心
```
logging
```
项目的监控列表中。

google-cloud-recipe-foundation-builder

Original

Translation

Google Cloud Recipe: Foundation Builder

Google Cloud 方案：基础架构构建器

Overview

概述

Clarifying Questions

确认问题

Prerequisites

前置条件

Steps to Complete the Recipe

方案执行步骤

Phase 1: Pre-flight Confirmation

阶段1：预执行确认

Phase 2: Error Recovery & Lazy Role Remediation Strategy

阶段2：错误恢复与延迟角色修复策略

Remediation Protocol

修复流程

Phase-Specific Remediation Mapping

阶段特定修复映射

Phase 3: Security Guardrails (Org Policies)

阶段3：安全护栏（组织策略）

Phase 4: Resource Hierarchy

阶段4：资源层级

1. Folder Creation

1. 文件夹创建

Check and Create "Common" Folder

检查并创建"Common"文件夹

If not present:

若不存在：

Check and Create "Production" Folder

检查并创建"Production"文件夹

If not present:

若不存在：

Check and Create "Non-Production" Folder

检查并创建"Non-Production"文件夹

If not present:

若不存在：

Check and Create "Development" Folder

检查并创建"Development"文件夹

If not present:

若不存在：

2. Project Creation and Billing Link

2. 项目创建与账单关联

Check if "central-logging-monitoring" project exists in Common folder

检查Common文件夹中是否存在"central-logging-monitoring"项目

If not present: Create, link billing, and enable APIs

若不存在：创建、关联账单并启用API

Check if "production" project exists in Production folder

检查Production文件夹中是否存在"production"项目

If not present: Create, link billing, and enable APIs

若不存在：创建、关联账单并启用API

Check if "non-production" project exists in Non-Production folder

检查Non-Production文件夹中是否存在"non-production"项目

If not present: Create, link billing, and enable APIs

若不存在：创建、关联账单并启用API

Check if "development" project exists in Development folder

检查Development文件夹中是否存在"development"项目

If not present: Create, link billing, and enable APIs

若不存在：创建、关联账单并启用API

Phase 5: Centralized Logging and Monitoring

阶段5：集中式日志与监控

Validation Logic & Checklist

验证逻辑与检查清单

Links

链接