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.

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.

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

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.

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.