3.7 Governance and Cost Case Lab

Case background

Contoso is moving three workloads to Azure: a public web application, an internal finance application, and a developer sandbox. The cloud platform team owns network connectivity, monitoring, and governance. Application teams own their own compute and storage inside approved boundaries. Finance needs monthly cost visibility by application and cost center. Security requires production resources to stay in approved regions, deny public IPs except for the web edge, and prevent accidental deletion of production resource groups.

The proposed hierarchy is:

Tenant root group
|-- mg-platform
|   |-- sub-connectivity-prod
|   `-- sub-management-prod
|-- mg-prod
|   |-- sub-web-prod
|   `-- sub-finance-prod
`-- mg-nonprod
    `-- sub-sandbox-dev

This hierarchy works because it separates stable governance needs. Platform subscriptions host shared network and monitoring assets. Production subscriptions receive stricter policy and budget oversight. Sandbox receives looser resource rules but tighter spending controls. The hierarchy does not mirror every team name, which keeps governance stable as teams change.

Step 1: Select scopes

Start by mapping each requirement to a scope. Approved production regions should be assigned at mg-prod because both production subscriptions need the same allowed locations. Sandbox may have a different policy at mg-nonprod. Platform rules may be assigned at mg-platform. If only the finance application needs a special data classification rule, assign it at sub-finance-prod or its resource group, depending on how broad the rule should be.

The exam often hides the answer in words such as all current and future production subscriptions. That phrase points to a management group assignment. Words such as only this application point toward resource group or subscription scope.

Step 2: Build the resource organization

Create resource groups around lifecycle boundaries. For sub-web-prod, use rg-web-prod, plus dependencies such as rg-web-network-prod only if the network lifecycle is separate. For sub-finance-prod, use rg-finance-app-prod, rg-finance-data-prod, and maybe rg-finance-monitoring-prod if monitoring assets are not centralized. In the platform management subscription, keep shared Log Analytics and action groups away from application resource groups.

Apply required tags at resource group creation:

az group create --name rg-finance-app-prod --location eastus --tags Environment=Prod Application=Finance CostCenter=FIN-100 Owner=team-finance Criticality=Tier1
az group create --name rg-web-prod --location eastus --tags Environment=Prod Application=Web CostCenter=MKT-200 Owner=team-web Criticality=Tier1

Then enforce tag consistency with Policy. Use a deny policy to block creation when required tags are missing at resource group scope, and a modify or inherit policy to add tags to resources when practical. Use remediation for existing resources.

Step 3: Configure governance

Assign an initiative named something like Contoso production baseline to mg-prod. Include allowed locations, required tags, deny public IPs except where excluded, require diagnostic settings, and audit insecure storage configuration. Parameterize allowed regions and tag names. For the web edge exception, avoid weakening the baseline for all production. Use an exemption for the approved web edge resource group or design the policy condition to allow public IPs only when an approved tag or resource group is present.

Assign RBAC with least privilege. The network team can be Network Contributor on the hub network resource group. The monitoring team can be Monitoring Contributor on the management subscription or monitoring resource group. Application teams can be Contributor on their own application resource groups, but not Owner at the subscription unless there is a clear administrative need. Billing readers or cost management roles can be assigned for finance reporting as required by the account type.

Add locks to production resource groups that should not be deleted accidentally:

az lock create --name lock-rg-finance-prod --lock-type CanNotDelete --resource-group rg-finance-app-prod
az lock create --name lock-rg-web-prod --lock-type CanNotDelete --resource-group rg-web-prod

Use ReadOnly locks sparingly. They can block legitimate management operations such as scaling, diagnostics changes, or backup adjustments. For active production environments, CanNotDelete usually addresses accidental deletion while allowing controlled changes.

Step 4: Configure cost operations

Create monthly budgets at production subscription scopes and a stricter sandbox budget. Configure thresholds such as 70 percent forecasted, 90 percent actual, and 100 percent actual. Add action groups if notifications must integrate with ticketing or automation. Use Cost Management views grouped by Application, CostCenter, and Environment. Review untagged cost regularly because untagged spend usually means the deployment process or policy assignment needs correction.

Use Azure Advisor weekly or during cost reviews. Investigate underutilized VMs, unattached disks, idle public IP addresses, App Service plan utilization, and reservation or savings opportunities. Do not apply recommendations blindly. Check owner, performance history, business cycles, and reliability requirements.

Step 5: Troubleshoot lab failures

Failure 1: The finance team cannot deploy a VM in North Europe. Check policy first if the production baseline allows only East US and West US 2. Contributor access does not bypass deny policy. The fix is to deploy in an allowed region or request a policy change or exemption.

Failure 2: The web team cannot delete a test public IP in the production web resource group. Check locks. A resource group CanNotDelete lock blocks deletion of child resources. The fix is controlled lock removal, deletion, and lock reapplication if approved.

Failure 3: Cost reports show unallocated spending. Check tag consistency and timing. Tags may be missing on charge-generating resources, spelled inconsistently, or applied after usage occurred. Use Policy remediation and template corrections.

Failure 4: A deployment fails with a provider namespace error. Check resource provider registration in the subscription. Register the provider or use a deployment path that registers it, assuming permissions allow registration.

Exam-readiness checklist

For every governance case, ask six questions before picking an answer. What scope is required? Who needs permission? What configuration must be allowed or denied? What metadata is needed for reporting? What should notify people? What must be protected from deletion or change? This forces you to choose the Azure feature that matches the requirement instead of selecting a familiar tool.

The best AZ-104 answer is usually the smallest scope that satisfies the requirement. Use management groups for broad inherited governance, subscriptions for billing and quota boundaries, resource groups for lifecycle, RBAC for permissions, Policy for configuration compliance, tags for classification, budgets for spend alerts, Advisor for optimization, and locks for deletion or write protection.