/application-design-center-design-deploy

name: application-design-center-design-deploy
description: >-
  Processes GCP infrastructure design and deployment workflows within Application Design Center (ADC).
  Use when:
  - Designing GCP infrastructure with Terraform.
  - Validating local HCL.
  - Performing best-practice plan scans.
  - Importing templates to Application Design Center (ADC).
  - Deploying templates.
  - Troubleshooting deployment failures.
  Boundaries:
  - Only use for GCP-specific cloud infrastructure.
  - Only use for Terraform coding within the ADC context.
license: Apache-2.0
metadata:
  version: v1
  publisher: google
  category: CloudInfrastructure

Designing and Deploying GCP Infrastructure with Application Design Center

Overview

This skill provides a prescriptive, production-grade workflow for the entire infrastructure lifecycle on Google Cloud Platform (GCP). It replaces the automated, opaque-box GAD `design_infra` tool with an **agent-controlled design and validation loop** utilizing modular Terraform and local CLI validation, followed by a **shifted-left best practices plan scan** prior to synchronization with the Application Design Center (ADC) registry for deployment and lifecycle management.

Always maintain the persona of a Principal Cloud Architect. Keep the local Terraform configuration as the source of truth, and ensure the design is fully compliant with best practices before importing it into the cloud registry.

--------------------------------------------------------------------------------

Index

1. [Pre-requisites: Setup & Confirmation](#pre-requisites-setup-confirmation) 2. [Phase 1: Local Infrastructure Design & Validation](#phase-1-local-infrastructure-design-validation) 3. [Phase 2: Shifted-Left Best Practices Assessment & Iterative Remediation](#phase-2-shifted-left-best-practices-assessment-iterative-remediation) 4. [Phase 3: Import IaC to Application Design Center](#phase-3-import-iac-to-application-design-center) 5. [Phase 4: Application Deployment & Monitoring](#phase-4-application-deployment-monitoring) 6. [Phase 5: Troubleshoot Deployment Failures](#phase-5-troubleshoot-deployment-failures) 7. [Phase 6: Verification & E2E Testing](#phase-6-verification-e2e-testing)

--------------------------------------------------------------------------------

Pre-requisites: Setup & Confirmation

Before executing Phase 1, you **must** perform the following setup steps:

1. **Confirm Target Project & Location**:

• Explicitly ask the user to confirm the target GCP **project ID** and

**location** (region).

• If the user does not specify a location, use **`us-central1`** as the

default.

• Verify that your local environment has the active project set:

        gcloud config set project <project_id>

--------------------------------------------------------------------------------

Phase 1: Local Infrastructure Design & Validation

**Goal**: Transform user requirements and codebase characteristics into a 100% validated, secure, and compile-ready Terraform configuration locally.

1. **Invoke the `design` Skill**: Call and execute the `design` skill (defined in [design](references/design_guide.md)) for the user's prompt.

• The `design` skill will autonomously perform the Codebase Analysis,

query the catalog registry, planning, HCL generation, and local CLI validation loop (`terraform init`, `validate`, `plan`) in a dedicated scratch directory. 2. **Locate Validated HCL**: Identify the scratch directory where the `design` skill saved the validated, compile-ready Terraform files (e.g., `scratch/tf_validate_<session_id>/`). 3. **Verify Handover (MANDATORY)**: Ensure that the local validation loop in the `design` skill completed successfully with a clean plan before proceeding. Meticulously inspect the HCL to verify:

• **Secret-Safe Policy**: Confirm that no plaintext credentials,

passwords, or hardcoded secrets are written in `terraform.tfvars` or HCL resource blocks. All sensitive inputs must be wired through GCP Secret Manager.

• **State Isolation Policy**: Confirm that there is no remote backend

block (e.g., `backend "gcs" {}`) in the HCL files. State must remain local in the scratch folder during validation, allowing ADC to handle the remote state registry upon import.

• *Remediation*: If any violations are found, correct them in the HCL,

re-run local validation, and verify again. Do not proceed with unvalidated or insecure code. 4. **Export Terraform Plan to JSON (MANDATORY)**: In the scratch directory, run the following commands to generate a binary plan and convert it into a clean JSON representation:

    terraform plan -out=tfplan && terraform show -json tfplan > tfplan.json

Verify that the `tfplan.json` file is successfully written in your scratch directory.

--------------------------------------------------------------------------------

Phase 2: Shifted-Left Best Practices Assessment & Iterative Remediation

**Goal**: Validate the local plan's alignment with security, cost, and reliability benchmarks BEFORE importing it into the cloud registry, using the native ADC plan assessment API.

1. **Discover Space ID (MANDATORY)**: Before running the assessment or creating templates, you **must** dynamically discover the active ADC Space ID in your target location:

• **List Spaces**: Run the command:

        gcloud design-center spaces list --project=<project_id> --location=<location>

• **Select Space**: Parse the output to identify the active space (e.g.,

`test-deploy` or `googlespace`). If multiple spaces exist, ask the user to confirm. If no space exists, ask the user or create one:

        gcloud design-center spaces create <space_id> --pr