Workload identity federation in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Workload Identity Federation Basics

What is the primary benefit of using Workload Identity Federation in Google Cloud?

A It allows external workloads to access Google Cloud resources without using long-lived service account keys.

B It automatically encrypts all data stored in Google Cloud Storage buckets.

C It enables Google Cloud services to run workloads on-premises without internet access.

D It provides a graphical interface to manage Google Cloud IAM roles.

💡 Hint

Think about how external systems can securely access Google Cloud without managing keys.

Workload Identity Federation lets external identities access Google Cloud resources without needing to manage service account keys, improving security and ease of use.

❓ Configuration

intermediate

Configuring a Workload Identity Pool Provider

You want to configure a Workload Identity Pool provider to trust an external OIDC identity provider. Which configuration element is mandatory to specify in the provider setup?

A The Google Cloud project billing account ID.

B The issuer URI of the external OIDC identity provider.

C The IP address of the external workload.

D The encryption key used for Google Cloud Storage.

💡 Hint

Consider what uniquely identifies the external identity provider in OIDC.

The issuer URI is required to identify and trust the external OIDC identity provider in the Workload Identity Pool provider configuration.

❓ Architecture

advanced

Designing Secure Access with Workload Identity Federation

You have an application running on AWS that needs to access Google Cloud Storage securely without using service account keys. Which architecture best follows Workload Identity Federation best practices?

A Manually copy files from AWS to Google Cloud Storage using a local machine with gcloud CLI.

B Generate a Google Cloud service account key and store it in AWS Secrets Manager for the application to use.

C Use a VPN to connect AWS to Google Cloud and allow access via internal IPs without authentication.

D Create a Workload Identity Pool in Google Cloud, configure an AWS provider with the AWS account ID, and grant the pool access to the required Cloud Storage roles.

💡 Hint

Think about how to avoid managing keys and use identity federation instead.

Using a Workload Identity Pool with an AWS provider allows the AWS workload to authenticate to Google Cloud securely without keys, following best practices.

❓ security

advanced

Security Implications of Workload Identity Federation

Which of the following is a key security advantage of using Workload Identity Federation over traditional service account keys?

A It eliminates the need to distribute and rotate long-lived service account keys, reducing risk of key leakage.

B It automatically encrypts all network traffic between Google Cloud and external workloads.

C It allows anonymous access to Google Cloud resources for faster development.

D It disables audit logging for external workload access to improve performance.

💡 Hint

Consider how key management affects security risks.

Workload Identity Federation removes the need for long-lived keys, which are a common source of security breaches if leaked or mishandled.

❓ service_behavior

expert

Behavior of Token Exchange in Workload Identity Federation

When an external workload exchanges its identity token for a Google Cloud access token using Workload Identity Federation, what happens if the token audience does not match the configured audience in the Workload Identity Pool provider?

A Google Cloud ignores the audience and issues an access token anyway.

B The token exchange succeeds but logs a warning for auditing purposes.

C The token exchange fails and Google Cloud denies access due to audience mismatch.

D The external workload is granted limited read-only access automatically.

💡 Hint

Think about how strict identity verification is in token exchanges.

If the token audience does not match the configured audience, Google Cloud rejects the token exchange to prevent unauthorized access.

Practice

1. What is the main purpose of Workload Identity Federation in Google Cloud?

easy

A. Encrypt data stored in Google Cloud Storage

B. Create virtual machines automatically

C. Manage billing accounts for Google Cloud projects

D. Allow external applications to access Google Cloud without using long-lived keys

Solution

1. Step 1: Understand Workload Identity Federation purpose

   It is designed to let external apps access Google Cloud resources securely without needing to manage long-lived service account keys.

2. Step 2: Compare options with this purpose

   Only Allow external applications to access Google Cloud without using long-lived keys matches this purpose. Other options describe unrelated Google Cloud features.

3. Final Answer:

   Allow external applications to access Google Cloud without using long-lived keys -> Option D

4. Quick Check:

   Workload Identity Federation = Access without keys [OK]

Hint: Remember: federation means access without keys [OK]

Common Mistakes:

• Confusing federation with VM creation
• Thinking it manages billing
• Assuming it encrypts storage data

2. Which of the following is the correct way to create a workload identity pool using gcloud CLI?

easy

A. gcloud iam service-accounts create POOL_ID --project=my-project

B. gcloud iam workload-identity-pools create POOL_ID --location=global

C. gcloud compute instances create POOL_ID --zone=global

D. gcloud storage buckets create POOL_ID --location=global

Solution

1. Step 1: Identify the correct gcloud command for workload identity pools

   The command to create a workload identity pool is under 'gcloud iam workload-identity-pools create' with a pool ID and location.

2. Step 2: Check each option

   gcloud iam workload-identity-pools create POOL_ID --location=global matches the correct syntax. Options A, B, and D relate to other services like service accounts, compute instances, and storage buckets.

3. Final Answer:

   gcloud iam workload-identity-pools create POOL_ID --location=global -> Option B

4. Quick Check:

   Workload identity pool creation uses 'gcloud iam workload-identity-pools create' [OK]

Hint: Look for 'iam workload-identity-pools create' command [OK]

Common Mistakes:

• Using compute or storage commands instead
• Confusing service account creation with pool creation
• Missing the --location flag

3. Given this snippet to configure a workload identity provider:

gcloud iam workload-identity-pools providers create-oidc my-provider \
  --workload-identity-pool=my-pool \
  --issuer-uri=https://accounts.example.com \
  --allowed-audiences=example-audience

What is the expected behavior after this command?

medium

A. It creates an OIDC provider in the specified pool trusting identities from the issuer URI

B. It deletes the workload identity pool named my-pool

C. It creates a service account named my-provider

D. It sets IAM permissions for the service account

Solution

1. Step 1: Analyze the command purpose

   The command creates an OIDC identity provider inside a workload identity pool, specifying the issuer URI and allowed audiences.

2. Step 2: Match behavior to options

   It creates an OIDC provider in the specified pool trusting identities from the issuer URI correctly describes creating a provider trusting external identities. Other options describe unrelated actions.

3. Final Answer:

   It creates an OIDC provider in the specified pool trusting identities from the issuer URI -> Option A

4. Quick Check:

   Provider creation = trust external issuer [OK]

Hint: OIDC provider means trusting external issuer [OK]

Common Mistakes:

• Thinking it deletes pools
• Confusing provider with service account creation
• Assuming it sets IAM permissions directly

4. You run this command to grant an external identity access to a service account:

gcloud iam service-accounts add-iam-policy-binding [e-mail] \
  --role roles/iam.workloadIdentityUser \
  --member "principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/my-pool/attribute.subject/my-app"

But the external app still cannot access the service account. What is the most likely error?

medium

A. The service account does not exist

B. The role roles/iam.workloadIdentityUser is invalid

C. The member string format is incorrect or does not match the external identity

D. The workload identity pool was deleted

Solution

1. Step 1: Check the member string format

   The member string must exactly match the external identity's attributes. A mismatch or typo will block access.

2. Step 2: Verify other options

   The service account likely exists if the command ran. The role is valid. Pool deletion would cause different errors.

3. Final Answer:

   The member string format is incorrect or does not match the external identity -> Option C

4. Quick Check:

   Member string must match identity exactly [OK]

Hint: Check member string matches external identity exactly [OK]

Common Mistakes:

• Using wrong member string format
• Assuming role is invalid
• Ignoring pool existence

5. You want to allow an external CI/CD system to deploy to your Google Cloud project using workload identity federation. Which combination of steps is required to set this up securely?

hard

A. Create a workload identity pool and provider for the CI/CD system, then grant the provider access to a service account with minimal roles

B. Create a service account key and share it with the CI/CD system, then assign owner role to the service account

C. Create a VM instance and install the CI/CD system there with full project permissions

D. Enable billing API and assign billing admin role to the CI/CD system

Solution

1. Step 1: Create workload identity pool and provider

   This lets the external CI/CD system authenticate without keys by trusting its identity.

2. Step 2: Grant minimal permissions to a service account

   Assign only needed roles to the service account and allow the provider to impersonate it, following least privilege.

3. Final Answer:

   Create a workload identity pool and provider for the CI/CD system, then grant the provider access to a service account with minimal roles -> Option A

4. Quick Check:

   Use federation + minimal roles for secure access [OK]

Hint: Use federation and least privilege roles [OK]

Common Mistakes:

• Sharing long-lived keys
• Assigning overly broad roles
• Using VM instead of federation
• Confusing billing roles with access