Maintain infrastructure with Terraform

Everything in this domain is a day-two operation (the work of running and maintaining infrastructure after it is first built), not a way to create it. Carry that one fact through the whole page: none of these operations provisions, modifies, or destroys a real resource. Importing only writes to Terraform state (Terraform's stored record of the objects it manages); the inspection commands only read; verbose logging only observes. Picture an operator's toolkit that acts on Terraform's records and on its behavior, never on the cloud itself. The classic exam trap is assuming a command does more than it does: that terraform import creates the resource (it only records one that already exists), that terraform state show is as risky as its neighbors terraform state rm and terraform state mv (it is strictly read-only), or that a -verbose CLI (command-line interface) flag exists (logging is set through an environment variable). When an answer choice quietly changes real infrastructure, it is almost never the maintenance command the question wants.

The domain is three jobs an operator does, one per subtopic and in this order. First, when a real object exists that Terraform never created (made by hand, by a script, or by another tool), Import existing infrastructure adopts it into management: either the classic terraform import ADDRESS ID command, which writes state only and needs the resource block to exist already, or the config-driven import block (Terraform 1.5+), which runs through the ordinary terraform plan then terraform apply and can even draft starter HCL (HashiCorp Configuration Language) with terraform plan -generate-config-out=FILE. Next, once objects are managed, Inspect state with the CLI answers what Terraform currently tracks: a family of read-only commands (terraform state list and terraform state show, terraform show, terraform output, plus terraform graph, terraform providers, and terraform version) that read state, outputs, and toolchain metadata without touching anything. Finally, when Terraform behaves in a way you did not expect, Use verbose logging turns on the TF_LOG family of environment variables that stream Terraform Core and provider internals to stderr (standard error), the detail HashiCorp asks for in a bug report.

Across every task here, the exam rewards the safest, most reviewable option. Prefer the config-driven import block, whose effect you preview in a plan, over a one-off terraform import when you have the choice. Prefer the read-only terraform state list and terraform state show over the state-mutating terraform state rm, terraform state mv, or terraform state push unless the task explicitly calls for a change. And remember that reading is not always harmless with secrets: adding -json or -raw to terraform output, or -json to terraform show, prints sensitive values in cleartext, so keep that output out of shared logs. The instinct to carry into every question: when a choice quietly does more than was asked, provisions, mutates state, or exposes a secret, it is usually the wrong answer.