Examkin

Question

Difficulty: Very hardProgrammatic GCP Interaction via SDK, CLI, and APIs

An enterprise hybrid application written in Python needs to programmatically manage infrastructure resources across multiple Google Cloud projects via Google Cloud Client Libraries. The application runs simultaneously on on-premises virtual machines and Google Kubernetes Engine (GKE) clusters. Company security compliance strictly prohibits the creation and storage of downloadable, long-lived service account JSON key files anywhere in the deployment pipeline. Furthermore, the application must interact with APIs across target projects without delegating broad administrative permissions to the workload identity directly. How should you design the programmatic authentication and authorization architecture to satisfy these requirements?

  1. Configure Workload Identity Federation for the on-premises workloads and Workload Identity for the GKE workloads to mint short-lived Application Default Credentials (ADC), and use IAM Service Account Impersonation with fine-grained custom roles for target project access.Answer
  2. B
    Generate a single central service account JSON key, store it securely inside Secret Manager, grant the service account the Owner primitive role across all target projects, and programmatically retrieve the key at application startup to populate GOOGLE_APPLICATION_CREDENTIALS.
  3. C
    Assign the Service Account Admin role to the workload's service account at the GCP Organization node, download the generated service account key into an unversioned storage location, and set up explicit API key authentication headers for cross-project RPC calls.
  4. D
    Provision local Terraform state backends to manage authentication tokens programmatically, and configure local environment scripts to pass service account keys as base64-encoded strings during gcloud CLI initialization routines.

Answer

Configure Workload Identity Federation for on-premises workloads and Workload Identity for GKE workloads to obtain short-lived credentials dynamically, combined with IAM Service Account Impersonation for granular cross-project API access.
The correct strategy combines Workload Identity Federation for on-premises systems and GKE Workload Identity for containerized workloads. Both mechanisms exchange native identity tokens (OIDC/SAML/Kubernetes tokens) for short-lived Google Cloud OAuth2 tokens via Application Default Credentials (ADC), completely avoiding static JSON keys. Cross-project authorization is cleanly achieved using IAM Service Account Impersonation, granting short-lived, fine-grained access tokens to targeted target service accounts.

Step-by-Step Solution

1
Establish short-lived identity mapping without static keys
On-premises workloads authenticate via Workload Identity Federation (using external OIDC/SAML tokens), while GKE workloads leverage GKE Workload Identity to map Kubernetes service accounts directly to GCP service accounts.
This satisfies the governance requirement preventing the creation and maintenance of downloadable, long-lived JSON service account keys.
2
Implement Service Account Impersonation for multi-project authorization
The application requests short-lived access tokens for specific destination service accounts in target projects by leveraging the Service Account Token Creator role.
Impersonation ensures the workload operates under short-lived tokens scoped specifically to required target actions across project boundaries.
3
Apply fine-grained IAM roles to target service accounts
Target service accounts in downstream projects are assigned specific predefined or custom roles (e.g., Compute Instance Admin) rather than primitive roles.
Enforces least privilege access control while performing programmatic SDK operations.

Key Concept

Keyless Programmatic Authentication and Multi-Project Service Account Impersonation
Estimated Time:3m 0s
Rate this question

Topics

Programmatic GCP Interaction via SDK, CLI, and APIs

More questions from this topic