HashiCorp 004: Maintain infrastructure with Terraform Practice Questions

Option D is correct. terraform state list prints just the resource addresses in state (optionally filtered by a pattern, such as a module path or resource type), giving a quick inventory without the detail of individual attributes. Option A is incorrect — terraform state show requires one specific resource address and prints its full attribute detail, not a listing of all addresses. Option C is incorrect — terraform output prints declared output values, unrelated to the inventory of managed resources. Option B is incorrect — terraform providers reports which provider plugins the configuration requires, not which resources are in state.

Option C is correct. terraform state mv with -state-out moves a state entry directly from one state file to another (or into a different module), preserving the tracked resource's identity without any provider API calls — the real IAM role is untouched throughout. Option D would technically work end-to-end but is the less direct, riskier path when a single-command move is available — removing from state and re-importing means re-typing the exact resource ID and briefly leaves the role completely untracked by Terraform. Option B is incorrect and destructive — tainting marks a resource for destroy-and-recreate on the next apply, which is the opposite of preserving the existing role. Option A is incorrect — simply moving the resource block between configs without a corresponding state operation causes the old module to plan a destroy and the new module to plan a create, losing the resource's existing identity in the process.

Option B is correct. terraform show also accepts a saved plan file as an argument and renders its proposed changes in human-readable form (it can additionally emit JSON with -json for tooling). Option D is incorrect — terraform state show takes a resource address from the current state, not a plan file, and would error on a plan file path. Option A is incorrect — -detailed-exitcode is a flag for terraform plan that changes its exit code semantics; it is not how you render a saved plan's contents, and this isn't valid plan syntax. Option C is incorrect — terraform validate checks configuration for syntax errors; it does not accept or display a plan file.

Option C is correct. TRACE is the most detailed logging level Terraform supports, capturing fine-grained internal detail including provider plugin communication — the right choice when diagnosing a suspected bug deep in a provider's behavior. Option B is incorrect — ERROR is the least verbose level, showing only failures. Option A is incorrect — WARN shows errors plus warnings, still far less detail than TRACE. Option D is incorrect — INFO is more verbose than WARN/ERROR but considerably less detailed than TRACE, and would likely omit the low-level plugin communication needed to diagnose a provider issue.

Option B is correct. terraform state show <address> takes the exact resource address (module path, resource type, name, and any index/key) and prints just that resource's attributes as recorded in state — quoting is needed here because the address contains brackets and a string key. Option E is incorrect — terraform state list has no -detailed flag, and it only ever prints addresses, not attributes. Option D is technically possible but is not the best answer — it works but is far less direct than targeting the resource by address, which is exactly what state show is for. Option A is a real but clumsy workaround — terraform state pull dumps raw state JSON to stdout, which is unstructured for a human to read reliably by grepping, unlike the purpose-built state show command. Option C is incorrect and risky — terraform import is for attaching an unmanaged resource to state; running it against a resource that is already tracked is not the intended read-only inspection step and can produce confusing errors.