Secret Manager Study Notes

Secret Manager is a secure, central store for sensitive values such as API keys, passwords, tokens, and certificates. Applications fetch secret values at runtime through the API instead of keeping them in code, configuration files, or environment variables checked into source control.

Key facts

• A secret is a container with metadata and IAM policy, while the actual value lives in immutable secret versions that you add over time.
• Accessing a secret by the alias latest returns the newest enabled version, which lets applications pick up rotated values without code changes.
• Replication is chosen at creation: automatic replication lets Google manage placement, while user-managed replication pins copies to regions you select.
• IAM controls access per secret, so a workload can be granted the Secret Manager Secret Accessor role on one secret without seeing any others.
• Disabling a version makes it inaccessible immediately, while destroying a version permanently deletes its material after the operation completes.
• Rotation can be driven by scheduled notifications to Pub/Sub, prompting a function or workflow to generate and store a fresh credential.
• Secret Manager integrates with Cloud Functions, Cloud Run, and GKE, where secrets can be mounted as files or exposed as environment variables.
• Audit logs record access to secret versions, giving visibility into which identity read which secret and when, without logging the secret value itself.
• Labels and annotations help organize secrets by team, environment, or application so policies and billing reports stay manageable at scale.

What the exam expects you to know

• Recommend Secret Manager whenever a scenario involves storing passwords, API keys, or tokens outside of code and config files.
• Grant roles/secretmanager.secretAccessor only to the specific service account and only on the specific secret the workload needs.
• Use versioning and the latest alias to rotate credentials with minimal application change and a clear rollback path.
• Choose user-managed replication when data residency requirements dictate exactly which regions may store a copy of the secret.
• Combine rotation schedules with Pub/Sub notifications to automate credential renewal for databases and third-party services.
• Recognize that mounting secrets in Cloud Run or GKE is preferable to baking them into container images or plain environment definitions.

Secret Manager vs Cloud KMS: when to use which

Use Secret Manager to store a value your application must retrieve and use directly, like a database password or a third-party API token. Use Cloud KMS to hold encryption keys that encrypt and decrypt data, where the service performs cryptographic operations and key material is never handed back to callers. A common architecture uses both: Secret Manager stores the secret, and a CMEK key from KMS encrypts the storage behind it. On exams, 'application needs this password at runtime' means Secret Manager; 'encrypt data with a managed key' means KMS. See also the Cloud KMS notes.

Useful gcloud commands

gcloud secrets create db-password --replication-policy=automatic
gcloud secrets versions add db-password --data-file=password.txt
gcloud secrets versions access latest --secret=db-password
gcloud secrets add-iam-policy-binding db-password --member=serviceAccount:app@PROJECT_ID.iam.gserviceaccount.com --role=roles/secretmanager.secretAccessor

Common exam traps

• Storing secrets as plain environment variables in deployment files or in a Git repository is not equivalent to using Secret Manager.
• Granting Secret Accessor at the project level exposes every secret in the project; the least-privilege grant is on the individual secret.
• Updating a secret means adding a new version, not editing the old one, because existing versions are immutable by design.
• Secret Manager is not a general configuration store for non-sensitive settings; its purpose and access controls are built for confidential values.

Frequently asked questions

How does secret rotation work in Secret Manager?

You can set a rotation period that publishes a message to a Pub/Sub topic when rotation is due. A subscriber, often a Cloud Function, creates a new credential with the target system, adds it as a new secret version, and updates clients. Old versions stay available briefly for safe rollback.

Can a secret be accessed from another project?

Yes, if the identity in the other project is granted a role such as Secret Accessor on that specific secret. Access is controlled by the secret's own IAM policy, not by project boundaries alone. Cross-project grants should be narrow, because the caller can then read every enabled version unless conditions limit it.

What happens when I disable a secret version?

A disabled version can no longer be accessed by any caller, but its material is retained and it can be re-enabled. A destroyed version is permanently deleted and cannot be recovered. Disabling is the safe first step during an incident, while destroying is the final cleanup after rotation is confirmed.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.