# Assignment

The Nautilus DevOps team is strategically planning the migration of a portion of their infrastructure to the AWS cloud. Acknowledging the magnitude of this endeavor, they have chosen to tackle the migration incrementally rather than as a single, massive transition. They created some services in different regions and later found that some of those can be deleted now.

Delete a VPC named devops-vpc present in us-east-1 region 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 VPC (Keep Code) — `devops-vpc`

Same "delete but keep the code" pattern: **destroy** the VPC 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_vpc" "this" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "devops-vpc"
  }
}
```

## How to run

```bash
cd /home/bob/terraform

# Destroy ONLY this VPC; leaves the code in main.tf intact.
terraform destroy -target=aws_vpc.this -auto-approve
```

## How it works

### Targeted destroy vs. the wrong approaches

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

The `-target` flag scopes the operation to the single resource address
(`aws_vpc.this` — the **Terraform resource name** `this`, not the Name tag
`devops-vpc`). Terraform calls `DeleteVpc`, removes the resource from state, and
leaves your configuration untouched, because destroy operates on infrastructure and
state, never on source code.

### Why the code surviving matters

Keeping the block means the VPC is trivially re-creatable later: a plain
`terraform apply` will see it declared in config but absent from state and recreate
it with the same `10.0.0.0/16` CIDR. That satisfies "we might need to provision this
again."

### One caveat for VPCs — dependencies

`DeleteVpc` only succeeds if the VPC is **empty** of dependent resources. AWS refuses
to delete a VPC that still has subnets, internet/NAT gateways, route tables (beyond
the main one), non-default security groups, ENIs, or running instances attached — the
call fails with `DependencyViolation`.

- If those dependents are **Terraform-managed** in this same config, targeting the VPC
  will normally also plan destruction of what depends on it. If not, or if the delete
  errors with `DependencyViolation`, remove the dependents first (or run a full
  `terraform destroy` if the whole config is just this VPC's stack).
- The **default** security group, default route table, and default NACL are deleted
  automatically *with* the VPC and don't block it.

For a bare VPC like this one (just the CIDR, nothing provisioned inside it), 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** `devops-vpc` again
(`+ 1 to add`). That's expected — **do not apply it**. The task wants the VPC deleted
with the code retained, which is exactly this state.

## Verify

```bash
aws ec2 describe-vpcs \
  --filters Name=tag:Name,Values=devops-vpc \
  --query 'Vpcs' --output text | grep -q . \
  && echo "VPC still exists." \
  || echo "VPC deleted."

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

Expected — the describe returns nothing (VPC gone), and the resource block is still
present in `main.tf`.