Google ACE Practice Question: A Cloud Run service needs to access a database…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  As a plain-text environment variable in the Cloud Run service configuration

  Why it's wrong here

  Setting a plain-text environment variable in the Cloud Run service configuration makes the value readily visible in the Cloud Console and through gcloud run services describe, and it is stored unencrypted in the service specification. Anyone with viewer access to Cloud Run can read the secret, and the value is shared with every instance of the service, with no per-access auditing or rotation capability. This creates broad exposure without any of the governance controls of a dedicated secrets manager.

• ✗

  In a Cloud Storage bucket accessible to the service account

  Why it's wrong here

  Storing a secret in a Cloud Storage bucket exposes it to any principal who has object read permission on that bucket, and Cloud Storage lacks secrets-specific features such as automatic versioning for rotation, expiration, or dedicated IAM roles scoped to individual secret values. While encryption can be enabled at the bucket or object level, access decisions and audit logs are based on objects rather than the semantic identity of a secret, making it difficult to track who used the password versus who merely viewed the object. This approach treats secrets as generic blobs, missing the fine-grained controls and lifecycle management of Secret Manager.

• ✓

  In Secret Manager, referenced as a mounted secret or accessed via the API at runtime

  Why this is correct

  Secret Manager stores secret values encrypted at rest and in transit, and Cloud Run can inject them either as mounted volume files or environment variables without ever displaying the actual value in the service definition or console. Runtime API access via the Secret Accessor role also lets your code fetch secrets on demand, while IAM policies and Cloud Audit Logs provide fine-grained control and full access trails. Versioning supports seamless rotation, making this the only option that combines encryption, least-privilege access, and operational transparency.

• ✗

  Baked into the container image at build time

  Why it's wrong here

  Embedding a secret in a container image during build bakes it into the image layers, so it persists in Container Registry or Artifact Registry and can be extracted by anyone with pull access using docker history or layer inspection. Because the image is built once, rotating the secret requires rebuilding and redeploying every service, and the secret remains in the image registry indefinitely even after deletion. This violates best practices for secret hygiene and unnecessarily expands the attack surface.

Go deeper

Related to this question