Examkin

Question

Difficulty: HardImplementing Infrastructure as Code using Terraform and Deployment Manager

A principal cloud architect is designing an enterprise infrastructure automation strategy using HashiCorp Terraform for a logistics enterprise on Google Cloud. Multiple automated runner instances executing within Cloud Build must perform `terraform apply` operations concurrently across distinct operational pipelines targeting shared staging environments. The architectural mandate requires protecting infrastructure state against concurrency race conditions, enabling immediate state recovery from accidental corruptions, and adhering to strict least-privilege security without storing long-lived service account keys in repositories. Which implementation strategy meets all of these requirements?

  1. Configure a Google Cloud Storage remote backend with Object Versioning enabled, rely on native GCS object locking for state concurrency control, and configure Cloud Build worker service accounts to impersonate dedicated deployment service accounts via short-lived IAM tokens.Answer
  2. B
    Store state files in a standard Google Cloud Storage bucket, grant the Cloud Build runner service account the primitive Owner role (roles/owner) at the organization level, and disable state locking parameters in the backend block to avoid build pipeline timeout exceptions during concurrent executions.
  3. C
    Store Terraform state locally within the ephemeral workspace directory of Cloud Build runners, upload compressed state archives to Google Cloud Storage at step completion, and grant build runners the Service Account Admin role (roles/iam.serviceAccountAdmin) to provision target infrastructure.
  4. D
    Configure a Google Cloud Storage remote backend with Object Versioning disabled, download long-lived service account JSON keys from Cloud Secret Manager into build steps, and grant the Service Account User role (roles/iam.serviceAccountUser) to the Cloud Build trigger creator.

Answer

The correct architecture uses a Google Cloud Storage backend with Object Versioning enabled for automatic state history, relies on native GCS state locking for concurrency safety, and uses short-lived Service Account Impersonation for least-privilege pipeline authentication.
The solution combining a Google Cloud Storage remote backend with Object Versioning enabled, native state locking, and service account impersonation meets all architectural requirements. GCS prevents simultaneous state modifications through atomic object locks, object versioning maintains a historical ledger of state generations for rapid rollback, and service account impersonation provides secure, short-lived credential access without storing static keys.

Step-by-Step Solution

1
Evaluate state storage security and concurrency controls
Google Cloud Storage natively supports state locking using strong consistency and object generation checks. Enabling Object Versioning ensures previous state generations remain recoverable in case of corruption or bad applies.
Remote state management in collaborative enterprise environments requires lock acquisition during writes and versioning for disaster recovery.
2
Determine identity and authentication requirements for CI/CD runners
Cloud Build runners should authenticate to target project resources by impersonating designated deployment service accounts using short-lived IAM tokens rather than static JSON service account keys.
Service account impersonation adheres to security best practices by eliminating static credentials in code repositories and limiting access scopes via fine-grained IAM roles.

Key Concept

Enterprise Infrastructure as Code state management, concurrency control, and least-privilege pipeline authentication on Google Cloud
Estimated Time:2m 30s
Rate this question

Topics

Implementing Infrastructure as Code using Terraform and Deployment Manager

More questions from this topic