A parks department wants a throwaway test stack for a permit portal and a stable production stack, and needs to delete the entire test environment in one action without touching production. How should the team organize those Azure resources?

A resource group is a logical container that defines a shared lifecycle for the Azure resources it holds. When the parks department needs a throwaway permit-portal test stack beside a stable production stack, placing each environment in its own resource group is the right pattern because deleting a resource group deletes the resources inside it. Operators can remove the entire test environment in one deliberate action while production resources continue undisturbed in a different group.

Mixing test and production into one resource group fails the requirement because a group-level delete would wipe both environments together—the opposite of a safe cleanup. Putting every resource in its own subscription abandons the resource-group model and creates unnecessary billing and access sprawl for what is really a lifecycle-organization problem, not a separate-account problem. Relying only on tags also fails: tags are metadata for filtering, cost allocation, and automation filters; they do not themselves delete resources or act as a lifecycle container.

Exam caveat: resources in a group can still live in different regions, and some resources have special deletion dependencies or locks that can block a clean group delete until those blockers are cleared. Operational check: before deleting the test group, confirm naming and tags distinguish environments, verify no production dependency points into the test group, remove or understand any resource locks, and run a portal or CLI what-if style inventory of the group contents so the delete matches the intended pilot stack only.