7. Cleanup

Tear down all Azure resources created during the workshop to avoid ongoing costs.

Step 1 — Destroy the Pulumi stacks

The workshop created two Pulumi stacks: dev (Azure infrastructure) in lab/azure/ and a separate stack for the Kubernetes workloads. Destroy them in reverse dependency order — workloads first, then the infrastructure that hosts them.

cd lab/azure
pulumi destroy

Explanation

pulumi destroy removes every resource tracked in the stack state in the correct dependency order. Azure takes a few minutes to delete resources such as AKS clusters and PostgreSQL servers. The command blocks until all deletions are confirmed.

Protected resources

If you completed Challenge 3 and added protect=True to any resource, pulumi destroy will refuse to delete it. Remove the protect option, run pulumi up to apply the change, then re-run pulumi destroy.

Step 2 — Verify in the Azure portal

After pulumi destroy completes, confirm that no billable resources remain.

  1. Open the Azure portal and navigate to Resource groups.
  2. Locate the resource group created by the workshop (e.g. rg-<your-name>-dev).
  3. Confirm the resource group is empty or delete it manually if any orphaned resources remain.

Explanation

Pulumi tracks only the resources it created. Resources created outside of Pulumi (for example, by the Azure portal or the az CLI during troubleshooting) are not removed by pulumi destroy and must be cleaned up manually.

Step 3 — Remove local kubeconfig entries

The workshop added a context to your local ~/.kube/config. Remove it to keep your kubeconfig tidy.

kubectl config delete-context <your-cluster-name>
kubectl config delete-cluster <your-cluster-name>
kubectl config delete-user <your-cluster-name>

Replace <your-cluster-name> with the name shown when you ran az aks get-credentials during the lab. To list all contexts currently in your kubeconfig:

kubectl config get-contexts

Explanation

az aks get-credentials wrote a new context, cluster, and user entry into ~/.kube/config. These entries are harmless once the cluster is deleted, but removing them avoids confusion in future sessions.