Examkin

Question

Difficulty: HardImplementing Infrastructure as Code using Terraform and Deployment Manager

An enterprise organization manages multiple Google Cloud projects across production and non-production environments using Terraform within a centralized CI/CD pipeline. Engineers report intermittent deployment failures caused by concurrent pipeline executions modifying state simultaneously, and security audits identified Terraform state files containing sensitive data stored locally on transient build runners. You need to redesign the Infrastructure as Code (IaC) architecture to align with Google Cloud security and operational best practices. Which strategy should you recommend?

  1. Configure a dedicated Cloud Storage bucket per environment with Object Versioning enabled as the Terraform remote backend, enforce state locking via Cloud Storage native locking mechanisms, and restrict bucket access using fine-grained IAM roles granted to the CI/CD execution service account.Answer
  2. B
    Store state files in a local directory on the CI/CD runner host and execute a post-deployment script that uploads state snapshots to a Cloud Storage bucket without object versioning.
  3. C
    Configure a single shared Cloud Storage backend for all environments, disable Object Versioning to control storage costs, and grant the primitive Owner role to all deployment pipelines to ensure full resource management rights.
  4. D
    Store state files in a central Git repository and grant the Service Account Admin role (roles/iam.serviceAccountAdmin) to the deployment pipeline service account to dynamically generate service account keys during execution.

Answer

Configure a dedicated Cloud Storage bucket per environment with Object Versioning enabled as the Terraform remote backend, enforce state locking via Cloud Storage native locking mechanisms, and restrict bucket access using fine-grained IAM roles granted to the CI/CD execution service account.
Configuring a dedicated Cloud Storage bucket with Object Versioning enabled as the Terraform remote backend guarantees state persistence, prevents state corruption from concurrent runs via native GCS state locking, allows point-in-time state recovery through object versions, and secures state contents by applying fine-grained IAM roles to the automated pipeline service account.

Step-by-Step Solution

1
Identify current IaC state management and pipeline vulnerabilities
Local storage on build runners exposes cleartext state files to loss/exposure and causes state corruption due to lack of concurrency locking.
Terraform state contains sensitive metadata and resource mappings that require remote persistence, encryption at rest, state locking, and point-in-time recovery capabilities.
2
Evaluate GCP remote backend features for Terraform
Google Cloud Storage (GCS) provides built-in state locking natively, object versioning for rollback capabilities, and integration with IAM for least-privilege access control.
A GCS remote backend prevents simultaneous pipeline runs from corrupting state, while Object Versioning safeguards against accidental deletion or state corruption.
3
Implement environmental separation and identity controls
Isolate environments using separate GCS buckets for each stage (e.g., development, production) and assign fine-grained predefined storage roles to dedicated pipeline service accounts.
Environment separation limits the blast radius of misconfigurations, and dedicated service accounts enforce security boundaries without over-granting primitive roles.

Key Concept

Terraform Remote State Management and Security Best Practices in GCP
Estimated Time:2m 0s
Rate this question

Topics

Implementing Infrastructure as Code using Terraform and Deployment Manager

More questions from this topic