What replication policies does Secret Manager support?

Secret Manager offers two replication policies: automatic and user-managed. Automatic replication stores the secret across multiple Google-managed regions for high availability and is the simplest option. User-managed replication lets you choose specific regions where the secret data is stored, which is required for data residency compliance or to keep secrets geographically close to the services that use them. With user-managed replication, you can also specify customer-managed encryption keys (CMEK) per region.

How does secret versioning work?

Each secret can have multiple versions, and each version contains the actual secret value. Versions are numbered sequentially and can be in one of three states: enabled (accessible), disabled (exists but not accessible), or destroyed (permanently deleted). You can access a specific version by number or use the 'latest' alias to always get the most recent enabled version. Disabled versions can be re-enabled, but destroyed versions cannot be recovered.

How do I set up automatic secret rotation?

You configure a rotation schedule on the secret with a rotation period (e.g., every 30 days) and optional next rotation time. When rotation is due, Secret Manager publishes a message to a configured Pub/Sub topic. A Cloud Function subscribed to that topic generates the new secret value, adds it as a new version, and updates the dependent service. Secret Manager does not generate new values itself — your rotation function must implement the logic for creating new credentials and updating consumers.

GCP Secret Manager Config Builder

IAM & SecurityGCP

Build Secret Manager secret configurations with replication, rotation, and CMEK encryption.

Last verified: May 2026

Secret Manager Configuration

Build Secret Manager secret configurations with replication, rotation policies, and CMEK encryption.

Required Fields

namereplication

{
  "name": "projects/my-project/secrets/database-credentials",
  "replication": {
    "userManaged": {
      "replicas": [
        {
          "location": "us-central1",
          "customerManagedEncryption": {
            "kmsKeyName": "projects/my-project/locations/us-central1/keyRings/secrets-ring/cryptoKeys/secrets-key"
          }
        },
        {
          "location": "us-east1",
          "customerManagedEncryption": {
            "kmsKeyName": "projects/my-project/locations/us-east1/keyRings/secrets-ring/cryptoKeys/secrets-key"
          }
        }
      ]
    }
  },
  "rotation": {
    "nextRotationTime": "2026-06-14T00:00:00Z",
    "rotationPeriod": "7776000s"
  },
  "topics": [
    {
      "name": "projects/my-project/topics/secret-rotation-notifications"
    }
  ],
  "expireTime": "2027-03-14T00:00:00Z",
  "labels": {
    "environment": "production",
    "team": "platform",
    "compliance": "soc2"
  },
  "versionAliases": {
    "current": "3",
    "previous": "2"
  }
}

Generated Output

Output will appear here...

About This Tool

Google Cloud Secret Manager provides a centralized, secure store for API keys, passwords, certificates, and other sensitive data with versioning, automatic rotation, and fine-grained IAM access control. Creating secrets involves specifying replication policies (automatic or user-managed across specific regions), labels, expiration times, rotation schedules, and Pub/Sub notification topics for secret events. This builder helps you configure secrets with correct replication policies, IAM bindings, rotation schedules, and consumer-side access patterns, generating configurations for gcloud CLI, Terraform, and client library code.

Real-World Scenario

Your team is migrating database passwords from environment variables in Cloud Run services to Secret Manager. The builder generates: secrets with automatic replication, labels for environment/service, IAM bindings granting the Cloud Run service account Secret Accessor role on specific secrets only. The Cloud Run code uses 'projects/X/secrets/Y/versions/latest' to always fetch the current version. When DB passwords need rotation, the ops team adds a new version — services pick it up on next request, no Cloud Run redeploy needed.

When to Use This Tool

•Building a secret configuration with user-managed replication pinned to specific regions for data residency compliance
•Configuring automatic rotation schedules with Pub/Sub notifications that trigger a Cloud Function to generate new secret values
•Creating secrets with expiration dates for temporary credentials that automatically become inaccessible after a deadline
•Generating Terraform configurations for secrets with IAM bindings that grant Secret Accessor role to specific service accounts

Pro Tips

TIP

Always use 'latest' alias in application code, not specific version numbers. When you rotate the secret (creating a new version), apps automatically pick up the new value on next fetch. Hardcoding version numbers turns rotation into a deploy-required operation, which defeats the point of having rotation.

TIP

User-managed replication is required for compliance scenarios but adds complexity. For the 95% case where data residency isn't a hard requirement, automatic replication is dramatically simpler — and Google manages region selection for optimal availability.

TIP

Secret Manager doesn't generate new secret values during rotation — it just notifies your rotation function via Pub/Sub. You still have to write the rotation logic (generate new credentials with the upstream service, write to Secret Manager). This is more work but more flexible than AWS Secrets Manager's built-in rotators.

How It Works Under the Hood

The builder constructs Secret Manager secret resources with: name, replication policy (automatic or user-managed with region list and optional CMEK), labels, expiration time, rotation schedule (rotation_period and next_rotation_time) and Pub/Sub notification topic. Output is generated as gcloud secrets create commands and Terraform google_secret_manager_secret resources. It also generates the prerequisite IAM bindings (Secret Accessor for consumers, Secret Manager Admin for ops).

Frequently Asked Questions

What replication policies does Secret Manager support?: Secret Manager offers two replication policies: automatic and user-managed. Automatic replication stores the secret across multiple Google-managed regions for high availability and is the simplest option. User-managed replication lets you choose specific regions where the secret data is stored, which is required for data residency compliance or to keep secrets geographically close to the services that use them. With user-managed replication, you can also specify customer-managed encryption keys (CMEK) per region.
How does secret versioning work?: Each secret can have multiple versions, and each version contains the actual secret value. Versions are numbered sequentially and can be in one of three states: enabled (accessible), disabled (exists but not accessible), or destroyed (permanently deleted). You can access a specific version by number or use the 'latest' alias to always get the most recent enabled version. Disabled versions can be re-enabled, but destroyed versions cannot be recovered.
How do I set up automatic secret rotation?: You configure a rotation schedule on the secret with a rotation period (e.g., every 30 days) and optional next rotation time. When rotation is due, Secret Manager publishes a message to a configured Pub/Sub topic. A Cloud Function subscribed to that topic generates the new secret value, adds it as a new version, and updates the dependent service. Secret Manager does not generate new values itself — your rotation function must implement the logic for creating new credentials and updating consumers.

Featured In

Secrets Management Across Clouds: Vault, AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.