Task 3.5: Manage infrastructure lifecycle

• ADelete the resource block and every reference to it, using terraform validate to find them, then apply

  Correct

  Removing the block makes Terraform destroy the object on apply, and validate reports leftover references to the deleted resource.

• BRun terraform destroy -target=aws_sqs_queue.jobs once and leave the configuration files exactly as they are

  Incorrect

  destroy does not change the configuration, so the next apply plans to create the queue again.

• CReplace the resource block with a removed block that sets destroy = false, then apply

  Incorrect

  destroy = false only forgets the object; the queue keeps running in the cloud.

• DRun terraform state rm aws_sqs_queue.jobs, then delete the resource block

  Incorrect

  state rm forgets the queue without destroying it, so it stays in the cloud, unmanaged.

To destroy one object permanently, take it out of the configuration and let the next plan and apply destroy it. Commands that act only on state or only for one run leave either the object or the configuration behind.

• AA removed block for aws_s3_bucket.logs with destroy = false forgets only the keys that left the map

  Incorrect

  A removed block applies to the resource as a whole and replaces its resource block, so it would stop managing all three buckets.

• BDropping "legacy" from the map is enough; Terraform keeps a bucket whose key disappears

  Incorrect

  An instance whose key disappears from for_each is planned for destruction.

• CA removed block cannot name aws_s3_bucket.logs["legacy"]; removed does not accept instance keys

  Correct

  The from address of a removed block cannot include an instance key for a resource that has several instances.

• DA moved block from aws_s3_bucket.logs["legacy"] to a data source hands it over without destroying it

  Incorrect

  moved cannot turn a managed resource into a data resource.

• Eterraform state rm 'aws_s3_bucket.logs["legacy"]' forgets that one bucket, after which its key can be dropped

  Correct

  state rm accepts a single instance address, removes only that binding, and leaves the remote bucket in place.

removed blocks work on whole resources or modules, so a single instance is handled with terraform state rm before its key is removed from the map, ideally after a -dry-run to confirm the address.

• AB is now destroyed before its replacement is created

  Incorrect

  The behavior propagates from A, and B cannot opt out.

• BA loses its create_before_destroy behavior for every replacement

  Incorrect

  The setting on A is unchanged.

• CB prevents A from ever being replaced

  Incorrect

  That describes prevent_destroy, not create_before_destroy.

• DIt cannot override the setting Terraform applies to B

  Correct

  Terraform propagates create_before_destroy to dependencies and stores it; setting false on B would imply dependency cycles.

Plan replacements across a dependency chain as a whole, since the ordering of one resource affects its dependencies.

• ATwo chained moved blocks: a to b, and b to c

  Correct

  HashiCorp recommends chaining moved blocks when the same object moves twice, documenting the full history for callers on any version.

• BOne moved block from b to c, replacing the old one

  Incorrect

  Callers still on v1 would plan to destroy aws_instance.a.

• CA removed block for a, and a new resource c

  Incorrect

  That destroys or forgets the object instead of moving it.

• Dterraform state mv in each caller's pipeline

  Incorrect

  moved blocks let callers upgrade without manual state commands.

Keep historical moved blocks in published modules so that every caller can upgrade from any earlier version.

• AForgets the database and blocks any later destroy

  Incorrect

  prevent_destroy is not accepted in a removed block.

• BDestroys the database, as prevent_destroy wins

  Incorrect

  The configuration is invalid rather than resolved in favor of either argument.

• CRejects it; destroy is the only lifecycle argument allowed

  Correct

  In removed blocks, the only supported lifecycle argument is destroy.

• DIgnores the lifecycle block and keeps managing the database

  Incorrect

  A removed block always stops management of the resource.

Use destroy = false to forget an object without destroying it, and nothing else in that lifecycle block.

• Amoved never works between types, as each type has its own schema

  Incorrect

  Some providers do support moving objects between resource types.

• BIt works only if the provider supports that type change

  Correct

  moved can always rename a resource, but changing the type depends on provider support.

• CIt always works, and Terraform converts the attributes

  Incorrect

  Types have separate schemas and are not typically compatible.

• DIt works only for resources in the root module

  Incorrect

  moved blocks also work inside and across modules.

Check the provider documentation before planning a cross-type move.