lock_openFree sampleMaintain infrastructure with Terraformmedium
An engineer needs the current private IP address that Terraform recorded for a single instance so they can paste it into a ticket. They know the resource address is aws_instance.app. Which command prints the attributes of just that one resource from state?
- Aterraform show aws_instance.app
- Bterraform state list aws_instance.app
- Cterraform state show aws_instance.appcheck_circle Correct
- Dterraform output aws_instance.app
Use terraform state show with a resource address to inspect one resource's recorded attributes. terraform state show <address> looks up a single resource in state and prints its stored attribute values, making it the correct tool for reading one instance's details rather than the whole state.
Why A is wrong: terraform show takes an optional plan or state file path as its argument, not a resource address, so passing aws_instance.app here does not select a single resource as intended.
Why B is wrong: terraform state list only filters and prints matching addresses, so it would confirm the resource exists but never display its attribute values such as the private IP.
Why C is correct: terraform state show accepts a single resource address and prints that resource's recorded attributes from state, which is exactly what is needed to read one instance's private IP.
Why D is wrong: terraform output reads named output values, not resource addresses, so it fails unless an output happens to be declared with that exact name, which is not the case here.
lock_openFree sampleMaintain infrastructure with Terraformmedium
An engineer wants to bring an existing Google Compute Engine instance under Terraform management using an import block, and wants a single 'terraform apply' to both import the instance and generate the matching configuration file for them. Which addition to their workflow achieves this in Terraform 1.x?
import {
to = google_compute_instance.web
id = "projects/demo/zones/europe-west1-b/instances/web-1"
}
- ARun 'terraform apply' on its own, because an import block automatically writes the resource configuration into the root module during the apply.
- BAdd 'generate = true' inside the import block so Terraform emits the configuration during the next apply.
- CRun 'terraform plan -generate-config-out=generated.tf', review the generated resource block, then run 'terraform apply'.check_circle Correct
- DRun 'terraform import google_compute_instance.web projects/demo/...' first, which writes both the state entry and a generated.tf file automatically.
Know that import blocks combined with terraform plan -generate-config-out can import a resource and scaffold its configuration. In Terraform 1.x an import block declares the target address and existing ID, and running terraform plan with -generate-config-out writes a starting HCL block for the resource; only after reviewing that generated configuration does apply perform the import, giving both state and config in one workflow.
Why A is wrong: This is tempting because import blocks are declarative, but they only import into state; configuration generation requires the explicit -generate-config-out flag on plan, so an apply alone leaves the block undefined.
Why B is wrong: This invents an attribute that does not exist; the import block supports 'to' and 'id' only, and config generation is driven by the plan flag rather than a block argument.
Why C is correct: The import block plus the -generate-config-out flag produces HCL for the imported resource, which the practitioner reviews and keeps before applying, giving both the import and a starting configuration.
Why D is wrong: The CLI import command populates state only and never generates configuration, so this would import the instance but leave the practitioner to hand-write the HCL themselves.
lock_openFree sampleMaintain infrastructure with Terraformmedium
After successfully importing a resource into state, a practitioner runs terraform plan and Terraform reports that it wants to change several attributes on that resource. Assuming the real resource is healthy, what does this most likely indicate?
- AThe import failed silently and the resource was never actually recorded in state.
- BTerraform always proposes a first replacement after any import to reconcile ownership.
- CThe configuration written for the resource does not yet match the imported resource's real attributes.check_circle Correct
- DThe state file has been corrupted and must be rebuilt from scratch before planning.
Recognise that a post-import plan showing changes means the configuration must be aligned with the imported resource. Import writes only the current state of the real resource. Terraform then compares that state against your configuration during plan, so any attributes you have not accurately written into configuration appear as proposed changes until the configuration is edited to match the imported resource.
Why A is wrong: This is tempting, but a failed import would not leave the resource in state at all; a plan proposing changes confirms the resource is tracked and merely mismatched.
Why B is wrong: This sounds procedural but is untrue; a correctly matched configuration produces a no-change plan after import, so proposed changes point to a real discrepancy.
Why C is correct: Because import only records state, the hand-written configuration can differ from the live resource; the plan surfaces that gap as proposed changes until the configuration is reconciled.
Why D is wrong: Jumping to corruption overreacts; a plan running normally and reporting specific attribute changes is expected behaviour when the configuration and imported resource diverge.
lock_openFree sampleMaintain infrastructure with Terraformeasy
After finishing a debugging session, a practitioner notices that every subsequent Terraform command in the same shell is still printing pages of low-level log output. What is the most appropriate way to return to normal, quiet output?
- ARun 'terraform apply -quiet' so the CLI flag suppresses the verbose logging for future runs.
- BSet TF_LOG=OFF, which is the dedicated value that disables all logging permanently.
- CDelete the terraform.log file from the working directory to stop further logging.
- DUnset the TF_LOG environment variable, or set it to an empty value, so logging returns to its default quiet state.check_circle Correct
Verbose logging persists while TF_LOG is set, so unsetting or emptying it restores Terraform's default quiet output. Terraform only produces verbose logs when TF_LOG contains a valid level, so unsetting the variable or clearing its value is what returns the CLI to its normal quiet behaviour.
Why A is wrong: A per-command quiet flag seems logical, but logging is driven by an environment variable rather than a CLI flag, so this would not remove the log output.
Why B is wrong: OFF looks like the natural disable value, but it is not a defined Terraform log level, so verbose output would continue.
Why C is wrong: Removing the log file is tempting, but the logging behaviour comes from the TF_LOG setting, not the file, so a new run would simply recreate the output.
Why D is correct: Verbose logging is enabled only while TF_LOG holds a recognised level, so clearing that variable restores the normal, unlogged output for later commands.
lock_openFree sampleMaintain infrastructure with Terraformeasy
An engineer wants verbose Terraform logs written to a file for later review rather than scrolling past the terminal, while still keeping the logging enabled. Which pair of environment variables achieves this?
$ export TF_LOG=DEBUG
$ export ???=./terraform.log
$ terraform plan
- ATF_LOG for the level and TF_LOG_FILE for the destination file path.
- BTF_LOG for the level and TF_OUTPUT for the destination file path.
- CTF_LOG for the level and TF_LOG_PATH for the destination file path.check_circle Correct
- DTF_LOG_PATH for both the level and the destination, using a single combined value.
Setting TF_LOG_PATH alongside TF_LOG persists verbose log output to a named file for later inspection. TF_LOG turns logging on at a given level while TF_LOG_PATH redirects that output to a file, so both must be set to capture verbose logs on disk instead of only in the terminal.
Why A is wrong: The naming is plausible, but the variable that sets the log destination is TF_LOG_PATH, not TF_LOG_FILE, so the file would not be written.
Why B is wrong: TF_OUTPUT reads like an output redirect, but it is not a recognised Terraform variable, so the logs would still go only to standard error.
Why C is correct: TF_LOG enables logging at the chosen level and TF_LOG_PATH tells Terraform to append that log output to the named file, which is exactly the behaviour required.
Why D is wrong: TF_LOG_PATH only sets the file location; the level must be supplied separately through TF_LOG, so one variable cannot do both jobs.