A team is deploying a microservice on Cloud Run that requires environment variables with sensitive information, such as database passwords. What is the recommended way to provide these secrets?
Secret Manager securely stores secrets and integrates with Cloud Run.
Why this answer
Secret Manager is Google Cloud's dedicated service for securely storing and managing sensitive data like API keys and database passwords. Cloud Run natively integrates with Secret Manager, allowing you to reference secret versions by name in your service configuration without exposing the secret value in plaintext. This approach ensures secrets are encrypted at rest and in transit, and access can be tightly controlled via IAM permissions.
Exam trap
The trap here is that candidates may confuse Cloud Storage with a volume mount capability in Cloud Run, or mistakenly think embedding secrets in the container image is acceptable because it 'works' in local development, ignoring the security and compliance implications in a production environment.
How to eliminate wrong answers
Option A is wrong because injecting secrets directly in the Cloud Run YAML configuration would expose them in plaintext in the deployment manifest and revision history, violating security best practices. Option B is wrong because embedding secrets in the container image as environment variables makes them accessible to anyone with image pull access and persists them in the image layers, which is insecure and difficult to rotate. Option C is wrong because Cloud Storage buckets do not natively support mounting as a volume in Cloud Run; Cloud Run supports mounting volumes from Filestore or Secret Manager, but not Cloud Storage, and storing secrets in a bucket without encryption key management or IAM fine-grained access control is not a recommended pattern for secrets.