Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise DevOps team is architecting a multi-cloud continuous deployment pipeline using Argo CD hosted on an external Kubernetes cluster. The pipeline needs to deploy application artifacts and fetch sensitive database credentials directly from Google Cloud Secret Manager across projects.
Corporate security policy strictly prohibits the creation, distribution, and storage of downloadable long-lived service account keys (.json key files) within external CI/CD systems.
Which solution should the team implement to authenticate the external pipeline to Google Cloud while maintaining least-privilege access control?
Generate Google Cloud service account JSON keys programmatically via Cloud Functions, rotate them daily into Kubernetes Secret objects, and grant the service account the Secret Manager Admin role at the project level.
Configure Identity-Aware Proxy (IAP) TCP forwarding on the external runner nodes and grant the IAP-secured Tunnel User role to the external cluster's default compute service principal.
Configure Workload Identity Federation with an OIDC identity pool for the external cluster, map the Kubernetes service account to a Google Cloud service account, and grant that service account the Secret Manager Secret Accessor role on only the targeted secrets.
Store external cluster credentials in Secret Manager, retrieve the secret's resource name, and use basic HTTP authentication to fetch secrets over the public Secret Manager REST API.
Generate Google Cloud service account JSON keys programmatically via Cloud Functions, rotate them daily into Kubernetes Secret objects, and grant the service account the Secret Manager Admin role at the project level.
Configure Identity-Aware Proxy (IAP) TCP forwarding on the external runner nodes and grant the IAP-secured Tunnel User role to the external cluster's default compute service principal.
Configure Workload Identity Federation with an OIDC identity pool for the external cluster, map the Kubernetes service account to a Google Cloud service account, and grant that service account the Secret Manager Secret Accessor role on only the targeted secrets.
Workload Identity Federation allows workloads running outside of Google Cloud—such as on-premises environments, external Kubernetes clusters, AWS, or Azure—to impersonate Google Cloud IAM service accounts by exchanging external credentials (like OpenID Connect tokens) for short-lived Google Cloud access tokens, removing the need for long-lived service account keys.
StudyCerts
StudyCertsroles/secretmanager.secretAccessor) role on the specific secret resources required by the deployment..json service account private keys.Workload Identity Federation provides a native, highly secure mechanism for federating identity across hybrid and multi-cloud environments. It satisfies corporate governance by preventing static secret exposure while strictly enforcing least-privilege IAM roles at the resource level.
Store external cluster credentials in Secret Manager, retrieve the secret's resource name, and use basic HTTP authentication to fetch secrets over the public Secret Manager REST API.