Google PCD: Identity, Authentication and Application Security — Study Guide

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Part of the Google Professional Cloud Developer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Identity is the new perimeter on Google Cloud. Applications must authenticate principals (users, services) and authorize them for least-privilege access to data and APIs, while protecting secrets, keys, and the software supply chain. This section outlines end-to-end design and operational practices that combine Google Cloud IAM, modern auth protocols, network and API defenses, encryption, logging, and response processes. Emphasis is on short‑lived credentials, centralized policy, and layered controls that fail safely.

Identities, Authentication, and Access Control

• IAM roles and service accounts

  • Use resource hierarchy (org > folder > project) and predefined roles over primitive roles. Prefer custom roles only when predefined roles are too broad.
  • Assign service accounts (SAs) to workloads. Do not reuse the default Compute Engine or App Engine SAs. One SA per workload boundary simplifies least privilege and rotation of trust.
  • Enforce least privilege by granting the minimum set of permissions at the narrowest resource scope.
  • Impersonation: Prefer short‑lived credentials via Service Account Token Creator to let humans, CI/CD, or other services obtain ephemeral access without storing keys:
    • Grant roles/iam.serviceAccountTokenCreator on the target SA to the calling identity.
    • Example: gcloud auth print-access-token –impersonate-service-account sa-ci@proj.iam.gserviceaccount.com
  • Workload Identity
    • GKE: Use Workload Identity to bind Kubernetes service accounts to Google service accounts; tokens are projected and exchanged automatically—no JSON keys.
    • External workloads: Use Workload Identity Federation to exchange OIDC/SAML credentials (for example, from GitHub Actions or on‑prem) for Google access tokens without storing long‑lived keys.
  • Failure modes and trade-offs
    • Overbroad roles or wide-scope grants lead to lateral movement. Missing Token Creator privileges block impersonation flows. JSON key files increase breach blast radius.

• User authentication with OAuth 2.0, OpenID Connect, and Google Identity

  • For end-user auth, use OIDC with Google as IdP or a corporate IdP; validate ID tokens server-side. For API access, use OAuth 2.0 access tokens with appropriate scopes.
  • Validate tokens: verify iss, aud, exp, iat, and signature using the IdP’s JWKs; cache JWKS and enforce key rotation.
  • For mobile/SPA backends, favor Authorization Code flow with PKCE. Avoid implicit flows.
  • For service-to-service, use OAuth 2.0 Service Account JWT flow or mTLS; avoid static API keys.
  • Example (token impersonation with gcloud): gcloud auth application-default print-access-token –impersonate-service-account api-sa@p.iam.gserviceaccount.com
  • Failure modes
    • Not validating aud/iss allows token confusion. Accepting expired tokens, or not rotating JWKs, increases risk. Using refresh tokens in mobile apps exposes long-lived credentials.

• Identity-Aware Proxy (IAP) for browser access

  • Use IAP to front HTTP apps on Cloud Run, GKE, or Compute Engine without embedding auth logic. Enforce “IAP-secured Web App User” for access.
  • Apps receive a signed header (x-goog-iap-jwt-assertion). Verify the JWT to trust user identity and email; don’t rely on X-Forwarded-* for authn.
  • Common pitfalls: bypass paths not routed through IAP, misconfigured backend firewall, or trusting client IP headers without Cloud Load Balancing integrity.

Secrets, Keys, and Encryption

• Secret Manager

  • Store API keys, DB passwords, and webhook secrets in Secret Manager. Rely on versioning, IAM controls, and audit logs.
  • Access patterns
    • Fetch at startup and cache in-memory; refresh on secret change signals (Pub/Sub notifications).
    • Avoid baking secrets into images or environment variables. If env vars are used, ensure they never get logged or dumped to crash reports.
  • Rotation
    • Automate with Cloud Scheduler + Cloud Functions/Run to create new versions, update dependents, and deprecate old ones.
    • Example: gcloud secrets versions access latest –secret db-password
  • Failure modes
    • Excessive Secret Manager calls per request add latency and risk quota exhaustion. Missing roles/secretAccessor causes runtime 403s.

• Cloud KMS and application encryption

  • Use envelope encryption: a locally generated data encryption key (DEK) encrypts data; Cloud KMS customer-managed key (CMEK) encrypts the DEK (KEK).
  • Rotate keys regularly; plan for re-encryption. Prefer “decrypt old, encrypt new” on write; bulk re-encryption jobs for at-rest data are costlier.
  • Enable CMEK for services (BigQuery, GCS, Pub/Sub, Cloud SQL, etc.) when required by compliance. Keep KMS keys in the same region as data.
  • Example CLI:
    • Encrypt: gcloud kms encrypt –location=global –keyring=app-kr –key=data-key –plaintext-file=note.txt –ciphertext-file=note.txt.enc
    • Decrypt: gcloud kms decrypt –location=global –keyring=app-kr –key=data-key –ciphertext-file=note.txt.enc –plaintext-file=note.txt
  • Use well-vetted crypto libraries (for example, Tink) to avoid implementation errors.
  • Failure modes
    • Location mismatches prevent CMEK use. Per-request KMS decrypt adds latency; cache DEKs in memory with rotation awareness. Missing roles/cloudkms.cryptoKeyEncrypterDecrypter yields 403s.

Authorization, APIs, and Perimeter Security

• Application authorization

  • Role-based checks: simple, fast, but coarse. Attribute-based access control (ABAC) uses user attributes, resource attributes, and context (time, device posture) for fine-grained decisions.
  • Centralize policy evaluation or use a sidecar/OPA; consistently propagate identity and tenant claims through microservices.
  • Multi-tenancy patterns
    • Embed tenant_id in auth tokens and enforce it in every data access path; use row-level filtering or separate datasets per tenant for strict isolation.
    • Consider per-tenant service accounts or KMS keys if regulatory isolation is required.
  • Failure modes
    • Insecure direct object references (IDOR) due to missing tenant checks. Divergent authorization logic across services causing inconsistent enforcement.

• Secure API design

  • Validate and normalize all inputs; reject oversized payloads. Enforce strong content types. Threat-model file uploads; use signed URLs for large objects.
  • Rate limiting and quotas: use Cloud Armor rate limiting or Apigee to mitigate abuse and 429s. Implement exponential backoff with jitter on clients.
  • CORS
    • Return minimal Access-Control-Allow-*; avoid wildcard origins on credentialed requests. Preflight caching reduces latency.
  • CSRF defenses
    • Prefer stateless APIs with bearer tokens in Authorization headers. For cookie-based sessions, use SameSite=strict or lax, secure cookies, and a CSRF token (double-submit or synchronizer).
  • Example (Cloud Armor rule):
    • gcloud compute security-policies rules create 1000 –security-policy web-policy –expression “request.path.matches(’/api/’)” –action rate_based_ban –rate-limit-threshold-count 100 –rate-limit-threshold-interval-sec 60
  • Failure modes
    • Naive IP-based limiting can be bypassed with IPv6 or proxies. Overly permissive CORS enables token leakage. Missing CSRF tokens with cookies allows session riding.

• Network controls and data perimeter

  • Use hierarchical firewall policies and VPC firewall rules; allow Google Front Ends health checks when behind HTTP(S) Load Balancing.
  • Example:
    • gcloud compute firewall-rules create allow-lb –network prod –allow tcp:80,tcp:443 –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
  • Cloud Armor provides WAF, bot defense, and geo/IP restrictions; tune rules and review false positives.
  • Private service access provides private IP connectivity to Google managed services (for example, Cloud SQL, Memorystore); avoid public egress and IP allowlists.
  • VPC Service Controls reduce data exfiltration risk by creating perimeters around supported services; combine with Access Context Manager for device/location context.
  • Failure modes
    • Misconfigured perimeters block CI/CD or break service-to-service calls. Missing PSA allocations prevent private IP attachment. Overly strict WAF rules can cause availability incidents.

Supply Chain Security, Logging, and Response

• Software supply-chain security

  • Store artifacts in Artifact Registry; enforce vulnerability scanning. Fail builds on high/critical CVEs with policy exceptions tracked.
  • Pin dependencies and base images; avoid “latest”. Generate and verify SBOMs. Use Binary Authorization to require signed images before deploy.
  • Sign images with Cosign and record provenance; adopt SLSA-aligned build practices. Use Workload Identity Federation for CI to eliminate JSON keys.
  • Failure modes
    • Unpinned dependencies pull vulnerable releases. Skipping provenance allows image tampering. Storing registry credentials or service account keys in CI logs leaks secrets.

• Security logging and monitoring

  • Enable Admin Activity and Data Access Audit Logs for critical projects and services. Route logs to a dedicated project with restricted access.
  • Create Cloud Logging metrics for auth failures, permission denials, and policy evaluation errors; alert via Cloud Monitoring.
  • Example (custom counter metric idea): Count 401/403 rates on /api/* and alert on baseline deviations.
  • Threat triage and remediation
    • Use Security Command Center to aggregate findings; create playbooks for key scenarios (key leakage, brute force, anomalous IAM changes).
    • Automate common remediations (revoke tokens, disable keys, rotate secrets, quarantine service accounts).
  • Privacy-aware design
    • Minimize PII; tokenize where possible. Redact sensitive values from logs; use Cloud DLP for classification. Apply least-retention and regional storage policies.
  • Failure modes
    • Disabling Data Access logs blinds detection of exfiltration. High-cardinality labels explode costs. Logging secrets creates durable exposure.

Practical Problem Scenario

Acme Retail builds a multi-tenant analytics portal on Cloud Run with a React frontend, a Python API, and BigQuery datasets per tenant. Requirements include SSO for employees and customers, tenant isolation, secret and key management, private database access, WAF and rate limiting, and a strong CI/CD posture without long-lived keys.

Approach:

1. Establish identities and least privilege

• Create a dedicated Google service account per microservice (api-sa, ingest-sa). Grant least-privilege roles at project or dataset scope (for example, roles/bigquery.dataEditor on tenant datasets).
• Rationale: Per-service SAs scope blast radius and simplify rotation; narrow-scoped roles reduce lateral movement.

2. Use Workload Identity Federation for CI/CD

• Configure GitHub Actions OIDC to impersonate deployer-sa via roles/iam.workloadIdentityUser and roles/iam.serviceAccountTokenCreator. Deploy to Cloud Run with impersonated tokens.
• Rationale: Removes JSON keys from CI; short-lived credentials reduce theft risk.

3. Frontend and user authentication

• Configure IAP on the HTTPS Load Balancer in front of Cloud Run services. Integrate Google as IdP for employees and customer IdP via federation. Restrict access with the “IAP-secured Web App User” role to authorized groups.
• Rationale: Centralized auth for browser apps; no auth logic in services; SSO support.

4. Validate IAP identity in the API

• Verify the x-goog-iap-jwt-assertion header in the API; enforce presence of a tenant_id claim (mapped from group or custom claim).
• Rationale: Strong identity guarantee from IAP; embedding tenant context in each request ensures consistent downstream authorization.

5. Implement tenant-aware authorization

• Store per-tenant policies and map users to roles (viewer, analyst, admin). On each request, check role and ABAC conditions (tenant_id match, feature flags).
• Rationale: Combines RBAC simplicity with ABAC flexibility; eliminates IDOR by enforcing tenant scoping.

6. Secrets and database access

• Store DB passwords and third-party API tokens in Secret Manager; grant roles/secretmanager.secretAccessor to only the API SA. Access secrets on startup and refresh on Pub/Sub rotation notifications.
• Rationale: No hard-coded credentials; auditable access; timely rotation without restarts.

7. Data encryption and CMEK

• Create a Cloud KMS keyring and keys per environment. Enable CMEK on BigQuery datasets and Cloud Storage buckets. Use envelope encryption for any application-stored sensitive blobs.
• Rationale: Customer-managed keys meet compliance and provide separation of duties.

8. Private connectivity and service perimeter

• Use private service access for Cloud SQL private IP. Create VPC Service Controls perimeter for the project hosting BigQuery and GCS; add Access Context policies for corporate-admin access.
• Rationale: Eliminates public egress paths; reduces data exfiltration risk.

9. API security, rate limiting, CORS, and CSRF

• Apply a Cloud Armor security policy with WAF managed rules and rate limiting to the external HTTP(S) LB; tune allowlists for partner IPs. Configure strict CORS (explicit origins) for the API and use Authorization bearer tokens; cookies are not used.
• Rationale: Mitigates OWASP Top 10 and abuse; prevents cross-origin credential leakage; avoids CSRF by not using cookies.

10. Supply-chain hardening

• Store images in Artifact Registry. Enable vulnerability scanning and fail builds on critical CVEs. Sign images with Cosign and enforce Binary Authorization to require Acme signatures in prod.
• Rationale: Prevents unvetted artifacts from running; maintains provenance.

11. Logging, monitoring, and alerts

• Enable Audit Logs and route to a centralized project. Create log-based metrics for 401/403 spikes, permissionDenied from BigQuery, and Secret Manager access. Alert on anomalies and set up Cloud Monitoring uptime checks for the public endpoints.
• Rationale: Early detection of auth failures and misuse; availability monitoring.

12. Incident playbooks and rotation drills

• Document steps to revoke compromised SAs (disable, rotate keys, invalidate tokens), rotate secrets, and re-encrypt with new KMS versions. Test quarterly.
• Rationale: Prepared, repeatable response minimizes downtime and data exposure.

This design ensures short-lived, verifiable identities at every hop, consistent tenant-aware authorization, protected secrets and keys, private data paths, and a hardened supply chain, with observability and response workflows that keep the system resilient under attack and during routine operations.

← Application Data · All domains · Continuous Delivery →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →