Google PCA Practice Question: Analyze and optimize technical and business processes
A healthcare company runs a regulated patient-portal application on Google Cloud. Auditors require evidence that infrastructure changes are reviewed before they reach production and that production access is limited. The platform team currently applies Terraform changes directly from engineer laptops using personal credentials. Which two practices should the team adopt to satisfy the auditors while keeping delivery efficient? (Choose two.)
⚠ Common exam trap
The trap here is equating documentation with control, assuming that committing plans after a local apply provides the same assurance as enforcing review and apply through a pipeline.
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
✓
Store Terraform state in a Cloud Storage bucket with versioning and Object Versioning enabled, and grant write access only to the CI/CD service account.
Auditors want a controlled, reviewable path to production and a clear record of who deployed what. Running plan in CI on pull requests with mandatory peer review, then applying from an approved branch with a dedicated service account, creates that path. Backing it with a locked-down, versioned remote state bucket prevents out-of-band changes and preserves history. Together these practices keep delivery automated while producing the evidence and access controls the auditors require.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable Cloud Audit Logs for Terraform-related API calls to reduce log volume and cost.
Why it's wrong here
Audit logs are primary evidence for proving who changed what and when. Disabling Admin Activity logs is not even possible for most services, and suppressing Data Access or other logs removes the traceability auditors rely on. Cost reduction should target log retention and routing rather than eliminating the audit trail.
- ✗
Grant all platform engineers the Project Editor role so they can resolve production incidents quickly without approval delays.
Why it's wrong here
Broad Project Editor access directly contradicts the requirement to limit production access and undermines separation of duties. It also makes it difficult to attribute changes to a specific reviewed pipeline. Faster incident response should come from defined break-glass procedures with logging and approval, not from permanent broad permissions.
- ✓
Store Terraform state in a Cloud Storage bucket with versioning and Object Versioning enabled, and grant write access only to the CI/CD service account.
Why this is correct
Centralizing state in a versioned Cloud Storage bucket with restricted write access prevents engineers from mutating production state locally and creates an auditable history of state changes. This supports the review requirement because all applies flow through a controlled service account, and versioning provides recoverability and evidence for auditors.
- ✓
Use Cloud Build triggers on pull requests to run terraform plan, require peer review, and apply only from an approved branch using a dedicated service account.
Why this is correct
This pattern enforces review before deployment because the plan is generated and inspected in the pull request, and the apply step runs from a pipeline using a dedicated service account rather than human credentials. It gives auditors a verifiable trail linking approvals to deployed changes while keeping the workflow automated and fast.
- ✗
Run terraform apply from each engineer's laptop but require them to commit the plan output to Git afterward.
Why it's wrong here
Applying from laptops with personal credentials leaves no enforceable control point and makes the committed plan an after-the-fact artifact that can be altered. Auditors need assurance that changes were reviewed before reaching production, not documentation produced afterward. This also conflicts with limiting production access to a controlled identity.
Go deeper
Related to this question
Learn chapter
Security Best Practices and Compliance
Key term
Out-of-band
Out-of-band refers to a separate, dedicated network path used for managing and configuring IT devices, distinct from the main data traffic path.
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
One of 807 original PCA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
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.