Assignment

The Nautilus DevOps team is currently engaged in a cleanup process, focusing on removing unnecessary data and services from their AWS account. As part of the migration process, several resources were created for one-time use only, necessitating a cleanup effort to optimize their AWS environment.

Delete an IAM group named iamgroup_siva using terraform. Make sure to keep the provisioning code, as we might need to provision this instance again later.

The Terraform working directory is /home/bob/terraform.

Note: Right-click under the EXPLORER section in VS Code and select Open in Integrated Terminal to launch the terminal.

Solution

Delete IAM Group (Keep Code) — `iamgroup_siva`

Same shape as the "delete but keep the code" pattern: destroy the group while leaving its provisioning block in main.tf for later reuse. A targeted destroy does exactly this — it acts on the real resource and Terraform state only, never on your .tf source.

`main.tf` — leave unchanged

Do not delete or comment out the block. It stays exactly as given:

resource "aws_iam_group" "this" {
  name = "iamgroup_siva"
}

How to run

cd /home/bob/terraform

# Destroy ONLY this IAM group; leaves the code in main.tf intact.
terraform destroy -target=aws_iam_group.this -auto-approve

How it works

Targeted destroy vs. the wrong approaches

Approach	Result
Delete the resource block, then `apply`	Group is destroyed, but the code is gone — violates "keep the provisioning code."
`terraform destroy` (no target)	Destroys everything in the config, not just this group.
`terraform destroy -target=aws_iam_group.this`	Destroys only this group; code stays in `main.tf`. ✅

The -target flag scopes the operation to the single resource address (aws_iam_group.this — note this is the Terraform resource name this, not the AWS group name iamgroup_siva). Terraform calls DeleteGroup, removes the resource from state, and leaves your configuration file untouched, because destroy operates on infrastructure and state, never on source code.

Why the code surviving matters

Keeping the block means the group is trivially re-creatable later: a plain terraform apply will see it declared in config but absent from state and recreate it. That satisfies "we might need to provision this again" — the declaration remains the reusable blueprint.

One caveat for IAM groups

DeleteGroup only succeeds if the group is empty — no users as members and no attached/inline policies. If the destroy errors with DeleteConflict, detach everything first, then re-run:

# Remove any members
aws iam get-group --group-name iamgroup_siva \
  --query 'Users[].UserName' --output text | \
  xargs -r -n1 -I{} aws iam remove-user-from-group --group-name iamgroup_siva --user-name {}

# Detach any managed policies
aws iam list-attached-group-policies --group-name iamgroup_siva \
  --query 'AttachedPolicies[].PolicyArn' --output text | \
  xargs -r -n1 -I{} aws iam detach-group-policy --group-name iamgroup_siva --policy-arn {}

# Then retry
terraform destroy -target=aws_iam_group.this -auto-approve

For a bare group like this one (created empty), the plain targeted destroy works directly.

Expected state afterward

After the destroy, the config still declares a resource that no longer exists in state, so terraform plan will show Terraform wants to create iamgroup_siva again (+ 1 to add). That's expected — do not apply it. The task wants the group deleted with the code retained, which is exactly this state.

Verify

aws iam get-group --group-name iamgroup_siva 2>&1 | grep -q 'NoSuchEntity' \
  && echo "Group deleted." \
  || echo "Group still exists."

# Confirm the code is still present
grep -A2 'resource "aws_iam_group" "this"' /home/bob/terraform/main.tf

Expected — get-group fails with NoSuchEntity (group gone), and the resource block is still present in main.tf.

4.0 KiB Raw Blame History