A platform engineering team is automating continuous deployment pipelines using Cloud Build and Cloud Deploy for microservice applications hosted on Google Kubernetes Engine (GKE). The architecture requires strict compliance with least-privilege IAM controls for pipeline execution and resilient infrastructure state management for pipeline provisioning. Which TWO design practices should the team implement to achieve these requirements?
- Configure Cloud Deploy execution service accounts with least-privilege roles such as Cloud Deploy Job Runner rather than primitive roles.Answer
- Store Infrastructure as Code (IaC) Terraform state files in a Cloud Storage backend with object versioning and state locking enabled.Answer
- CAssign the primitive Owner role to the Cloud Build service account to ensure uninterrupted execution across all GCP resources.
- DStore Terraform state files inside the ephemeral Cloud Build runner workspace without remote locking to maximize deployment velocity.
- EGrant the Service Account Admin role to the deployment pipeline service account to allow workloads to execute under worker identity.
Answer
The correct practices are configuring Cloud Deploy execution service accounts with fine-grained roles such as Cloud Deploy Job Runner, and storing Infrastructure as Code (IaC) Terraform state files in a remote Cloud Storage backend with object versioning and state locking enabled.
Configuring Cloud Deploy execution service accounts with granular predefined roles adheres to least-privilege security principles. Concurrently, utilizing a Cloud Storage remote backend with versioning and object locking for Terraform state management prevents configuration drift, race conditions, and state file corruption during automated release deployments.
Step-by-Step Solution
Key Concept
Automating Continuous Deployment Pipelines and Release Strategies with Least Privilege and Resilient IaC State Management