This chapter covers Google Cloud Secret Manager, a secure and convenient service for storing API keys, passwords, certificates, and other sensitive data. For the ACE exam, Secret Manager is a core topic within Security & Compliance (Domain 5), typically appearing in 2-3 questions. You will need to understand how to create, access, rotate, and manage secrets, as well as integrate them with other GCP services like Compute Engine and Cloud Functions.
Jump to a section
Secret Manager works like a hotel's safe deposit box system. Each guest (application or user) gets a secure box (secret version) in a locked vault (Secret Manager). The hotel issues a key (IAM permission) that allows a specific guest to open their box. When a guest wants to store a secret, they place it in the box and lock it; the hotel never sees the contents. To retrieve a secret later, the guest presents their key, and the hotel unlocks the box without ever copying the contents elsewhere. If a guest loses their key, the hotel administrator can revoke the key and issue a new one, but the box remains sealed. The hotel also rotates boxes periodically: when a guest checks out, a new box is assigned with a new key, and the old box is destroyed. This ensures that even if an old key is compromised, it cannot open the new box. The hotel keeps an audit log of every box access — who opened it, when, and for how long. In this analogy, the hotel never reads the contents of the box; it only manages access. This mirrors Secret Manager's design: Google never has access to the secret payload, only the metadata and access logs.
What is Secret Manager and Why It Exists
Secret Manager is a fully managed Google Cloud service that stores sensitive data such as API keys, passwords, certificates, and database credentials. Instead of hardcoding secrets in application code or configuration files, you store them in Secret Manager and retrieve them at runtime. This eliminates the risk of secrets being exposed in source code, logs, or build artifacts. Secret Manager provides centralized access control (via IAM), automatic versioning, audit logging, and built-in rotation policies.
How Secret Manager Works Internally
Secret Manager stores secrets as immutable versions. Each secret has a name (e.g., my-db-password) and can have multiple versions (e.g., version 1, version 2). When you create a secret, you immediately create its first version with the payload. Subsequent updates create new versions; you can disable or destroy old versions. The payload is encrypted at rest using Google-managed or CMEK keys, and in transit using TLS. Access is controlled by IAM permissions: secretmanager.secrets.get and secretmanager.versions.access allow reading the payload. Access is logged in Cloud Audit Logs.
Key Components, Values, Defaults, and Timers
Secret: A logical container for versions. Has a name and labels.
Version: An immutable snapshot of the secret payload. Maximum 10,000 versions per secret.
Payload: The actual secret data, up to 64 KB (65536 bytes) per version.
IAM Roles: roles/secretmanager.secretAccessor (read), roles/secretmanager.admin (full control).
Replication: By default, secrets are replicated across multiple zones within the region. For higher availability, you can use user-managed replication across regions.
Rotation: You can define a rotation period (e.g., 30 days) and a rotation time. Secret Manager does not automatically rotate; it sends a Pub/Sub notification to a topic you specify, and you must implement the rotation logic.
Expiration: Secrets can have a time-to-live (TTL) or be scheduled for deletion. By default, secrets are permanent.
Pricing: $0.06 per secret per month + $0.03 per 10,000 access operations.
Configuration and Verification Commands
To create a secret using gcloud:
gcloud secrets create my-secret --replication-policy="automatic"To add a version:
echo -n "my-password" | gcloud secrets versions add my-secret --data-file=-To access a version:
gcloud secrets versions access latest --secret=my-secretTo list secrets:
gcloud secrets listTo view IAM policy:
gcloud secrets get-iam-policy my-secretIntegration with Other Services
Compute Engine: You can grant a service account attached to a VM the secretAccessor role, and the application can retrieve secrets via the API or the Secret Manager client library.
Cloud Functions: The function's runtime service account can access secrets. Use the Secret Manager API in the function code.
Cloud Run: Similar to Cloud Functions; you can mount secrets as environment variables or volumes.
GKE: Use Secret Manager as a CSI driver to mount secrets as volumes in pods.
Cloud Build: You can access secrets during builds by granting the Cloud Build service account access.
Best Practices
Use separate secrets for different environments (dev, prod).
Rotate secrets regularly using automated workflows triggered by Pub/Sub.
Use IAM conditions to restrict access based on resource tags or IP addresses.
Enable audit logs to monitor access.
Never store secrets in environment variables in plain text; always retrieve from Secret Manager at runtime.
Create a Secret
Use the `gcloud secrets create` command or the Console to define a secret name and replication policy. The replication policy can be `automatic` (Google-managed, multi-region) or `user-managed` (specify regions). You can also add labels for organization. The secret is created with no versions initially. IAM policies can be set at this stage or later.
Add a Secret Version
Use `gcloud secrets versions add` or the API to add a version with the payload. The payload is base64-encoded if using the API. Each version gets an integer version number (1, 2, ...). You can specify `--data-file` to read from a file. The version is enabled by default. If you add a new version, it becomes the 'latest' version.
Access a Secret Version
Use `gcloud secrets versions access` with the version number or `latest`. The response contains the payload. IAM permission `secretmanager.versions.access` is required. The access is logged. If the version is disabled or destroyed, access fails with a 404 error.
Disable or Destroy a Version
To disable a version: `gcloud secrets versions disable <version> --secret=my-secret`. Disabling prevents access but keeps the data. To destroy: `gcloud secrets versions destroy <version> --secret=my-secret`. Destruction is permanent and irreversible. You cannot destroy the only enabled version if the secret has no other enabled versions (unless forced).
Set Up Rotation
Define a rotation period and optional rotation time: `gcloud secrets add-rotation-schedule my-secret --next-rotation-time="2025-01-01T00:00:00Z" --rotation-period="2592000s"` (30 days). Secret Manager sends a Pub/Sub message to a configured topic when rotation is due. You must have a subscriber that creates a new version and disables the old one. No automatic rotation is performed.
Enterprise Scenario 1: Database Credential Management
A large e-commerce company stores MySQL database credentials for hundreds of microservices. Previously, passwords were hardcoded in Kubernetes secrets, leading to security audits flagging plaintext exposure. They migrated to Secret Manager by creating one secret per database user (e.g., mysql-app1-user). Each microservice's service account receives the secretmanager.secretAccessor role for its specific secret. During deployment, the application retrieves the password from Secret Manager at startup and caches it in memory for the session. Rotation is configured every 90 days with a Cloud Function that generates a new password, updates the database, and adds a new version. The old version is disabled after a 24-hour grace period. This setup eliminates credential leaks from config maps and provides a complete audit trail.
Enterprise Scenario 2: API Key Distribution for External Partners
A SaaS provider issues API keys to hundreds of partners. They used to email keys, which was insecure and hard to revoke. They now use Secret Manager with IAM conditions: each partner's service account can only access its own secret. When a new partner is onboarded, a secret is created with a unique API key. The partner retrieves the key via a secure gcloud command. If a partner is compromised, the admin disables the secret version and creates a new one, then notifies the partner. The old version is destroyed after 30 days. This solution scales to thousands of secrets without manual overhead.
Common Pitfalls
Overly permissive IAM: Assigning secretmanager.admin to applications instead of secretAccessor allows them to delete secrets. Always use least privilege.
Not enabling audit logs: Without audit logs, you cannot detect unauthorized access. Enable Data Access audit logs for Secret Manager.
Storing secrets in environment variables in CI/CD: During Cloud Build, secrets are injected as environment variables; they may be exposed in logs. Use Secret Manager's availableSecrets configuration to mount secrets as files instead.
Ignoring version management: Accumulating thousands of old versions increases cost. Implement a cleanup policy to destroy versions older than a certain date.
What the ACE Exam Tests
Objective 5.1: "Implement and manage secrets using Secret Manager." Exam questions focus on: (1) Creating and accessing secrets via gcloud and API, (2) IAM permissions required for read/write, (3) Replication policies (automatic vs. user-managed), (4) Versioning behavior (immutable, disable, destroy), (5) Integration with Compute Engine, Cloud Functions, and Cloud Run, (6) Rotation setup (Pub/Sub notification, not automatic), (7) Encryption (default Google-managed vs. CMEK).
Common Wrong Answers
"Secret Manager automatically rotates secrets." Wrong. Secret Manager only sends a notification; you must implement the rotation logic.
"You can modify an existing secret version." Wrong. Versions are immutable; you must create a new version.
"Secrets are stored in plaintext in Cloud Storage." Wrong. Secrets are encrypted at rest and in transit; they are not stored in Cloud Storage.
"You can access a destroyed version." Wrong. Once destroyed, the version is permanently unavailable.
"Use `--replication-policy=none` to avoid replication." Wrong. The only options are automatic and user-managed; you cannot disable replication.
Exam-Specific Numbers and Terms
Maximum payload size: 64 KB (65536 bytes).
Maximum versions per secret: 10,000.
Rotation period must be in seconds (e.g., 2592000 for 30 days).
IAM role for read-only: roles/secretmanager.secretAccessor.
Command to access latest version: gcloud secrets versions access latest --secret=NAME.
To add a version from a file: --data-file=/path/to/file.
Replication policies: automatic (default) or user-managed with --locations.
Edge Cases
If you destroy the only enabled version of a secret, the secret becomes inaccessible but still exists. You can add a new version.
You cannot delete a secret that has enabled versions; you must first disable or destroy all versions.
When using user-managed replication, you must specify at least one region. The secret is replicated synchronously within each region.
IAM conditions can restrict access based on resource tags, but not on secret version.
How to Eliminate Wrong Answers
If the question mentions automatic rotation, it's wrong unless it says "Pub/Sub notification for rotation."
If the question suggests modifying a version, it's wrong.
If the question says secrets are stored in Cloud Storage, it's wrong.
Look for keywords: "immutable versions," "Pub/Sub," "64 KB," "secretAccessor."
Secret Manager stores secrets as immutable versions; each version can be up to 64 KB.
IAM role `roles/secretmanager.secretAccessor` grants read access to secret payloads.
Secrets are encrypted at rest and in transit by default; CMEK is optional.
Rotation is not automatic; Secret Manager sends a Pub/Sub notification when rotation is due.
Use `gcloud secrets versions access latest --secret=NAME` to retrieve the latest version.
Destroying a version is irreversible; disabling a version can be undone.
Replication policy can be `automatic` (multi-region) or `user-managed` (specified regions).
These come up on the exam all the time. Here's how to tell them apart.
Secret Manager
Stores secret payloads (passwords, API keys) directly.
Provides versioning and access control for secrets.
Maximum payload size 64 KB.
Integrates with GCP services via IAM and client libraries.
Priced per secret and per access operation.
Cloud KMS
Manages encryption keys used to encrypt/decrypt data elsewhere.
Does not store application secrets; only keys.
No payload size limit (used for encryption of any size).
Provides envelope encryption and HSM-backed keys.
Priced per key version and per cryptographic operation.
Mistake
Secret Manager automatically rotates secrets.
Correct
Secret Manager only sends a Pub/Sub notification when rotation is due. You must implement the actual rotation logic (e.g., with Cloud Functions) to create a new version and disable the old one.
Mistake
You can update an existing secret version's payload.
Correct
Secret versions are immutable. To change the payload, you must create a new version. The old version can be disabled or destroyed.
Mistake
Secrets are stored in plaintext in Cloud Storage buckets.
Correct
Secrets are encrypted at rest using AES-256 (Google-managed or CMEK) and in transit via TLS. They are stored in Secret Manager's internal infrastructure, not in Cloud Storage.
Mistake
You can access a destroyed secret version.
Correct
Destroying a version is permanent and irreversible. The payload is deleted and cannot be recovered. Access to a destroyed version returns a 404 error.
Mistake
Secret Manager is only for text-based secrets.
Correct
Secret Manager can store any binary data up to 64 KB, including certificates, SSH keys, and binary tokens. The payload must be base64-encoded when using the API.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, attach a service account to the VM. Grant that service account the `roles/secretmanager.secretAccessor` role on the secret. Then, in your application, use the Secret Manager client library (e.g., for Python: `google-cloud-secret-manager`) to call `access_secret_version`. Alternatively, you can use the gcloud command `gcloud secrets versions access latest --secret=my-secret` if gcloud is installed.
Yes. Assign the Cloud Functions runtime service account the `secretAccessor` role. In your function code, use the Secret Manager client library to retrieve the secret at runtime. For example, in Node.js, use `@google-cloud/secret-manager` and call `accessSecretVersion`. This avoids hardcoding secrets in environment variables.
You cannot delete a secret that has enabled versions. You must first disable or destroy all versions. Use `gcloud secrets versions destroy` for each version, then `gcloud secrets delete` to delete the secret. Alternatively, you can schedule deletion by setting a TTL.
By default, secrets are replicated automatically across multiple zones within the chosen region (if `automatic` policy). For cross-region replication, use `user-managed` policy and specify multiple regions. Secrets are synchronously replicated within each region and asynchronously across regions. This provides high availability and durability.
Yes. You can specify a Cloud KMS key when creating a secret using the `--kms-key-name` flag. The secret payload is encrypted with that key. Note that the CMEK key must be in the same region as the secret. If you use automatic replication, the key must be a multi-regional key (e.g., `global`).
Disabling a version makes it inaccessible but retains the payload. You can re-enable it later. Destroying a version permanently deletes the payload and cannot be undone. Both require the `secretmanager.versions.disable` and `secretmanager.versions.destroy` permissions respectively.
You cannot set up automatic rotation directly. Use `gcloud secrets add-rotation-schedule` to define a rotation period and a Pub/Sub topic. When rotation is due, Secret Manager publishes a message to the topic. You must create a Cloud Function or other subscriber that listens for the message, generates a new secret value, adds a new version, and optionally disables the old version.
You've just covered Secret Manager for Credentials — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?