Enterprise Azure Terraform Lab Phase 1 Part 6 : RBAC, Scripts, Troubleshooting, and Cleanup

๐Ÿ“… Created: 2026-05-04 | โฑ๏ธ Read Time: 6 mins

๐Ÿ“ GitHub Repository: lwc-wk/enterprise-azure-lab1

Enterprise Azure Terraform Lab Phase 1 Part 6 : RBAC, Scripts, Troubleshooting, and Cleanup

๐Ÿงฉ Background

The last part of Phase 1 focuses on operational maturity.

Deploying Azure resources is only one side of the lab. I also wanted to show:

  • Least-privilege RBAC
  • Local deployment scripts
  • Troubleshooting discipline
  • Screenshot evidence
  • Cleanup and cost control
  • Portfolio packaging

๐Ÿ” Azure RBAC Baseline

Basic Azure RBAC is implemented with Terraform role assignments.

The Entra ID groups are created first:

lab-readers
lab-operators

Terraform then assigns roles using group Object IDs.

Group Scope Role Purpose
lab-readers Resource Group Reader Read-only access to the lab
lab-operators Web App Website Contributor Operate App Service without broad infrastructure access

RBAC variables are stored in:

env/local.rbac.tfvars

This file is not committed.

Screenshot

Screenshot

Screenshot


๐Ÿงฐ Local Scripts

Before building a full AZ-400 pipeline, the lab uses local scripts.

deploy-infra.sh

This script:

  • Finds the project root
  • Switches into infra/
  • Runs terraform init
  • Runs terraform fmt
  • Runs terraform validate
  • Loads env/dev.tfvars
  • Loads env/local.secrets.tfvars if present
  • Loads env/local.rbac.tfvars if present
  • Runs terraform plan
  • Runs terraform apply
  • Shows Terraform outputs

deploy-app.sh

This script should:

  • Install dependencies
  • Build the React app
  • Create the deployment zip
  • Deploy to App Service
  • Restart the Web App

destroy.sh

This script destroys the lab environment to control cost.

๐Ÿ“Œ explanation:

Created local scripts before moving to CI/CD. This standardizes deployment and cleanup and becomes a stepping stone toward AZ-400 pipeline automation.


๐Ÿ–ผ๏ธ Screenshot Evidence Checklist

Because the lab is destroyed after validation, screenshots become portfolio evidence.

Recommended evidence list:

docs/screenshots/
โ”œโ”€โ”€ 01-terraform-apply-success.png
โ”œโ”€โ”€ 02-resource-group-overview.png
โ”œโ”€โ”€ 03-vnet-subnets.png
โ”œโ”€โ”€ 04-nsg-rules.png
โ”œโ”€โ”€ 05-nsg-subnet.png
โ”œโ”€โ”€ 06-storage-security.png
โ”œโ”€โ”€ 07-log-analytics-workspace.png
โ”œโ”€โ”€ 08-web-app-running.png
โ”œโ”€โ”€ 09-app-service-overview.png
โ”œโ”€โ”€ 10-app-service-plan.png
โ”œโ”€โ”€ 11-scale-up-before.png
โ”œโ”€โ”€ 12-scale-up-demo.png
โ”œโ”€โ”€ 13-scale-down-after.png
โ”œโ”€โ”€ 14-deployment-slot-staging.png
โ”œโ”€โ”€ 15-slot-swap-option.png
โ”œโ”€โ”€ 16-app-service-diagnostic-settings.png
โ”œโ”€โ”€ 17-storage-diagnostic-settings.png
โ”œโ”€โ”€ 18-budget-alert.png
โ”œโ”€โ”€ 19-rbac-resource-group-reader.png
โ”œโ”€โ”€ 20-rbac-app-service-role.png
โ””โ”€โ”€ 99-terraform-destroy-success.png

The most important screenshots are:

  • Terraform apply success
  • VNet/subnet design
  • NSG rules and association
  • Storage security baseline
  • App Service running
  • Diagnostic settings
  • Budget alert
  • RBAC assignments
  • Terraform destroy success

๐Ÿงฏ Troubleshooting Notes

App Service Free Tier Quota

East US returned Free App Service capacity/quota issues.

Central US succeeded.

Lesson:

Azure App Service free-tier availability can be region-dependent.

Resolution:

  • Move lab region to centralus
  • Use a clean Resource Group
  • Keep F1 where available
  • Destroy after validation

App Service Capacity Conflict

Azure returned:

No available instances to satisfy this request.

Resolution:

  • Clean up partial deployment
  • Change project name to azlab2
  • Deploy into a clean Resource Group

Partial Apply Cleanup

A partial deployment left behind a VNet and blocked Resource Group deletion.

Terraform detected nested resources and refused to delete the Resource Group.

Resolution:

  • Manually delete leftover VNet
  • Re-run destroy / cleanup
  • Use clean state and clean naming

Terraform Optional Output Issue

When optional deployment slot outputs were added but the slot resource was disabled, Terraform validation failed.

Lesson:

Optional resources and optional outputs should live together in the same disabled template.

Terraform State Query Issue

Running terraform state list from scripts/ returned no state.

Reason:

Terraform configuration and backend are in infra/.

Fix:

cd infra
terraform state list

๐Ÿงน Terraform Destroy and Cleanup

The lab follows a destroy-after-validation model.

That means:

  1. Deploy infrastructure
  2. Validate resources
  3. Capture screenshots
  4. Confirm monitoring, RBAC, and budget evidence
  5. Destroy the lab resources
  6. Keep only the backend state layer if needed

Screenshot

Screenshot

Screenshot


๐Ÿ“ฆ Git and Portfolio Packaging

After a stable checkpoint:

git status
git add .
git commit -m "Complete AZ-104 phase 1 Azure Terraform lab"
git push

Important files not to commit:

env/local.secrets.tfvars
env/local.rbac.tfvars
app/node_modules/
app/dist/
app/app.zip
.terraform/
*.tfstate

๐ŸŽฏ Interview Summary

Short version:

This project is a Terraform-managed Azure infrastructure lab. It deploys a small enterprise-style environment with Resource Group lifecycle boundaries, VNet segmentation, NSG controls, secure Storage Account settings, Log Analytics monitoring, diagnostic settings, App Service hosting, budget alerts, and basic RBAC. It is designed to be deployed for validation and destroyed afterward for cost control.

Longer version:

I built this lab to demonstrate practical AZ-104 infrastructure skills. The design separates permanent Terraform backend infrastructure from ephemeral lab resources. It uses standardized naming, tags, subnet segmentation, NSG boundaries, secure storage defaults, Log Analytics, diagnostic settings, Resource Group scoped budget alerts, App Service hosting, and group-based RBAC. I also documented optional autoscale and deployment slot workflows while keeping them disabled by default to control cost.


๐Ÿงพ Key Takeaway

This lab is not about using the most Azure services.

It is about proving that I can:

  • Design before deploying
  • Use Terraform safely
  • Understand Azure resource relationships
  • Troubleshoot real Azure limitations
  • Control cost
  • Apply least privilege
  • Connect monitoring properly
  • Explain tradeoffs clearly
  • Destroy resources cleanly

That is the real foundation for moving from AZ-104 into AZ-400, SC-300, DevSecOps, and future AI infrastructure work.