Goal: credentials rotate automatically without humans pasting new values.
How it works: you set a rotation schedule on the secret; Secret Manager publishes a SECRET_ROTATE message to your Pub/Sub topic at each rotation time. YOUR subscriber does the actual rotation (generate value, add version, update the external system).
Setup:
```
gcloud secrets create [ID] --replication-policy automatic --rotation-period [PERIOD] --next-rotation-time [ISO-TIME] --topics projects/[P]/topics/[TOPIC]
```
Then deploy a subscriber (Cloud Run function or service) on that topic that:
1. Receives SECRET_ROTATE.
2. Generates the new credential value (or calls the external system's API to rotate).
3. Adds it as a new secret version.
4. Optionally disables the old version after consumers have picked up the new one.
Traps:
- Secret Manager does NOT generate the new value. If nothing subscribes to the topic, rotations "happen" and nothing changes. Monitor the subscriber.
- Consumers reading `latest` flip to the new value immediately; consumers pinning versions do not. Coordinate the consumer strategy with the rotation (see the destroyed-version error skill).
- The rotation function needs secretmanager.admin-ish rights on the secret (add versions) but consumers only need secretAccessor. Separate identities.
- Test rotation end to end in a sandbox secret before pointing it at production credentials. A broken rotator that adds garbage versions is worse than no rotation.
- Rotation period minimums and the next_rotation_time format (ISO 8601) are strict; invalid values fail at set time.
Verify: force a rotation on a test secret, confirm a new enabled version appears and consumers pick it up, then enable the production schedule.