A city IT office wants production citizen services and a free-form sandbox for experiments kept apart so quotas, billing, and accidental changes do not collide. What Azure approach matches that goal?
Select an answer to reveal the explanation.
Short Explanation
Prod and playground should not share the same leash. Separate subscriptions give each side its own billing, quotas, and access story. That way a sandbox experiment cannot burn production limits or land on the wrong invoice.
Full Explanation
Production citizen services and a free-form sandbox need stronger isolation than naming conventions alone can provide. Creating separate Azure subscriptions for production and sandbox isolates billing, quotas and limits, and access so experimental work cannot exhaust production quotas, land on the wrong invoice, or inherit overly broad production permissions by accident. That subscription split is the Fundamentals-aligned way to keep playground risk away from live municipal services.
Placing sandbox and production VMs in the same resource group and relying on naming prefixes alone fails because prefixes do not enforce billing walls, quota walls, or delete boundaries—one mistaken bulk operation can still hit both. Using one subscription and “disabling all resource groups” is invalid operationally and removes the normal organization layer without creating isolation. Moving sandbox workloads into a different availability zone inside the same unmanaged shared account without a subscription split addresses resiliency placement, not billing, limit, or access isolation between prod and experiments.
Exam caveat: resource groups and RBAC still matter inside each subscription; separate subscriptions are necessary but not sufficient if identical overly broad roles are copied into both. Operational check: provision distinct subscriptions, assign different owner/contributor sets, set independent budgets and alerts, and verify sandbox deployments cannot select production resource groups before the first experiment lands.