Google PCA Manage and provision cloud infrastructure Practice Question
A user wants to store a database password that will be used by a Compute Engine instance. What is the most secure and manageable approach?
⚠ Common exam trap
Google Cloud often tests the misconception that instance metadata is a secure place for secrets because it is 'internal' to the project, but in reality, metadata is accessible to any process on the instance and is logged, making it unsuitable for sensitive data.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use Secret Manager and grant the instance's service account access to the secret
Secret Manager is the most secure and manageable approach because it provides encrypted storage, automatic rotation, and fine-grained access control via IAM. By granting the Compute Engine instance's service account access to the secret, the password is never exposed in plaintext metadata, logs, or disk files, and access can be audited and revoked independently of the instance lifecycle.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use Secret Manager and grant the instance's service account access to the secret
Why this is correct
Secret Manager stores the credential encrypted and versioned, and IAM on the Compute Engine service account grants retrieval at runtime, so the password never sits in instance metadata, startup scripts or source code. This satisfies the secure and manageable requirement without manual rotation.
- ✗
Set the password as an environment variable in instance metadata
Why it's wrong here
Instance metadata is readable by any process on the VM via the metadata server and appears in the console, so the password is exposed without audit logging or rotation. It is tempting because metadata is easy to set at deploy time, but that mechanism suits configuration values and SSH keys, not database credentials.
- ✗
Store the password in Cloud Storage bucket metadata
Why it's wrong here
Bucket metadata is readable by anyone holding storage.buckets.get on the bucket, so the password leaks without Secret Manager's audit logging, rotation or IAM-scoped access. It is tempting because metadata can hold arbitrary key-value pairs, but that suits tagging and lifecycle configuration, not credential storage.
- ✗
Store the password in a file on the instance's boot disk
Why it's wrong here
A file on the boot disk persists in every snapshot and image derived from that instance, and any process on the VM can read it, so the secret cannot be rotated or audited centrally. It is tempting for simple startup scripts, but Secret Manager exists precisely to hold credentials outside instance storage.
Go deeper
Related to this question
Learn chapter
IAM Policies, Service Accounts, and Auditing
Key term
Secret Manager
A Secret Manager is a centralized tool that securely stores, manages, and controls access to sensitive information like passwords, API keys, and certificates, often automating their rotation and injection into applications.
Key term
Service account
A service account is a special type of account used by an application or a virtual machine, rather than a human user, to authenticate and interact with cloud services and APIs securely.
About these practice questions
Courseiva writes every PCA question from scratch — 807 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCA practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCA exam.