ExamFinch.com My Study

Study guide

8.2 Workload Identity and Service Authentication

Practice this exam

Google Cloud Professional Cloud Developer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam and Compute Platform Decisions

1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs

2 Chapter 2: Container Engineering and API Contracts

2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts

3 Chapter 3: gRPC Compatibility and Geographic Routing

3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls

4 Chapter 4: API Management and Caching

4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover

5 Chapter 5: Messaging, Task Dispatch, and Orchestration

5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows

6 Chapter 6: Resilience and Relational Availability

6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency

7 Chapter 7: Distributed Schemas and NoSQL Data Models

7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication

8 Chapter 8: Object Storage and Application Identity

8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP

9 Chapter 9: Security, Data Integration, and Developer Credentials

9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell

10 Chapter 10: Managed Development and Automated Tests

10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking

11 Chapter 11: AI Development Tools and Build Pipelines

11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM

12 Chapter 12: Artifact Security and Admission Policies

12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass

13 Chapter 13: Cloud Run and GKE Deployment Configuration

13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing

14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases

14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts

15 Chapter 15: Source/Event Deployment and Cloud API Integration

15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries

16 Chapter 16: Tracing, Sampling, and Monitoring

16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring

17 Chapter 17: Structured Logs, Routing, and Error Management

17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling

18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting

18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance

8.2 Workload Identity and Service Authentication

Key Takeaways Explain This Topic AI

Workload Identity Federation for GKE supports direct principal grants or optional service-account impersonation.

An existing Standard node pool needs the GKE metadata-server configuration.

Cloud Run ingress restrictions and Invoker authorization are separate controls.

Last updated: October 2026

Application Identity, Workload Identity & Secret Manager

In modern cloud architectures, securing application communication requires replacing static perimeter defenses and embedded credentials with dynamic, cryptographically verifiable identities. The Google Cloud Professional Cloud Developer exam emphasizes the elimination of long-lived service account keys, the configuration of Workload Identity across container platforms, fine-grained credential injection with Secret Manager , and zero-trust perimeter verification using Identity-Aware Proxy (IAP) .

Google Cloud Service Accounts & Token Mechanics

A Service Account (SA) is a special Google identity used by applications and virtual workloads rather than individual human end-users. Workloads use service accounts to authenticate against Google Cloud APIs.

Service Account Classifications

User-Managed Service Accounts: Created explicitly by developers (e.g., order-service@my-project.iam.gserviceaccount.com ). Best practice dictates creating dedicated, least-privilege service accounts for each distinct microservice.

Default Service Accounts: Created automatically when certain Google Cloud APIs are enabled:

  • Compute Engine Default SA: PROJECT_NUMBER-compute@developer.gserviceaccount.com
  • App Engine Default SA: PROJECT_ID@appspot.gserviceaccount.com

Critical Security Risk: Historically, default service accounts are automatically granted the primitive Editor role ( roles/editor ), granting excessive read/write permissions across the entire project. In production environments, default service accounts should have their Editor role revoked or be disabled entirely in favor of dedicated user-managed service accounts.

Google-Managed Service Agents: Created and maintained by Google to execute tasks on your behalf (e.g., service-PROJECT_NUMBER@cloudrun-service-accounts.iam.gserviceaccount.com ). They are granted specialized internal roles.

Authentication Tokens: Access Tokens vs. ID Tokens

Workloads acquire credentials by querying the local Instance Metadata Server at http://metadata.google.internal/computeMetadata/v1/ using the mandatory HTTP header Metadata-Flavor: Google . ## Fetching an OAuth 2.0 Access Token (for calling Google Cloud APIs)

  • curl -s -H "Metadata-Flavor: Google" \
  • "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
  • ## Fetching an OpenID Connect (OIDC) ID Token (for authenticating to Cloud Run/Cloud Functions)
  • curl -s -H "Metadata-Flavor: Google" \

"http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://order-service-xyz.run.app"

Token Type Standard Lifetime Primary Use Case

OAuth 2.0 Access Token Bearer string 1 Hour (3,600s) Authorizing requests to Google Cloud APIs (Cloud Storage, Spanner, BigQuery).

OpenID Connect (OIDC) ID Token Cryptographically signed JWT 1 Hour (3,600s) Service-to-service authentication between Cloud Run, Cloud Functions, and IAP-protected endpoints.

The Anti-Pattern of Exported Private Keys

Downloading service account JSON private keys ( sa-key.json ) violates cloud security best practices:

User-managed keys do not expire by default unless an applicable organization policy sets expiry; avoid distributing them.

Keys are frequently leaked into source control, container layers, or logging sinks.

Static key rotation requires additional operational controls; keyless identities reduce credential distribution and leakage risk.

Resolution: Workloads running on Google Cloud must always leverage native metadata identity tokens or Workload Identity .

GKE Workload Identity

GKE Workload Identity is the recommended best practice for granting Kubernetes workloads secure access to Google Cloud services. It can grant resource IAM roles directly to a Kubernetes Service Account (KSA) principal. The following procedure illustrates the alternative IAM service-account impersonation model; it is not the only supported model. +--------------------------------------------------------------------------+

  • | GKE Workload Identity Authentication Flow |
  • +--------------------------------------------------------------------------+
  • | GKE Pod (spec.serviceAccountName: order-ksa) |
  • | | |
  • | | 1. Application invokes Google Cloud Client Library |
  • | v |
  • | GKE Pod Metadata Server (Intercepts metadata.google.internal) |
  • | | |
  • | | 2. Validates KSA identity: prod/order-ksa |
  • | v |
  • | Google Cloud IAM |
  • | | |
  • | | 3. Checks Workload Identity Binding: |
  • | | serviceAccount:PROJECT_ID.svc.id.goog[prod/order-ksa] |
  • | | has roles/iam.workloadIdentityUser on order-gsa |
  • | v |
  • | 4. Returns short-lived OAuth 2.0 Access Token for order-gsa to Pod |
  • +--------------------------------------------------------------------------+
  • Step-by-Step Implementation Procedure

Step 1: Enable Workload Identity on the GKE Cluster and Node Pools gcloud container clusters update my-cluster \

  • -region=us-central1 \
  • -workload-pool=my-project-id.svc.id.goog

For an existing Standard node pool, also configure --workload-metadata=GKE_METADATA on the node pool. Autopilot enables federation by default. A workload-pool setting alone does not retrofit every existing Standard node pool.

  • Step 2: Create the Google Service Account (GSA) and Grant IAM Roles ## Create GSA
  • gcloud iam service-accounts create order-gsa --project=my-project-id
  • ## Grant Cloud Storage permissions to GSA
  • gcloud projects add-iam-policy-binding my-project-id \
  • -member="serviceAccount:order-gsa@my-project-id.iam.gserviceaccount.com" \
  • -role="roles/storage.objectViewer"
  • Step 3: Create the Kubernetes Service Account (KSA) kubectl create namespace prod
  • kubectl create serviceaccount order-ksa --namespace prod
  • Step 4: Bind KSA to GSA via IAM

Grant the KSA permission to impersonate the GSA using the roles/iam.workloadIdentityUser role: gcloud iam service-accounts add-iam-policy-binding \

  • order-gsa@my-project-id.iam.gserviceaccount.com \
  • -role="roles/iam.workloadIdentityUser" \
  • -member="serviceAccount:my-project-id.svc.id.goog[prod/order-ksa]"
  • Step 5: Annotate the KSA
  • Annotate the KSA with the email address of the target GSA: kubectl annotate serviceaccount order-ksa \
  • -namespace prod \
  • iam.gke.io/gcp-service-account=order-gsa@my-project-id.iam.gserviceaccount.com
  • Step 6: Deploy Pod Referencing the KSA

In the Kubernetes Pod specification, assign serviceAccountName: order-ksa . The application's Google Cloud client libraries automatically acquire tokens from the Pod Metadata Server without requiring credential files or environment variables.

Cloud Run Service Identity

On Cloud Run, managing service identity requires no cluster setup. Developers attach a dedicated user-managed service account directly during deployment: gcloud run deploy payment-service \

  • -image=us-central1-docker.pkg.dev/my-project/apps/payment:v1 \
  • -service-account=payment-sa@my-project.iam.gserviceaccount.com \
  • -region=us-central1
  • Service-to-Service Private Ingress Pattern

When Cloud Run Service A calls a private Cloud Run Service B:

Require IAM authentication on Service B and separately choose an ingress setting. Internal ingress is a network rule, not an identity check; calls from another Cloud Run service need a supported VPC/internal routing path when internal ingress is selected.

Service A fetches a signed OIDC ID Token from the metadata server with audience=https://service-b-url.run.app .

Service A adds the token to the request header: Authorization: Bearer <ID_TOKEN> .

Cloud Run frontends validate the token's cryptographic signature and verify that Service A's service account holds the Cloud Run Invoker role ( roles/run.invoker ) on Service B.