Secret Manager is a Google Cloud service that stores and manages sensitive credentials such as database passwords, API keys, and tokens in a secure, centralized way. The point of it is to keep those values out of source code and configuration files and put them in a dedicated managed store instead. Secret management is a common security topic, so it is the kind of service that can appear on the Professional Cloud Database Engineer exam, usually in scenarios about how an application should obtain a credential it needs.
Secrets stored in Secret Manager are encrypted at rest. This happens automatically, so you do not have to configure encryption separately to get that protection. The service also supports fine-grained access control, which lets administrators define exactly which users and services are allowed to retrieve or modify a given secret. Because secrets live in one managed location rather than being scattered across code, deployment scripts, and environment files, centralizing them this way reduces accidental exposure and helps prevent unauthorized access.
Beyond storage and access control, Secret Manager adds auditing, versioning, and rotation. Auditing lets teams track who accessed or changed a secret, which supports security and compliance work. Versioning keeps older values of a secret available when they are still needed, so updating a secret does not immediately discard what came before it. Rotation helps update credentials over time without someone having to do it by hand each time.
One detail worth holding onto is that Secret Manager is primarily intended for services rather than for human users. The expected pattern is that your cloud workloads retrieve secrets programmatically when they run, not that people log in to read values out of it.
A typical case is an application that needs to authenticate against an external service. Consider a workload running on Cloud Run that calls an external API to fetch data. Rather than hardcoding the API key in the application or storing it in plaintext, you store it as a secret in Secret Manager first. That keeps the key encrypted, centrally managed, and reachable only by authorized services.
In the Cloud Run deployment, you then configure an environment variable, and instead of assigning it a plaintext value, you point it at the secret stored in Secret Manager. Cloud Run does not hold the key itself in that arrangement. It knows where to retrieve the value securely when it is needed. At runtime the application reads the environment variable normally, for example through a call like os.getenv, and uses the key to make its request. The source code never contains the actual secret value.
Access to the secret is governed by a service account that holds the Secret Accessor role. Only workloads granted that permission can retrieve the secret, which is what keeps unauthorized callers from reading it. For the exam, the connection between retrieving a secret and the Secret Accessor role on a service account is a useful one to keep straight, because questions about who can read a secret tend to come down to that permission.
Handling credentials this way carries several benefits, and they line up with security principles the Professional Cloud Database Engineer exam tends to reward. Secrets are never hardcoded or left sitting in plaintext as environment variable values. They are resolved dynamically at runtime, so the value is fetched only when it is actually used, which lowers the chance of accidental exposure. The setup follows the principle of least privilege, since only the resources that genuinely need a secret are given access to it. And because every retrieval is logged, secret access stays traceable and auditable.
For a database engineer, the most direct application is the database credential itself. A password an application uses to connect to a database fits this model exactly. Storing it in Secret Manager and granting the application's service account the Secret Accessor role keeps the password out of code and configuration while still letting the workload connect when it runs.
Our Professional Cloud Database Engineer course covers Secret Manager alongside service accounts and IAM roles for database access, with practice questions that drill these distinctions.
