An enterprise maintains a legacy on-premises continuous integration and continuous deployment (CI/CD) system that cannot support Workload Identity Federation and requires a user-managed service account key to deploy infrastructure to Google Cloud. Security policy mandates: Service account keys must be automatically rotated every 30 days without human intervention. Newly generated keys must be stored centrally and securely fetched dynamically by the CI/CD pipeline. Rotation must maintain continuous deployment availability by avoiding key revocation before the new credential is deployed. In the event of credential leakage, compromised keys must be rapidly invalidated without disrupting the service account itself. Which architecture should the security team implement to satisfy these requirements?

Configure Secret Manager with automated rotation schedules targeting a Cloud Function via Pub/Sub, where the function generates a new service account key via the IAM API, adds it as a new secret version, and deletes the prior key after a grace period.: ### What Automated Secret Manager Key Rotation Is **Secret Manager** provides native support for automated secret rotation by integrating with **Cloud Pub/Sub** and serverless compute such as **Cloud Functions** or **Cloud Run**. This pattern decouples credential consumers from key creation lifecycles, allowing workloads to query the `latest` version of a secret dynamically while automated background workflows manage creation, delivery, and disposal of underlying credentials. ### How It Meets the Requirements - **Automated 30-Day Rotation:** Setting a rotation schedule and period (e.g., 30 days) on the Secret Manager secret triggers periodic rotation notifications to a dedicated Pub/Sub topic. - **Centralized & Dynamic Storage:** The subscribed Cloud Function receives the rotation event, calls the Google Cloud IAM API (`projects.serviceAccounts.keys.create`) to generate a new key, and writes the JSON key payload directly as a new secret version using the Secret Manager API (`projects.secrets.addVersion`). The CI/CD toolchain retrieves `projects/{project}/secrets/{secret}/versions/latest` at runtime. - **Zero-Downtime Grace Periods:** The rotation function creates and publishes the new key version first, ensuring downstream systems have access to the valid new credential before scheduling or executing the deletion of the old key version via `projects.serviceAccounts.keys.delete`. - **Threat Mitigation and Revocation:** If a key is compromised, security teams or automated incident response playbooks can immediately invoke the IAM API to disable (`projects.serviceAccounts.keys.disable`) or delete the specific compromised key ID and destroy the corresponding Secret Manager version without deleting or modifying the underlying service account identity or its IAM bindings. ### Key Advantages - **Eliminates Static Key Footprints:** Client systems no longer store static private keys on local disks or configuration files; credentials are read from Secret Manager at execution time. - **Auditability and Observability:** Every rotation action, key creation, and secret access request is logged comprehensively in **Cloud Audit Logs** (Admin Activity and Data Access). - **Granular Least Privilege:** The rotating Cloud Function requires only `roles/iam.serviceAccountKeyAdmin` on the target service account and `roles/secretmanager.admin` on the secret, maintaining tight privilege boundaries. ### Why This Is Optimal This architecture completely automates the service account key lifecycle natively within Google Cloud while keeping external legacy pipelines operational and providing fine-grained incident response capabilities for key invalidation.

Automated Service Account Key Rotation Secret Manager 3 | Professional Cloud Security Engineer

Automated Service Account Key Rotation Secret Manager 3

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise maintains a legacy on-premises continuous integration and continuous deployment (CI/CD) system that cannot support Workload Identity Federation and requires a user-managed service account key to deploy infrastructure to Google Cloud. Security policy mandates:

Service account keys must be automatically rotated every 30 days without human intervention.
Newly generated keys must be stored centrally and securely fetched dynamically by the CI/CD pipeline.
Rotation must maintain continuous deployment availability by avoiding key revocation before the new credential is deployed.
In the event of credential leakage, compromised keys must be rapidly invalidated without disrupting the service account itself.

Which architecture should the security team implement to satisfy these requirements?

Configure Secret Manager with automated rotation schedules targeting a Cloud Function via Pub/Sub, where the function generates a new service account key via the IAM API, adds it as a new secret version, and deletes the prior key after a grace period.

Configure IAM Policy Simulator to run on a 30-day cron schedule, create a new service account key, store the key in a Cloud Storage bucket with Object Versioning, and revoke all IAM roles on the existing key.

Use Cloud Scheduler to invoke a Cloud Build pipeline that deletes the service account, recreates the service account with the same email address, generates a key, and updates Secret Manager.

Configure Cloud Key Management Service (Cloud KMS) automatic key rotation on a symmetric key that encrypts the service account private key stored in an application configuration file.

Professional Cloud Security Engineer

Automated Service Account Key Rotation Secret Manager 3

Related questions