Task 7.1: Import existing infrastructure into your Terraform workspace

• AA data block for the bucket, which Terraform converts to a managed resource on apply

  Incorrect

  Data sources only read objects; they never become managed resources.

• BA moved block from the bucket's cloud ID to the resource address

  Incorrect

  moved changes addresses of objects already in state; it cannot bring in new objects.

• CA lifecycle block with ignore_changes = all, so Terraform adopts the bucket as it is

  Incorrect

  ignore_changes affects updates of managed objects; it does not import anything.

• DAn import block with to and id, then plan and apply

  Correct

  Import blocks are part of the configuration, so the import appears in the plan for review and is recorded in state on apply.

Import blocks make imports part of the normal plan and apply workflow.

• Aterraform import -generate-config for each rule

  Incorrect

  The import command only imports into state and never generates configuration.

• Bterraform plan -generate-config-out=generated.tf

  Correct

  With import blocks for resources that have no configuration, plan -generate-config-out writes HCL for them to a new file; the feature is marked experimental.

• Cterraform show -json > generated.tf, then rename the attributes

  Incorrect

  show -json prints JSON state, which is not usable as configuration.

• Dterraform console with an export command

  Incorrect

  console evaluates expressions; it has no export of configuration.

Generated configuration is a template: review it, trim it and move it into the right files before applying.

• AIt fails; terraform import needs an existing resource block

  Correct

  Before running terraform import you must write a resource block that describes where to map the imported object; the command does not generate configuration.

• BThe instance is imported, and a matching resource block is written to imported.tf

  Incorrect

  The CLI command never writes configuration.

• CThe instance is imported into state, and the next plan keeps it

  Incorrect

  Without a block, the address is invalid; even if state held it, a plan would destroy it.

• DTerraform creates a new instance with the same settings

  Incorrect

  Import never creates infrastructure.

The import command writes state only, into an address your configuration already has.

• AIn terraform.tfstate of another project

  Incorrect

  Another project's state is not a reference for import formats.

• BIn the Terraform CLI configuration file

  Incorrect

  The CLI configuration has no import settings.

• CIn that resource's provider documentation

  Correct

  The import ID depends on the resource type; the provider documentation describes the format.

• DIt is always the resource's display name in the console

  Incorrect

  Formats differ by resource type and are rarely just a name.

Import IDs are provider-specific; read the resource's page.

• ATerraform returns an error, because the output path must not exist yet

  Correct

  You must supply a new file path; an existing file causes an error.

• BTerraform appends the new resource blocks to the end of the existing file

  Incorrect

  Terraform does not append to existing files.

• CTerraform overwrites the file with fresh configuration

  Incorrect

  It refuses to overwrite.

• DTerraform writes to a new file with a numbered suffix next to the old one

  Incorrect

  There is no automatic renaming.

Generated configuration always goes to a new file you name.

• AA moved block that names the DNS provider for the imported records

  Incorrect

  moved blocks change addresses.

• BA data source for each record

  Incorrect

  Data sources do not tell import which provider to use.

• CAn output that exposes each record's ID

  Incorrect

  Outputs expose values; they do not select providers.

• DA provider block, followed by terraform init

  Correct

  If no other resources use the provider, add a provider block so Terraform knows which provider generates the configuration, and re-run init.

Configuration generation still needs a provider to ask for attribute values.

• AIt re-creates the three objects so that Terraform owns them from now on

  Incorrect

  Import never re-creates objects.

• BNothing; it records them in state

  Correct

  Import brings existing resources into state; Terraform records that it imported them rather than created them.

• CIt tags the three objects as managed by Terraform

  Incorrect

  Import changes state, not the objects.

• DIt copies the three objects into a new account

  Incorrect

  Nothing is copied.

Import changes Terraform's records, not the infrastructure.

• AWhen the import runs in an HCP Terraform workspace instead of locally

  Incorrect

  Where the run happens does not decide this; the recommendation turns on how much of the resource's configuration you already know.

• BWhen you already know most of the resource's arguments

  Correct

  The docs recommend writing the resource block manually when you know most arguments, and generated configuration for many or complex resources.

• CWhen the resource sits inside a child module

  Incorrect

  Module placement does not decide this.

• DWhen the import uses the CLI command instead of an import block

  Incorrect

  The recommendation is about how much of the configuration you already know, not about the import method.

Hand-write what you know; generate what you do not.