TF-004 Implement and maintain state Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Disable access control on the bucket temporarily

  Why it's wrong here

  Disabling access control on the GCS bucket, such as making it publicly accessible or removing all IAM policies, is a severe security vulnerability. The Terraform state file often contains sensitive information, including resource IDs, configurations, and potentially secrets, which would then be exposed to unauthorized entities. This approach does not solve the underlying problem of a specific service account lacking the necessary permissions; instead, it creates a much larger security incident by compromising the integrity and confidentiality of the infrastructure state.

• ✗

  Run `terraform init -reconfigure` to regenerate the backend configuration

  Why it's wrong here

  Running `terraform init -reconfigure` is used to re-initialize the backend configuration, re-download providers, and update modules, but it does not modify or grant any Identity and Access Management (IAM) permissions on cloud resources. This command operates on the local Terraform working directory and interacts with the configured backend to establish connectivity. It cannot alter the server-side access policies that govern which service accounts or users can interact with the GCS bucket where the state file is stored. Therefore, it will not resolve a permissions error.

• ✓

  Grant the `Storage Object Viewer` role to the service account on the GCS bucket

  Why this is correct

  Granting the `Storage Object Viewer` role to the service account directly addresses the issue of insufficient permissions for reading the Terraform state file stored in Google Cloud Storage. This specific IAM role provides the necessary `storage.objects.get` permission, allowing the service account to retrieve the state file's contents. Terraform requires read access to the state file to understand the current infrastructure's deployed configuration before planning any changes, ensuring consistency and preventing unintended modifications. This is a secure and precise way to resolve the access problem.

• ✗

  Change the backend to local state and commit the state to the repository

  Why it's wrong here

  Changing the backend to local state and committing it to a repository fundamentally undermines the benefits of using remote state for collaborative Terraform development. Local state files are prone to being out of sync among team members, leading to inconsistent infrastructure views and potential state corruption. Furthermore, committing the state file, which can contain sensitive data, directly into version control is a significant security risk and makes version control cumbersome due to large, frequently changing binary files and merge conflicts. It defeats the purpose of a shared, consistent, and secure state.

Go deeper

Related to this question