Exercise 2: The Two-Step Workflow for Safely Importing an Existing Resource — Possible Solution
====================================================================

Step 1: WRITE THE MATCHING RESOURCE BLOCK BY HAND FIRST. Before running
`terraform import` at all, a `resource` block has to be written in the
configuration that represents this AWS instance as closely as possible
-- its type, its intended arguments, matching what's actually been
observed about the real console-created object (instance type, tags,
etc., inspected directly in the console beforehand).

Step 2: RUN THE IMPORT COMMAND, THEN ITERATE AGAINST plan. Running
`terraform import aws_instance.web i-0abcdef1234567890` links that
resource address to the real instance's ID in STATE ONLY -- it does not
generate or fill in the resource block's arguments. Immediately
afterward, `terraform plan` is run to check for a mismatch; any
attribute the hand-written block got wrong compared to the real object
shows up as a planned change. The resource block is then adjusted and
`plan` re-run, repeated until it reports no changes at all -- only at
that point does the configuration genuinely, accurately describe the
real object.

The common surprise, stated explicitly: many people expect `import` to
be a one-command operation that fully onboards an existing resource,
including writing its configuration for them. In versions before
Terraform 1.5's config-generation import blocks, that expectation is
wrong -- `import` only ever touches STATE. Skipping the "write a
resource block first" step, or skipping the "verify with plan
afterward" step, risks either an import command that fails outright
(no matching resource block to attach state to) or, worse, a resource
block that's silently WRONG in ways `plan` would have caught,
potentially causing Terraform to "fix" real attributes on the next
apply that were never actually broken.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly orders the two steps (write the block BEFORE running
import, not after) and explicitly calls out the common misconception
that import alone populates configuration -- exactly the surprise the
chapter's own warn-box names -- rather than describing the steps
without addressing why the ordering and the surprise both matter.