An enterprise organization stores database credentials in Google Cloud Secret Manager. The security team must implement continuous credential hygiene for these database secrets according to the following requirements: The credentials must be automatically rotated on a recurring 30-day schedule without microservice downtime. Secret Manager must emit events to trigger an automated rotation handler service when a rotation is due. The rotation service must generate a new credential, apply it to the database, add a new secret version to Secret Manager, validate application health, and disable the superseded secret version. The architecture must follow Google Cloud least-privilege security best practices for service integration. Which workflow and architectural configuration should the security engineer implement?

Configure a rotation schedule with a 30-day rotation period and a target Pub/Sub topic on the secret. Grant the Secret Manager Service Agent the Pub/Sub Publisher role on the topic. Deploy a Cloud Function subscribed to the Pub/Sub topic that generates the new credential, updates the database, adds the new version to Secret Manager, and disables the previous version.: ### What Secret Manager Automated Rotation Is **Secret Manager automated rotation** is a native lifecycle management capability that automatically schedules credential updates and invokes custom automation routines via **Cloud Pub/Sub** and serverless compute like **Cloud Functions** or Cloud Run. ### How It Meets the Requirements - **Recurring 30-Day Rotation Schedule**: Setting `next-rotation-time` and `rotation-period=2592000s` (30 days) on the Secret Manager resource instructs Google Cloud to automatically trigger rotation events at the specified interval. - **Pub/Sub Event Integration**: Secret Manager publishes a message containing the secret resource ID and event type (`ROTATION`) to the configured Pub/Sub topic whenever the rotation timer elapses. - **Least-Privilege Service Agent Permissions**: The Google-managed **Secret Manager Service Agent** (`service-@gcp-sa-secretmanager.iam.gserviceaccount.com`) is granted the `roles/pubsub.publisher` role strictly on the designated topic, adhering to least-privilege principles. - **Automated Handler Execution**: A Cloud Function subscribed to the topic acts as the rotation coordinator. It generates new database credentials, updates the database engine, adds a new secret version (`secrets.addVersion`), verifies application access, and sets the state of the older version to **Disabled** (`secrets.versions.disable`). ### Key Advantages and Capabilities - **Zero-Downtime Cutover**: Maintains version history and allows multiple active versions during the rotation handshake until workloads retrieve the newest version. - **Native Lifecycle Governance**: Eliminates the need to maintain external cron daemons, cron servers, or third-party scheduling platforms. - **Granular IAM Boundary**: The rotation Cloud Function operates under a dedicated runtime Service Account restricted to database administration and `roles/secretmanager.secretVersionManager`. - **Automatic Retry Policies**: Pub/Sub provides durable message delivery and automatic acknowledgment retries if the rotation function experiences transient errors. ### Why This Is Optimal This architecture leverages the purpose-built Secret Manager rotation framework, ensuring dependable event dispatching, decoupled execution, and continuous credential hygiene without service interruption.

Secret Manager Automated Rotation Workflow Pubsub | Professional Cloud Security Engineer

Secret Manager Automated Rotation Workflow Pubsub

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 organization stores database credentials in Google Cloud Secret Manager. The security team must implement continuous credential hygiene for these database secrets according to the following requirements:

The credentials must be automatically rotated on a recurring 30-day schedule without microservice downtime.
Secret Manager must emit events to trigger an automated rotation handler service when a rotation is due.
The rotation service must generate a new credential, apply it to the database, add a new secret version to Secret Manager, validate application health, and disable the superseded secret version.
The architecture must follow Google Cloud least-privilege security best practices for service integration.

Which workflow and architectural configuration should the security engineer implement?

Configure a rotation schedule with a 30-day rotation period and a target Pub/Sub topic on the secret. Grant the Secret Manager Service Agent the Pub/Sub Publisher role on the topic. Deploy a Cloud Function subscribed to the Pub/Sub topic that generates the new credential, updates the database, adds the new version to Secret Manager, and disables the previous version.

Configure an Eventarc trigger listening for Secret Manager audit log events in Cloud Logging. Direct Eventarc to execute a Cloud Function that rotates the database password and triggers a Cloud Build pipeline to inject the cleartext password into application environment variables.

Set a 30-day expiration timestamp on the secret in Secret Manager. Configure a Cloud Storage object notification to trigger a Cloud Function that generates new credentials, stores them in a Cloud Storage bucket, and increments the secret version counter.

Create a Cloud Scheduler job that runs every 30 days to invoke a Cloud Function over HTTP. Configure the Cloud Function to use the default Compute Engine service account to update the database, overwrite the existing secret payload using the Secret Manager REST API, and destroy the previous payload.

Professional Cloud Security Engineer

Secret Manager Automated Rotation Workflow Pubsub

Related questions