Explanation:
The issue arises because Terraform's state file (terraform.tfstate) is not being managed correctly across pipeline executions. This file tracks the current state of your infrastructure. If it isn't stored in a shared, consistent location (e.g., a remote backend), each pipeline run uses a new or outdated state file, leading to duplicate infrastructure stacks instead of updating existing resources. Google-recommended practices emphasize using a centralized, reliable backend for Terraform state. Option B addresses this by ensuring the state file is stored in Cloud Storage using Terraform's gcs backend. This enables state locking, consistency, and prevents duplication by allowing Terraform to reference the same state across all runs. Option A is inefficient and reactive, C risks state file corruption or exposure in source control, and D causes downtime by destroying infrastructure unnecessarily.
Ultimate access to all questions.
No comments yet.
You are managing infrastructure as code with Terraform in a CI/CD pipeline and observe that multiple copies of the entire infrastructure stack are being created in your Google Cloud project, with a new copy generated for each change. To optimize cloud costs by maintaining only a single instance of the infrastructure stack at any time while adhering to Google-recommended practices, what should you do?
A
Create a new pipeline to delete old infrastructure stacks when they are no longer needed.
B
Confirm that the pipeline is storing and retrieving the terraform.tfstate file from Cloud Storage with the Terraform gcs backend.
C
Verify that the pipeline is storing and retrieving the terraform.tfstate file from a source control.
D
Update the pipeline to remove any existing infrastructure before you apply the latest configuration.