Prepare and test your skills
Prepare and test your skills
Secret and Parameter Lifecycle Engineering is the practice of storing sensitive application configuration in managed stores and controlling its replication, encryption, access, and audit from pipeline to runtime. In Google Cloud, Secret Manager (opens in a new tab) provides the IAM-controlled store for secrets, while Cloud Key Management Service (Cloud KMS) (opens in a new tab) provides customer-controlled encryption keys that protect data at rest. Centralized projects for each service let a dedicated team own creation, rotation, and auditing to meet compliance requirements.
Secret Manager is the centralized store for sensitive application secrets used by pipelines and workloads. A dedicated centralized project hosts Secret Manager so one team owns creation, versioning, and auditing instead of scattering secrets across application projects. Access flows from the workload identity to Secret Manager, and Secret Manager grants or denies the read based on Identity and Access Management permissions. This separation means pipeline execution and application runtime depend on Secret Manager for secret material, while ownership and audit remain with the central security team.
Replication policy in Secret Manager controls where secret payloads are stored and served from, which affects availability, performance, and data residency. The automatic replication policy is the recommended default because it meets the availability and performance needs of most workloads without manual location management. User-managed replication is chosen only when the workload has specific location requirements, and those locations are selected through the API when the secret is created.
| Replication option | Management | Choose when |
|---|---|---|
| Automatic replication | Google Cloud chooses serving locations | Default for most workloads needing availability and performance |
| User-managed replication | You select locations via API at creation | Workload has specific residency or location constraints |
Exam tip: Use automatic replication by default; use API-selected locations only when a workload has specific location requirements.
Encryption lifecycle in Google Cloud starts with Google default encryption at rest and in transit, with customer-managed encryption keys (CMEKs) added when regulatory or rotation control is required. Cloud KMS (opens in a new tab) creates and holds CMEKs as software-based keys or hardware security module (HSM)-protected keys, with Cloud KMS Autokey automating provisioning and assignment. Cloud External Key Manager (Cloud EKM) lets you use key material sourced from a third-party system outside Google Cloud while still enabling Google Cloud encryption.
The key hierarchy depends on location alignment between the key ring and the protected data:
A centralized Cloud KMS project lets a dedicated team manage and audit keys separately from application teams. Key rings must be created in a location compatible with the data, so data in us-east1 and us-west1 requires a key ring in the US multi-region, and predefined dual-regions such as asia1, eur4, and nam4 require a key ring in that same dual-region. When a workload reads a secret or object, data flows from the storage service to Cloud KMS for decryption, so loss of access to the key blocks access to the data.
Least-privilege access for secrets means every pipeline step and runtime workload receives only the permissions needed for its task. Identity and Access Management (IAM) (opens in a new tab) authorizes who can act on which secret, and service accounts used by CI/CD pipelines should receive only the secret accessor roles they require. Workload Identity Federation lets applications on Google Kubernetes Engine (GKE) or outside Google Cloud access Secret Manager without long-lived service account keys. Audit logging, regular permission review, and IAM Recommender suggestions further reduce excess privilege by identifying unused access.
Defense in depth extends that boundary beyond IAM to the network path. VPC Service Controls (opens in a new tab) creates perimeters around Google Cloud APIs including Secret Manager and Cloud KMS to help prevent data exfiltration, while strict egress rules and private connectivity keep secret reads off the public internet. Together, IAM controls who can request a secret and VPC Service Controls controls where that request can travel.
Organization Policy Service enforces centralized guardrails that prevent high-risk secret and encryption configurations across organization, folder, and project levels. The constraint constraints/gcp.restrictNonCmekServices requires CMEK protection for listed services, such as bigquery.googleapis.com, storage.googleapis.com, and aiplatform.googleapis.com. When this policy applies to a service, resource creation without a customer-managed key is denied, so pipelines cannot deploy non-compliant storage. Complementary constraints restrict resource locations, limit service account creation, and disable external IP allocation, which together keep secret-bearing workloads inside approved boundaries.
Workload Identity Federation (opens in a new tab) is a keyless authentication method that lets workloads running outside Google Cloud access Google Cloud APIs without long-lived service account keys. The external workload presents a credential issued by its own external identity provider (IdP), and Google Cloud exchanges that credential for short-lived Google Cloud credentials. This exchange removes the need to download, store, and rotate RSA service account keys in pipeline configuration and secrets.
Service account keys are the private portion of a service account public/private RSA key pair that can authenticate as the service account from anywhere. The keys are long-lived, must be stored as secrets, and create operational risk if they are leaked, over-shared, or not rotated. Identity and Access Management treats service account keys as a security risk and recommends a more secure alternative whenever possible.
Workload Identity Federation replaces stored keys with short-lived credentials issued on demand. The workload obtains an environment-native credential, exchanges it with the Security Token Service (STS) for a short-lived federated token, and then uses that token to call Google Cloud APIs. The resulting OAuth 2.0 access tokens expire by default after 1 hour, so there is no persistent secret to manage in the pipeline. This model improves security and reduces maintenance because rotation and secure storage of keys are no longer required.
Supported external environments include:
A workload identity pool is the IAM trust boundary that represents external identities to Google Cloud. A pool lives in a Google Cloud project, and best practice is to manage pools and providers in a dedicated project separate from application projects. The pool trusts one or more external IdPs through its configured providers.
A workload identity pool provider describes a single external IdP and how Google Cloud validates its credentials. The provider stores the IdP issuer URL, the expected audience, and the mechanism for verifying tokens, such as OIDC discovery metadata and the JSON Web Key Set (JWKS). For Kubernetes, the cluster must expose OIDC metadata and JWKS, which requires the OIDC issuer feature on AKS and Kubernetes 1.20 or later with ServiceAccount token volume projection on self-hosted clusters.
Attribute mapping and conditions control how external token claims become Google Cloud principals. The attribute mapping translates claims from the external token, such as repository, branch, AWS role, Azure principal, or Kubernetes namespace and service account name, into federated identity attributes including google.subject. An attribute condition then restricts which external identities are allowed to federate, so only selected repositories, service accounts, or VMs can obtain tokens. You configure the pool, provider, mapping, and condition once per external environment and reuse them for many workloads and Google Cloud projects.
Token exchange flow for external workloads is the ordered sequence where each credential depends on the previous credential. Traffic flows from the external workload to STS and then from the workload to the target Google Cloud API, while trust flows from the external IdP to the workload identity pool provider to IAM allow policies. Client libraries, the gcloud CLI, and Terraform perform this exchange automatically when pointed at a credential configuration file.
Direct resource access and service account impersonation are two authorization models that differ in which IAM principal receives the role. Direct access grants roles to the federated principal itself, while impersonation grants roles to a Google service account that the federated principal acts as. Impersonation depends on the IAM Credentials API and on granting the federated principal the roles/iam.workloadIdentityUser role on the service account, while direct access depends only on granting the federated principal roles on the target resource.
| Model | IAM principal that gets the role | How access works |
|---|---|---|
| Direct resource access | Federated principal, such as principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.* | STS token authenticates directly to the resource; no Google service account is involved |
| Service account impersonation | IAM service account that the workload impersonates | STS token is exchanged through the IAM Credentials API for a short-lived service account access token, and the service account identity accesses the resource |
Direct resource access is recommended when the target API supports federated identities because it avoids managing an extra service account and impersonation permission. Impersonation is required when an API or existing automation only accepts a service account identity or when many federated identities should share one audited service account identity.
Exam tip: A credential configuration file contains no private key and does not need to be kept confidential, while a service account key contains a private key and must be protected as a secret.
A credential configuration file tells pipeline tools where to find the external credential and which pool, provider, and optional service account to use. The file is generated with gcloud iam workload-identity-pools create-cred-config and records the pool provider name, the credential source file or URL, and the impersonated service account email when impersonation is used. Client libraries discover the file through the GOOGLE_APPLICATION_CREDENTIALS environment variable, read the external token from the configured path, and handle STS exchange and refresh.
For Kubernetes workloads outside Google Cloud, the Pod mounts two volumes with distinct roles. The projected token volume exposes the Kubernetes ServiceAccount token at a path such as /var/run/service-account/token with the audience expected by the provider, and a ConfigMap contains the credential configuration file. The container sets GOOGLE_APPLICATION_CREDENTIALS to the mounted configuration path, so application code authenticates without embedded keys. For Workload Identity Federation for GKE (opens in a new tab), Google Cloud manages the pool and provider automatically with the fixed pool name PROJECT_ID.svc.id.goog, and the Kubernetes ServiceAccount is bound to IAM through allow policies instead of a manually created provider.
Automated certificate provisioning and mapping is the use of Certificate Manager (opens in a new tab) to issue, attach, select, and renew SSL/TLS certificates for external load balancers and application endpoints without manual replacement. Certificate Manager (2nd gen) centralizes this lifecycle across load balancers, Google Kubernetes Engine (GKE) workloads, Compute Engine instances, and hybrid environments through issuance configurations, certificate maps, and integration with Certificate Authority Service and Public CA. Google-managed certificates renew automatically once domain ownership is proven, while self-managed certificates require an orchestrated rotation through certificate maps.
Certificate maps are Certificate Manager resources that bind one or more certificates to a load balancer's target proxy and control which certificate is served during the TLS handshake. A certificate map is designed to scale, supporting thousands of certificate entries by default and capable of handling millions of certificates for large multi-domain deployments. When a load balancer uses a certificate map, the map entries take precedence over other certificates, such as Compute Engine SSL certificates attached to the same proxy. Certificate maps also define certificate selection logic, so if a client's hostname does not match any entry, the load balancer returns the designated primary certificate as the fallback.
Domain authorization is the proof of domain ownership that Certificate Manager requires before it issues a Google-managed certificate. The authorization method determines when provisioning can start, which network designs are allowed, and whether wildcard domains are supported. Traffic for validation flows from the public certificate authority to either the load balancer or the DNS record, depending on the method chosen.
| Feature | Load balancer authorization | DNS authorization |
|---|---|---|
| Setup complexity | No additional configuration or changes to DNS configuration required | Requires creating a DNS authorization and adding its CNAME record to DNS configuration |
| Network security | Load balancer must be fully internet-accessible on port 443, including DNS for all domains served | Works with complex configurations, ports other than 443, and CDN layers in front of the target proxy |
| Provisioning speed | Faster, but only after the load balancer is fully set up and serving traffic | Can provision in advance, before the target proxy is ready to serve traffic |
| Wildcard certificates | Not supported | Supported |
Choose load balancer authorization when the global Application Load Balancer is already serving traffic on port 443 and no wildcards are needed. Choose DNS authorization when certificates must be ready before the proxy serves traffic, when the frontend uses non-443 ports or a CDN layer, or when a single certificate must cover wildcard domains.
Exam tip: Only DNS authorization supports wildcard certificates; load balancer authorization requires the load balancer to be live and reachable from the internet on port 443.
Issuance configurations are Certificate Manager (2nd gen) policies that automate certificate generation and rotation for Cloud Load Balancing and managed workloads. Each issuance configuration links a workload identity pool to a Certificate Authority Service pool, so Google Cloud automatically issues and renews certificates before they expire. The policy controls three rotation settings: certificate lifetime, key algorithm, and rotation window.
For managed workloads, managed workload identity gives Compute Engine and GKE workloads an attested identity plus certificates and trust anchors for mutual TLS (mTLS) authentication. Identities are grouped into a workload identity pool that acts as the trust boundary, and linking that pool to a CA Service pool eliminates manual credential management. For Cloud Load Balancing, the same mechanism automates TLS provisioning and renewal, including mTLS between Application Load Balancers and their backends. Certificate Manager (2nd gen) also observes certificates that Certificate Authority Service auto-manages for other services, such as Cloud SQL, Vertex AI Agent Engine, and Gemini Enterprise, for inventory and health monitoring.
Self-managed certificates are certificates obtained from an external or private certificate authority (CA) that, unlike Google-managed certificates, must be manually replaced before they expire. Certificate maps orchestrate a zero-downtime rotation by letting the new certificate be staged and then swapped as the map entry reference in a single update. The workflow depends on the certificate resource, so the map always points to a valid certificate during the change.
UpdateCertificate method on the existing certificate resource; if domain names differ, first use the CreateCertificateRequest method with the new PEM files, then use the UpdateCertificateMapEntry method to replace the old reference with the new one.The final swap must complete in one API call without resulting in any downtime, so clients negotiating new handshakes move from the old certificate to the new certificate with no gap in serving.
roles/iam.workloadIdentityUser on the service account.Automatic replication in Secret Manager is the recommended default because Google Cloud chooses serving locations to meet the availability and performance needs of most workloads. User-managed replication should be chosen only when the workload has specific residency or location requirements, with locations selected through the API when the secret is created.
Direct resource access grants roles to the federated principal itself so the Security Token Service (STS) token authenticates directly to the resource without a Google service account. Service account impersonation grants roles to an Identity and Access Management (IAM) service account that the federated principal acts as, which requires granting the federated principal roles/iam.workloadIdentityUser on the service account and using the IAM Credentials API. Direct resource access is recommended when the target API supports federated identities because it avoids managing an extra service account and impersonation permission.
DNS authorization in Certificate Manager should be used when certificates must be ready before the proxy serves traffic, when the frontend uses non-443 ports or a CDN layer, or when a single certificate must cover wildcard domains. Load balancer authorization should be used when the global Application Load Balancer is already serving traffic on port 443 and no wildcards are needed, because only DNS authorization supports wildcard certificates and load balancer authorization requires the load balancer to be live and reachable on port 443.
Your enterprise organization uses GitHub Actions CI/CD workflows to build and deploy multi-tier containerized applications to Google Cloud. Your security team mandates the elimination of all long-lived service account keys to mitigate credential leakage risks. Additionally, you must ensure that only CI/CD pipelines originating from specific repositories within your GitHub organization are permitted to impersonate the target deployment service accounts.
How should you configure Workload Identity Federation to meet these security and operational requirements?
Create a Workload Identity Pool and configure an OIDC Provider for GitHub Actions with attribute mappings and an attribute condition filtering on repository attributes, then grant the specific federated principal impersonation permissions on the deployment service account using the Workload Identity User role.
Configure a Workload Identity Pool and OIDC Provider, and grant the Workload Identity User role on the deployment service account to all members of the workload identity pool principalSet.
Generate a long-lived service account JSON key, store it encrypted inside Google Secret Manager, and configure the GitHub Actions workflow to fetch the key via a bootstrap service account.
Register the GitHub runner infrastructure as an attached cluster in GKE Multi-Cloud and map Kubernetes Service Accounts using fleet-wide Workload Identity Federation.
Last updated