Your enterprise operates a hybrid CI/CD pipeline where deployment runners in an on-premises data center deploy containerized workloads to on-premises Anthos/GKE Enterprise clusters. The on-premises environment connects to your Google Cloud Virtual Private Cloud (VPC) through Dedicated Cloud Interconnect. You need to design a secure deployment workflow that satisfies the following requirements: On-premises runners must pull container images from Google Artifact Registry without traversing the public internet. Deployment workloads must securely authenticate and retrieve application credentials from Google Cloud Secret Manager without using exported, long-lived service account JSON keys. Secrets must not be passed through static environment variables or written unencrypted to disk. Which combination of architectural patterns and services should you implement?

Enable Private Google Access for on-premises hosts over Cloud Interconnect to route Artifact Registry traffic to Google Cloud APIs privately. Configure Workload Identity Federation to exchange local identity tokens for short-lived Google Cloud credentials, and fetch credentials from Secret Manager directly via client libraries or the Secrets Store CSI driver.: ### What Private Google Access and Workload Identity Federation Provide **Private Google Access for on-premises hosts** allows external networks connected via **Cloud Interconnect** or **Cloud VPN** to resolve and reach Google APIs and services—such as **Artifact Registry** and **Secret Manager**—using internal RFC 1918 or private VIP routing (`private.googleapis.com` or `restricted.googleapis.com`), completely avoiding internet transit. **Workload Identity Federation** allows non-Google Cloud compute workloads (such as on-premises CI/CD runners or Kubernetes pods) to use their native identity providers (such as OpenID Connect or SAML) to obtain short-lived Google Cloud credentials dynamically. ### How it meets the requirements: - **No public internet exposure**: Traffic to **Artifact Registry** and **Secret Manager** stays on dedicated private links via **Cloud Interconnect** and **Private Google Access**. - **Eliminating long-lived service account keys**: Workload Identity Federation eliminates the critical security vulnerability of exported JSON keys by trading federated identity tokens for ephemeral, short-lived **IAM access tokens**. - **Secure credential injection**: Accessing Secret Manager directly at runtime via **client libraries** or mounting secrets as ephemeral volumes with the **Secrets Store CSI driver** ensures that secrets are not exposed in plaintext environment variables or persisted to unencrypted disk layers. ### Key advantages and capabilities: - Enforces **defense-in-depth** across both network boundaries and identity management. - Integrates cleanly with **VPC Service Controls** for data loss prevention. - Supports **least privilege** and audit logging for every secret version access. - Removes operational overhead associated with rotating and managing long-lived static credentials. ### Why this is optimal: Combining Private Google Access over Cloud Interconnect with Workload Identity Federation adheres strictly to Google Cloud security architecture best practices for hybrid pipelines, mitigating risks of credential theft and data exfiltration while keeping all traffic on private channels.

Hybrid Cicd Artifact Registry Secret Manager Interconnect | Professional Cloud DevOps Engineer

Hybrid Cicd Artifact Registry Secret Manager Interconnect

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your enterprise operates a hybrid CI/CD pipeline where deployment runners in an on-premises data center deploy containerized workloads to on-premises Anthos/GKE Enterprise clusters. The on-premises environment connects to your Google Cloud Virtual Private Cloud (VPC) through Dedicated Cloud Interconnect.

You need to design a secure deployment workflow that satisfies the following requirements:

On-premises runners must pull container images from Google Artifact Registry without traversing the public internet.
Deployment workloads must securely authenticate and retrieve application credentials from Google Cloud Secret Manager without using exported, long-lived service account JSON keys.
Secrets must not be passed through static environment variables or written unencrypted to disk.

Which combination of architectural patterns and services should you implement?

Configure Cloud NAT inside the VPC to route external on-premises runner traffic to Artifact Registry over public endpoints. Generate a dedicated service account JSON key for Secret Manager, store the key in an on-premises HashiCorp Vault cluster, and inject credentials into container environment variables during deployment.

Establish an Identity-Aware Proxy (IAP) TCP forwarding tunnel from on-premises runners to Artifact Registry endpoints. Create static Kubernetes Secrets within the cluster manifests populated with database credentials encoded in base64 before applying them to the Anthos cluster.

Set up a public Cloud Storage bucket as a remote caching proxy for Artifact Registry. Attach an Identity and Access Management (IAM) Service Account with Secret Manager Secret Accessor privileges directly to the local runner virtual machine hypervisor.

Enable Private Google Access for on-premises hosts over Cloud Interconnect to route Artifact Registry traffic to Google Cloud APIs privately. Configure Workload Identity Federation to exchange local identity tokens for short-lived Google Cloud credentials, and fetch credentials from Secret Manager directly via client libraries or the Secrets Store CSI driver.

Professional Cloud DevOps Engineer

Hybrid Cicd Artifact Registry Secret Manager Interconnect

Related questions