A platform engineering team is setting up Terraform to manage Google Cloud networking infrastructure across multiple developer environments. To adhere to security best practices, the team wants to centrally store state files with automatic state locking while eliminating the risk of exposed long-lived service account credentials on local engineer workstations. Which TWO configuration steps should the team perform to fulfill these requirements? (Select TWO)
- Define a `backend "gcs"` block inside the Terraform configuration referencing a central Cloud Storage bucket, and run `terraform init`.Cevap
- Configure `impersonate_service_account` in the Terraform Google provider block to allow engineers to authenticate using their individual Google user credentials.Cevap
- CGenerate long-lived JSON service account keys for each developer and set the `credentials` parameter inside the Terraform Google provider configuration.
- DExecute `gsutil terraform sync` prior to every deployment to upload local state files to the designated Cloud Storage bucket.
Cevap
The team should configure a `backend "gcs"` block in the Terraform configuration followed by executing `terraform init`, and configure service account impersonation using `impersonate_service_account` in the Google provider configuration.
Configuring the `backend "gcs"` block with `terraform init` provisions centralized, state-locked storage in Google Cloud Storage. Utilizing `impersonate_service_account` within the Google provider ensures engineers authenticate via short-lived tokens without storing sensitive JSON private key files locally.
Adım Adım Çözüm
Anahtar Kavram
Terraform Remote Backend and Service Account Impersonation in Google Cloud