Google Cloud Professional Cloud Architect — Question 234

You are designing a central, automated infrastructure deployment process for your organization using Terraform and Cloud Build. The security team prohibits the use of long-lived, static service account keys in any CI/CD pipeline. Additionally, while developers can propose infrastructure changes for peer review, they must not have permissions to directly apply changes in the production project. You need to design a secure and automated workflow for applying Terraform changes that meets the security team's requirements and ensures proper governance. What should you do?

Answer options

• A. Configure the Cloud Build pipeline to use service account impersonation. Set up a trigger that automatically runs terraform apply when a pull request is merged.
• B. Use service account impersonation in Cloud Build. Configure the pipeline to run terraform plan on pull requests, and require manual approval before running terraform apply.
• C. Configure the pipeline to only run terraform plan. After a pull request is approved, have an authorized developer run terraform apply from a secured workstation.
• D. Create a privileged service account and store its JSON key in Secret Manager. Configure the Cloud Build pipeline to fetch this key during execution to authenticate Terraform.

Correct answer: B

Explanation

Option B is correct because it adheres to the security team's prohibition against long-lived service account keys by using impersonation and requires manual approval, ensuring governance. Option A fails to provide a manual approval step, allowing for potential unauthorized changes. Option C lacks automation since it relies on a developer to apply changes manually, which can lead to delays and inconsistencies. Option D violates security protocols by using a static service account key stored in Secret Manager.