google-cloud-solution-n-tier-serverless-web-app

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Secure n-tier serverless web application with strict private application tiers

具有严格私有应用层的安全n层无服务器Web应用

This skill guides agents through the workflow of designing and implementing a secure serverless web application with as many architectural design layers as specified by the user. It uses Cloud Run for the serverless layers and Cloud SQL for PostgreSQL as the data layer. A three-tier web application might be represented in three architectural layers: a Cloud Run presentation layer, a Cloud Run application layer, and a Cloud SQL for PostgreSQL database layer.

The architecture enforces strict physical and network isolation across all tiers (T1 to TN):

Tier 1 presentation tier (frontend / reverse proxy): Public-facing UI rendering/gateway service (Cloud Run). Exposes the entry point via Cloud Load Balancing and routes requests downstream to internal tiers privately via Direct VPC Egress.
Tier 2..N application tier (internal microservices / business logic): Private application services (Cloud Run). 100% isolated from the internet (Ingress: VPC-internal,
```
INGRESS_TRAFFIC_INTERNAL_ONLY
```
), reachable exclusively via upstream VPC routing (
```
egress = "ALL_TRAFFIC"
```
with Private Google Access on the subnet for
```
*.run.app
```
URLs, or
```
egress = "PRIVATE_RANGES_ONLY"
```
via an internal Application Load Balancer).
Data tier: Private Cloud SQL for persistent data and Memorystore for Redis for caching, reachable exclusively from authorized application tiers.

本技能引导Agent完成安全无服务器Web应用的设计与实现工作流，应用的架构设计层数可根据用户指定调整。它使用Cloud Run作为无服务器层，Cloud SQL for PostgreSQL作为数据层。一个三层Web应用可分为三个架构层：Cloud Run表示层、Cloud Run应用层和Cloud SQL for PostgreSQL数据库层。

该架构在所有层级（T1至TN）之间强制实施严格的物理和网络隔离：

Tier 1表示层（前端/反向代理）：面向公众的UI渲染/网关服务（Cloud Run）。通过Cloud Load Balancing暴露入口点，并通过Direct VPC Egress将请求私密地路由到下游内部层级。
Tier 2..N应用层（内部微服务/业务逻辑）：私有应用服务（Cloud Run）。100%与互联网隔离（Ingress：VPC-internal，
```
INGRESS_TRAFFIC_INTERNAL_ONLY
```
），仅可通过上游VPC路由访问（子网启用Private Google Access时，
```
egress = "ALL_TRAFFIC"
```
以访问
```
*.run.app
```
URL；或通过内部Application Load Balancer时，
```
egress = "PRIVATE_RANGES_ONLY"
```
）。
数据层：用于持久化数据的私有Cloud SQL，以及用于缓存的Memorystore for Redis，仅可从授权的应用层访问。

Workflow

工作流

[!TIP] Optional MCP Server Integration: If your AI coding client supports the Model Context Protocol (
MCP
), you can connect the Google Developer Knowledge MCP Server (
npx -y @google/mcp-developer-knowledge-server
) to dynamically query real-time Google Cloud documentation (
cloud.google.com/docs
) alongside this skill's offline knowledge base (
references/related-guidance.md
).

The solution design and implementation workflow is divided into the following phases:

Phase 1: Requirements discovery and analysis: Analyze the workload's requirements, constraints, dependencies, and current state.
Phase 2: Solution design & IaC drafting: Build a technology stack, architecture, and deployment configuration for the workload. IMPORTANT: You should strongly recommend and offer to generate the complete Terraform code (based on
assets/main.tf
and adhering to all Phase 3 specifications) alongside the solution architecture during this phase. This allows the user to immediately review and iteratively modify the code as the conversation continues. However, if the user explicitly states they do not want code, confirm their preference before proceeding.
Phase 3: Implementation plan & iterative refinement: Modify and refine the generated Terraform code and deployment instructions as the conversation and user feedback evolve.
Phase 4: Solution validation: Validate that the deployment meets the requirements of the workload.

[!提示] 可选MCP服务器集成：如果您的AI编码客户端支持模型上下文协议（MCP），您可以连接Google Developer Knowledge MCP Server（
npx -y @google/mcp-developer-knowledge-server
），以便在本技能的离线知识库（
references/related-guidance.md
）之外，动态查询实时Google Cloud文档（
cloud.google.com/docs
）。

解决方案的设计与实现工作流分为以下阶段：

阶段1：需求发现与分析：分析工作负载的需求、约束、依赖关系和当前状态。
阶段2：解决方案设计与IaC起草：为工作负载构建技术栈、架构和部署配置。**重要提示：在此阶段，您应强烈建议并主动提供生成完整Terraform代码（基于
```
assets/main.tf
```
并遵循所有阶段3规范）的服务，与解决方案架构一同交付。**这允许用户立即查看代码，并在对话过程中迭代修改。但如果用户明确表示不需要代码，请先确认其偏好再继续。
阶段3：实现计划与迭代优化：根据对话和用户反馈，修改并优化生成的Terraform代码和部署说明。
阶段4：解决方案验证：验证部署是否满足工作负载的需求。

Phase 1: Requirements discovery and analysis

阶段1：需求发现与分析

To prevent multi-turn interview fatigue and maintain trajectory determinism across evaluations, adopt an opinionated 80% default golden path unless the user explicitly requests deviations:

Default Golden Path Configuration (
80% Baseline
):
- Architecture: Secure 3-tier serverless pipeline (
```
frontend
```
  Cloud Run ->
```
backend application
```
  Cloud Run ->
```
Cloud SQL PostgreSQL
```
  ).
- Region:
```
us-central1
```
  .
- Database: Cloud SQL for PostgreSQL (
```
POSTGRES_18
```
  ) Enterprise Edition via Private Service Connect (
```
psc_enabled = true
```
  ).
- Edge Protection: Global external Application Load Balancer with Cloud Armor WAF (
```
sqli-v33-stable
```
  ) and Cloud CDN (
```
enable_cdn = true
```
  ).
- Networking & Security: Direct VPC Egress (
```
ALL_TRAFFIC
```
  ),
```
run.app.
```
  Cloud DNS private zone, least-privilege egress firewalls (
```
TCP 5432, 443
```
  ), and Cloud SQL Auth Proxy sidecar (
```
DB_SOCKET_PATH
```
  with IAM Auth).
Disambiguation Protocol (
Maximum 2 Optional Questions
): If the user's initial prompt leaves requirements open-ended (and is not fast-forwarding with exact specs), do not present a multi-topic questionnaire. Only ask up to 2 optional disambiguation questions concisely before confirmation:
1. Load Balancer & Residency Topology: Do you require a Global Application Load Balancer with Cloud CDN (default for worldwide users), or a Regional Application Load Balancer without CDN (for strict EU/regional data residency compliance)?
2. In-Memory Caching Tier: Should we provision an optional Memorystore for Redis caching tier (
```
Private Services Access
```
  ) alongside Cloud SQL to accelerate read queries?
Verify & Confirm: Present the confirmed 3-tier golden path decomposition to the user and request confirmation before proceeding to Phase 2 (or fast-forward automatically when instructed).

为避免多轮沟通疲劳，并确保评估过程中的轨迹确定性，除非用户明确要求偏离，否则采用既定的80%默认黄金路径：

默认黄金路径配置（80%基准）：
- 架构：安全3层无服务器流水线（
```
frontend
```
  Cloud Run ->
```
backend application
```
  Cloud Run ->
```
Cloud SQL PostgreSQL
```
  ）。
- 区域：
```
us-central1
```
  。
- 数据库：通过Private Service Connect（
```
psc_enabled = true
```
  ）部署的Cloud SQL for PostgreSQL（
```
POSTGRES_18
```
  ）企业版。
- 边缘防护：配备Cloud Armor WAF（
```
sqli-v33-stable
```
  ）和Cloud CDN（
```
enable_cdn = true
```
  ）的全球外部应用负载均衡器。
- 网络与安全：Direct VPC Egress（
```
ALL_TRAFFIC
```
  ）、
```
run.app.
```
  Cloud DNS私有区域、最小权限出站防火墙（
```
TCP 5432, 443
```
  ）以及Cloud SQL Auth Proxy边车容器（带IAM认证的
```
DB_SOCKET_PATH
```
  ）。
歧义消除规则（最多2个可选问题）：如果用户的初始提示未明确需求（且未提供精确规格直接推进），请勿呈现多主题问卷。仅最多询问2个简洁的歧义消除问题，然后确认：
1. 负载均衡器与驻留拓扑：您需要带Cloud CDN的全球应用负载均衡器（面向全球用户的默认选项），还是不带CDN的区域应用负载均衡器（用于严格的欧盟/区域数据驻留合规）？
2. 内存缓存层：是否需要在Cloud SQL之外额外部署Memorystore for Redis缓存层（
```
Private Services Access
```
  ）以加速读取查询？
验证与确认：向用户展示已确认的三层黄金路径分解，并请求确认后再进入阶段2（或根据指示直接推进）。

Phase 2: Solution design

阶段2：解决方案设计

Retrieve the 9 architectural security boundaries and report audit checklist from
references/non-negotiable-architectural-rules.md
and product mapping from
references/related-guidance.md
. Important: Use the retrieved content to ground your design and verify the report audit checklist before TF generation (
```
assets/main.tf
```
is the Single Source of Truth for exact HCL). If the Google Developer Knowledge MCP Server is connected, query docs dynamically in real time.
Map components to Google Cloud products: Map your confirmed decomposition directly to Google Cloud products based on Section 11 ("Comprehensive product mapping specifications") inside
```
references/related-guidance.md
```
:
- Public Ingress & WAF: global or regional external Application Load Balancer (
```
INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER
```
  ), Cloud Armor (
```
sqli-v33-stable
```
  ), Cloud CDN (if global Application Load Balancer). Note: When deploying a regional external Application Load Balancer, an explicit proxy-only subnet (
```
purpose = "REGIONAL_MANAGED_PROXY"
```
  ) is required in the VPC and
```
network
```
  must be specified on the regional forwarding rule.
- Internal compute tiers (T1 to TN): Cloud Run microservices (
```
INGRESS_TRAFFIC_INTERNAL_ONLY
```
  ), Direct VPC Egress configured with
```
egress = "ALL_TRAFFIC"
```
  , Private Google Access enabled on the subnet, and a Cloud DNS Managed Private Zone (
```
google_dns_managed_zone
```
  ) for
```
run.app.
```
  bound to
```
vpc_network
```
  mapping
```
*.run.app
```
  directly to Private Google Access VIPs (
```
199.36.153.4/30 / 199.36.153.8/30
```
  ) when calling internal
```
*.run.app
```
  URLs (to prevent queries from resolving via public Google DNS to
```
216.58.x.x
```
  and hitting
```
deny_all_egress
```
  or failing VPC-internal ingress checks), or
```
egress = "PRIVATE_RANGES_ONLY"
```
  when routing via an internal Application Load Balancer, deployed from specified/placeholder container image.
- Private data tier: Cloud SQL PostgreSQL via Private Service Connect + IAM DB Auth. If database caching was selected, add Memorystore Redis via Private Services Access. Depending on reliability requirements, specify either "Cloud SQL for PostgreSQL Enterprise edition instance" or a "Cloud SQL for PostgreSQL Enterprise Plus edition instance".
- Secrets, Registry, & Security: Secret Manager, Artifact Registry, least-privilege egress firewalls (explicitly permitting outbound TCP port 5432 to Cloud SQL PSC IP and TCP port 443 to Private Google Access VIPs
```
199.36.153.4/30, 199.36.153.8/30
```
  on
```
allow_backend_db_egress
```
  so the Cloud SQL Auth Proxy sidecar can query
```
sqladmin.googleapis.com
```
  and exchange tokens for ephemeral IAM certs on startup without crashing), and optional VPC Service Controls.
Create architecture diagram: Create a clean Mermaid format architecture diagram (
```
assets/output-template.md
```
) illustrating the multi-tier request and data flow across entry point, public reverse proxy, private microservice compute tiers, and private database/caching endpoints.
Draft solution architecture and generate Terraform &
gcloud
CLI code: Compile the requirements, technical decomposition, product mapping, architecture diagram, design recommendations, AND the complete Infrastructure as Code (
```
Terraform based on assets/main.tf alongside a self-contained sequence of gcloud CLI deployment commands adhering to all Phase 3 mandatory specifications
```
) into a single Markdown file structured strictly per the standardized Google Cloud Solution Architecture output template at
```
assets/output-template.md
```
and present them to the user. When saving or outputting the report artifact, append an ISO 8601 UTC timestamp and ensure the filename strictly ends with the
```
.md
```
extension (
```
e.g., workload_name_architecture_report-20260701T212820Z.md
```
). Verify that all 9 security boundaries from
```
assets/main.tf
```
are documented cleanly in your report.
Request review and iterate: Present the solution architecture (and Terraform code,
```
gcloud
```
script, or validation script if generated) to the user and request feedback. Modify and refine both the architecture and code iteratively as the conversation continues.

从
references/non-negotiable-architectural-rules.md
中获取9项架构安全边界和报告审核清单，并从
references/related-guidance.md
中获取产品映射。重要提示：使用获取的内容作为设计基础，并在生成TF代码前验证报告审核清单（
```
assets/main.tf
```
是精确HCL的唯一可信来源）。如果已连接Google Developer Knowledge MCP Server，则实时动态查询文档。
将组件映射到Google Cloud产品：根据
```
references/related-guidance.md
```
中的第11节（"全面产品映射规范"），将已确认的分解直接映射到Google Cloud产品：
- 公共Ingress与WAF：全球或区域外部应用负载均衡器（
```
INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER
```
  ）、Cloud Armor（
```
sqli-v33-stable
```
  ）、Cloud CDN（如果使用全球应用负载均衡器）。注意：部署区域外部应用负载均衡器时，VPC中需要显式的代理专用子网（
```
purpose = "REGIONAL_MANAGED_PROXY"
```
  ），且区域转发规则必须指定
```
network
```
  。
- 内部计算层（T1至TN）：Cloud Run微服务（
```
INGRESS_TRAFFIC_INTERNAL_ONLY
```
  ），配置Direct VPC Egress为
```
egress = "ALL_TRAFFIC"
```
  ，子网启用Private Google Access，以及针对
```
run.app.
```
  的Cloud DNS托管私有区域（
```
google_dns_managed_zone
```
  ）绑定到
```
vpc_network
```
  ，将
```
*.run.app
```
  直接映射到Private Google Access VIP（
```
199.36.153.4/30 / 199.36.153.8/30
```
  ）以访问内部
```
*.run.app
```
  URL（防止查询通过公共Google DNS解析到
```
216.58.x.x
```
  ，从而触发
```
deny_all_egress
```
  或VPC内部Ingress检查失败）；或通过内部应用负载均衡器路由时，设置
```
egress = "PRIVATE_RANGES_ONLY"
```
  ，从指定/占位容器镜像部署。
- 私有数据层：通过Private Service Connect + IAM数据库认证的Cloud SQL PostgreSQL。如果选择了数据库缓存，则添加通过Private Services Access部署的Memorystore Redis。根据可靠性要求，指定"Cloud SQL for PostgreSQL企业版实例"或"Cloud SQL for PostgreSQL企业增强版实例"。
- 密钥、注册表与安全：Secret Manager、Artifact Registry、最小权限出站防火墙（明确允许出站TCP端口5432到Cloud SQL PSC IP，以及TCP端口443到Private Google Access VIP
```
199.36.153.4/30, 199.36.153.8/30
```
  ，配置在
```
allow_backend_db_egress
```
  中，确保Cloud SQL Auth Proxy边车容器启动时可以查询
```
sqladmin.googleapis.com
```
  并交换令牌获取临时IAM证书，避免崩溃），以及可选的VPC Service Controls。
创建架构图：创建清晰的Mermaid格式架构图（
```
assets/output-template.md
```
），展示跨入口点、公共反向代理、私有微服务计算层和私有数据库/缓存端点的多层请求与数据流。
起草解决方案架构并生成Terraform与
gcloud
CLI代码：将需求、技术分解、产品映射、架构图、设计建议，以及完整的基础设施即代码（
```
基于assets/main.tf的Terraform，同时附带符合所有阶段3强制规范的独立gcloud CLI部署命令序列
```
）整合到一个严格遵循
```
assets/output-template.md
```
中标准化Google Cloud解决方案架构输出模板的Markdown文件中，并呈现给用户。保存或输出报告工件时，附加ISO 8601 UTC时间戳，并确保文件名严格以
```
.md
```
结尾（例如：
```
workload_name_architecture_report-20260701T212820Z.md
```
）。验证报告中是否清晰记录了
```
assets/main.tf
```
中的所有9项安全边界。
请求评审并迭代：向用户展示解决方案架构（以及生成的Terraform代码、
```
gcloud
```
脚本或验证脚本）并请求反馈。根据对话持续修改和优化架构与代码。

Phase 3: Implementation plan

阶段3：实现计划

Retrieve relevant building block templates from the
assets/
directory. Important: Use the code in
```
assets/main.tf
```
as the foundation for your Terraform implementation plan (
```
assets/output-template.md
```
for architecture structure).

Identify deployment prerequisites:

Required Google Cloud APIs (

run.googleapis.com

sqladmin.googleapis.com

redis.googleapis.com

servicenetworking.googleapis.com

secretmanager.googleapis.com

monitoring.googleapis.com

dns.googleapis.com

Required IAM permissions (Project Editor, Security Admin, etc.).

Generate Infrastructure as Code (IaC) (
Architectural Specifications
): Retrieve relevant architectural and hierarchy guidance from
```
references/non-negotiable-architectural-rules.md
```
. Base code strictly on the building blocks in
```
assets/main.tf
```
(
```
Section 5.1
```
for Tier 1,
```
Section 5.2
```
for Tiers 2..N), ensuring
```
database_version = "POSTGRES_18"
```
is preserved exactly. Do NOT generate from memory/v1 legacy resources or revert to older database versions like
```
POSTGRES_15
```
.
Write deployment instructions & README.md: Draft comprehensive step-by-step deployment instructions (or a complete
```
README.md
```
artifact), ensuring you include:
- Instructions to initialize and apply Terraform (
```
terraform init
```
  ,
```
terraform apply
```
  ). Zero-Install Environment Recommendation: Explicitly recommend running
```
terraform
```
  commands and your generated automated validation script inside Google Cloud Shell (
```
https://shell.cloud.google.com
```
  ), where
```
python3
```
  ,
```
gcloud
```
  , and
```
terraform
```
  are 100% pre-installed and authenticated out of the box so developers without local SDKs can deploy and validate immediately.
- Step-by-Step
  gcloud
  CLI Deployment Commands (
  Bottom-Up Wiring
  ): In Section 6.3 ("Step-by-step gcloud CLI deployment commands") inside
```
assets/output-template.md
```
  , provide a complete, self-contained sequence of
```
gcloud
```
  CLI commands required to deploy this exact architecture without Terraform. These commands must enforce reverse/bottom-up order (
```
VPC/subnets -> data tiers -> internal microservices -> public gateway -> load balancer
```
  ), specify
```
--database-version=POSTGRES_18
```
  when provisioning Cloud SQL, and extract downstream container URLs (
```
gcloud run services describe... --format='value(status.url)'
```
  ) into shell variables to dynamically pass them via
```
--update-env-vars
```
  into upstream services.
- Explanation of all Terraform variables, explicitly including and documenting the
  enable_vpc_sc
  variable.
- Dedicated VPC Service Controls Guidance Section: Provide specific instructions and gcloud commands for implementing an Org-level VPC-SC service perimeter around Cloud Run (
```
run.googleapis.com
```
  ), Cloud SQL (
```
sqladmin.googleapis.com
```
  ), and Secret Manager (
```
secretmanager.googleapis.com
```
  ) when
```
enable_vpc_sc = true
```
  .
- Container image deployment strategies (specifying pre-existing image URLs or placeholder bootstrapping followed by CI/CD).
- Cloud DNS Managed Private Zone (
```
google_dns_managed_zone
```
  ) configuration for
```
run.app.
```
  bound to
```
vpc_network
```
  , mapping
```
*.run.app
```
  directly to Private Google Access VIPs (
```
199.36.153.4/30 / 199.36.153.8/30
```
  ), alongside external DNS records and database schema initialization.
Request review: Present the implementation plan to the user for approval. Iterate as needed.

从
assets/
目录中获取相关构建块模板。 重要提示：使用
```
assets/main.tf
```
中的代码作为Terraform实现计划的基础（架构结构遵循
```
assets/output-template.md
```
）。

确定部署先决条件：

所需Google Cloud API（

run.googleapis.com

、

sqladmin.googleapis.com

、

redis.googleapis.com

、

servicenetworking.googleapis.com

、

secretmanager.googleapis.com

、

monitoring.googleapis.com

、

dns.googleapis.com

）。

所需IAM权限（项目编辑器、安全管理员等）。

生成基础设施即代码（IaC）（架构规范）：从
```
references/non-negotiable-architectural-rules.md
```
中获取相关架构和层级指导。严格基于
```
assets/main.tf
```
中的构建块编写代码（Tier 1对应第5.1节，Tiers 2..N对应第5.2节），确保
```
database_version = "POSTGRES_18"
```
完全保留。请勿凭记忆/v1遗留资源生成代码，或回退到
```
POSTGRES_15
```
等旧数据库版本。
编写部署说明与README.md：起草全面的分步部署说明（或完整的
```
README.md
```
工件），确保包含：
- Terraform初始化与应用说明（
```
terraform init
```
  、
```
terraform apply
```
  ）。零安装环境建议：明确推荐在Google Cloud Shell（
```
https://shell.cloud.google.com
```
  ）中运行
```
terraform
```
  命令和生成的自动化验证脚本，该环境已预装并预认证
```
python3
```
  、
```
gcloud
```
  和
```
terraform
```
  ，无需本地SDK的开发者可立即部署和验证。
- 分步
  gcloud
  CLI部署命令（自底向上连接）：在
```
assets/output-template.md
```
  的第6.3节（"分步gcloud CLI部署命令"）中，提供无需Terraform即可部署此精确架构的完整独立
```
gcloud
```
  CLI命令序列。这些命令必须遵循反向/自底向上顺序（
```
VPC/子网 -> 数据层 -> 内部微服务 -> 公共网关 -> 负载均衡器
```
  ），配置Cloud SQL时指定
```
--database-version=POSTGRES_18
```
  ，并将下游容器URL（
```
gcloud run services describe... --format='value(status.url)'
```
  ）提取到shell变量中，通过
```
--update-env-vars
```
  动态传递给上游服务。
- 所有Terraform变量的说明，明确包含并记录
  enable_vpc_sc
  变量。
- 专用VPC Service Controls指导章节：当
```
enable_vpc_sc = true
```
  时，提供围绕Cloud Run（
```
run.googleapis.com
```
  ）、Cloud SQL（
```
sqladmin.googleapis.com
```
  ）和Secret Manager（
```
secretmanager.googleapis.com
```
  ）实施组织级VPC-SC服务边界的具体说明和gcloud命令。
- 容器镜像部署策略（指定预先存在的镜像URL，或占位引导后跟进CI/CD）。
- 针对
```
run.app.
```
  的Cloud DNS托管私有区域（
```
google_dns_managed_zone
```
  ）配置，绑定到
```
vpc_network
```
  ，将
```
*.run.app
```
  直接映射到Private Google Access VIP（
```
199.36.153.4/30 / 199.36.153.8/30
```
  ），以及外部DNS记录和数据库模式初始化。
请求评审：向用户展示实现计划以获得批准。根据需要迭代优化。

Phase 4: Solution validation

阶段4：解决方案验证

Define solution verification steps & requirements: During validation planning, mandate these 5 verification steps across any deployed environment:
- SSL Provisioning: Verify that the Google-managed SSL certificate (
```
google_compute_managed_ssl_certificate
```
  ) becomes
```
ACTIVE
```
  (checking
```
--global
```
  status or regional equivalents).
- Frontend Ingress Block: Verify that direct internet access targeting the Tier 1 Frontend's default
```
*.run.app
```
  URL is blocked (
```
HTTP 403 Forbidden
```
  from edge screening).
- Backend Ingress Block: Verify that direct internet access targeting internal compute tiers'
```
*.run.app
```
  URLs (
```
INGRESS_TRAFFIC_INTERNAL_ONLY
```
  ) is blocked across all internal microservice tiers (
```
HTTP 404 Not Found
```
  or
```
HTTP 403 Forbidden
```
  ).
- Frontend Public Access via Application Load Balancer: Verify that accessing the custom domain routes successfully to the presentation tier via the Application Load Balancer (
```
HTTP 200
```
  to
```
399
```
  ).
- Edge WAF Protection: Verify that a simulated SQL injection request (
```
/?id=1%20OR%201=1
```
  on the custom domain) is intercepted and blocked (
```
HTTP 403 Forbidden
```
  from Cloud Armor).
- Private Server-to-Server Connectivity: Verify via Cloud Run application logs (
```
Logs Explorer
```
  ) and database connection pooling telemetry (
```
Cloud SQL Query Insights
```
  ) that tier 1 -> tier 2 -> data tier queries succeed over private VPC fiber (
```
Direct VPC Egress
```
  +
```
Private Service Connect
```
  /
```
Private Services Access
```
  ).
Generate tailored automated validation script: Rather than relying on a static pre-packaged script, generate a custom automated validation script (e.g., self-contained Python validation script using standard built-in
```
urllib
```
/
```
subprocess
```
libraries, or a cross-platform bash/PowerShell script) customized precisely to the user's deployed domain, SSL certificate name, and exact multi-tier
```
*.run.app
```
URIs.
Provide cross-platform execution guidance: Explain how the user can execute the generated script across their target OS (
```
macOS
```
,
```
Linux
```
,
```
Windows PowerShell
```
, or zero-install Google Cloud Shell (
```
https://shell.cloud.google.com
```
)).
Compile validation report: Document the validation checks, the generated verification script code, execution commands, and expected outcomes in Section 6.4 ("Solution verification guide and custom automated validation script") inside
```
assets/output-template.md
```
.
Conduct validation and finalize: Assist the user in running the generated verification script, inspecting logs, and troubleshooting any DNS or WAF propagation issues. Request final approval.

定义解决方案验证步骤与要求：在验证规划期间，强制要求在任何部署环境中执行以下5项验证步骤：
- SSL证书配置：验证Google托管SSL证书（
```
google_compute_managed_ssl_certificate
```
  ）变为
```
ACTIVE
```
  状态（检查
```
--global
```
  状态或区域等效状态）。
- 前端Ingress拦截：验证直接访问Tier 1前端默认
```
*.run.app
```
  URL的互联网请求被拦截（边缘筛选返回
```
HTTP 403 Forbidden
```
  ）。
- 后端Ingress拦截：验证直接访问内部计算层
```
*.run.app
```
  URL（
```
INGRESS_TRAFFIC_INTERNAL_ONLY
```
  ）的互联网请求在所有内部微服务层被拦截（返回
```
HTTP 404 Not Found
```
  或
```
HTTP 403 Forbidden
```
  ）。
- 通过应用负载均衡器访问前端：验证通过自定义域名路由可成功访问表示层（返回
```
HTTP 200
```
  至
```
399
```
  ）。
- 边缘WAF防护：验证模拟SQL注入请求（自定义域名下的
```
/?id=1%20OR%201=1
```
  ）被拦截并阻止（Cloud Armor返回
```
HTTP 403 Forbidden
```
  ）。
- 私有服务器间连接：通过Cloud Run应用日志（Logs Explorer）和数据库连接池遥测（Cloud SQL Query Insights）验证Tier 1 -> Tier 2 -> 数据层的查询通过私有VPC光纤成功完成（
```
Direct VPC Egress
```
  +
```
Private Service Connect
```
  /
```
Private Services Access
```
  ）。
生成定制化自动化验证脚本：不要依赖静态预打包脚本，生成定制化自动化验证脚本（例如，使用标准内置
```
urllib
```
/
```
subprocess
```
库的独立Python验证脚本，或跨平台bash/PowerShell脚本），精确适配用户部署的域名、SSL证书名称和确切的多层
```
*.run.app
```
URI。
提供跨平台执行指导：说明用户如何在目标操作系统（
```
macOS
```
、
```
Linux
```
、
```
Windows PowerShell
```
或零安装的Google Cloud Shell（
```
https://shell.cloud.google.com
```
））上执行生成的脚本。
编制验证报告：在
```
assets/output-template.md
```
的第6.4节（"解决方案验证指南与定制化自动化验证脚本"）中记录验证检查项、生成的验证脚本代码、执行命令和预期结果。
执行验证并最终确认：协助用户运行生成的验证脚本、检查日志，并排查任何DNS或WAF传播问题。请求最终批准。