Files

105 lines
4.0 KiB
Markdown

# 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:
```hcl
resource "aws_iam_group" "this" {
name = "iamgroup_siva"
}
```
## How to run
```bash
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:
```bash
# 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
```bash
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`.