HCTA0-003 Practice Exam — Terraform Associate (003)

Option Analysis: A. Option A is incorrect because `terraform refresh` does not support the `-upgrade` flag, and this command is used to sync Terraform state with remote resources, not update provider plugins. B. Option B is incorrect because `terraform apply` does not support the `-upgrade` flag for updating plugins, and this command is used to apply planned changes to infrastructure, not update provider versions. C. Option C is incorrect because `terraform providers` is a command to inspect configured provider requirements and versions, it does not have an `-upgrade` operation to update plugins to the latest allowed versions. D. Option D is correct because the `-upgrade` flag for `terraform init` will upgrade all configured provider plugins to the latest version that is compatible with the version constraints in the Terraform configuration, matching the requirement to keep plugins up to date. Key Concept: The `terraform init -upgrade` command is used to initialize a working directory and upgrade provider plugins to the latest compatible version that adheres to configured version constraints. References: Terraform CLI Documentation: terraform init, https://developer.hashicorp.com/terraform/cli/commands/init Terraform Plugin Upgrade Documentation

Option Analysis: A. This option is incorrect because deleting the state file after every run breaks Terraform's state tracking functionality, which is required to manage existing infrastructure and will lead to corrupted or duplicate resources. B. This option is correct because using an encrypted backend for Terraform state encrypts sensitive state data at rest, preventing plaintext exposure of secrets stored in the state file. C. This option is incorrect because even if secrets are stored in secrets.tfvars, Terraform will still output sensitive values to the plaintext state file by default unless state encryption is configured. D. This option is incorrect because manually editing and scrubbing the state file corrupts Terraform's state tracking of managed resources, and any future Terraform operations will reintroduce sensitive data to the state. Key Concept: Terraform state can contain sensitive data like credentials, so it must be protected by using an encrypted backend to prevent plaintext exposure. References: Terraform State Security, Backend Configuration, https://developer.hashicorp.com/terraform/language/settings/backends/configuration

Option Analysis: A. Option A is incorrect because resources created with for_each are not set up as a list that can be referenced with a general splat expression, since for_each creates instances keyed by a map or set of strings, not an ordered list. B. Option B is correct because you cannot reference a for_each-created resource using a standard splat expression; you must use for expressions to collect values instead. Key Concept: Resources created with the for_each meta-argument are addressed by their map or set keys, not via an ordered list index, so they do not support reference via splat expressions. References: Terraform Documentation: The for_each Meta-Argument, https://developer.hashicorp.com/terraform/language/meta-arguments/for_each Terraform Documentation: Splat Expressions, https://developer.hashicorp.com/terraform/language/expressions/splat

Option Analysis: A. Option A is incorrect because Terraform uses a single provider version for all resources from the same provider in a configuration, and does not use different versions for existing and new resources. B. Option B is correct because when a provider lock file exists and the version constraint has not changed, Terraform will use the provider version that is already recorded in the .terraform.lock.hcl dependency lock file. C. Option C is incorrect because the Terraform state file stores resource state data, not provider version selection information used for this scenario. D. Option D is incorrect because Terraform will only select a new newer provider version if the version constraint is changed or the lock file is updated, which did not happen in this scenario. Key Concept: The Terraform dependency lock file (.terraform.lock.hcl) pins provider versions to ensure consistent provider version selection across all runs and environments when version constraints do not change. References: Dependency Lock File, https://developer.hashicorp.com/terraform/language/files/dependency-lock Provider Version Constraints, https://developer.hashicorp.com/terraform/language/providers/requirements#version-constraints

Option Analysis: A. Option A is incorrect because not all standard Terraform backend types support all three features: state storage, locking, and remote operations. B. Option B is correct because some standard backends, such as the local backend, do not support remote operations, and others like the etcd v3 backend do not support state locking, so the universal claim in the question is false. Key Concept: Different standard Terraform backend types have different feature support for state storage, state locking, and remote operations, not all backends support all three core features. References: Backend Types | Terraform Documentation, https://developer.hashicorp.com/terraform/language/settings/backends/configuration#backend-types