Security controls become easier to understand when you can observe their behaviour. A route table defines a path, a firewall makes a decision, and diagnostic logs provide evidence you can investigate.

I’ve put together Azure Security Lab to connect those pieces in a practical learning environment. The repository combines Terraform, Windows workloads, Azure network controls, and guided validation, with optional extensions for identity and SOC training.

Explore the complete Azure Security Lab repository on GitHub.

Start with a focused network environment

The default lab has three virtual networks: a hub, a test spoke, and a protected spoke. Azure Firewall Basic sits in the hub. A Windows test client provides the starting point for connectivity exercises, while a Windows IIS VM represents the protected workload.

The protected VM has no public IP. Route tables direct private traffic between the spokes through the firewall, and network security groups define permitted traffic at the subnet boundary.

The main exercise is concrete: HTTP access from the test client to the protected application should succeed, while administrative access to the protected VM should fail. You then look for evidence of those decisions.

Understand the controls

• Firewall and routing: inspect the intended traffic path and the rules that allow or deny a connection.

• Network security groups: examine segmentation rules at the subnet boundary.

• Key Vault: retrieve generated credentials and lab values.

• Log Analytics: query firewall and Key Vault diagnostics.

• Azure Policy: inspect audit findings for tags, locations, public IPs, and storage settings.

• Budget alerts: track the financial footprint of the exercise.

The default policies use audit mode. They help you examine posture and understand policy scope. The test client’s public RDP path is restricted through your configured administrator source address; Bastion is a separate private-access option.

Follow a practical learning route

The wiki field guide links the deployment instructions, scenarios, operational runbooks, and reference material. The README groups the material into seven scenario areas, including optional identity and SOC exercises.

1. Review the design and choose your scope

Start with the architecture and feature toggles. Decide whether you are practising the default network controls, private administration, identity, or the broader SOC profile. Review permissions, access settings, and the expected Terraform plan before creating resources.

2. Deploy and inspect the environment

After deployment, inspect VM addresses, NSG rules, and route-table next hops. Confirm that the protected VM has private addressing and that the intended spoke routes reference the firewall. Establish what was created before interpreting test results.

3. Test allowed and blocked traffic

From the test VM, request the protected application over its private address. Then check the administrative port used in the scenario. Compare the results with the documented expectations, and investigate mismatches through the application, NSG, route, and firewall configuration.

4. Connect behaviour with telemetry

Query Log Analytics for firewall decisions and Key Vault activity. Relate the event time, source, destination, and rule to the action you performed.

Use the security test matrix to connect each control with its Terraform owner, validation action, and expected evidence.

5. Extend into SOC investigation

The optional SOC profile adds Sentinel content, endpoint telemetry, an AD DS identity environment, watchlists, workbooks, automation rules, and a Logic Apps playbook scaffold. Follow the documented benign simulations, inspect raw records, and investigate training incidents. Record the evidence behind your assessment before closing an exercise.

6. Verify cleanup

Use the matching environment configuration when destroying the lab. Confirm that resources and resource groups have been removed, and protect local state and plan artifacts. Cleanup completes the exercise because infrastructure ownership, secrets, and cost continue beyond the last connectivity test.

Choose optional features deliberately

Sentinel and the SOC components are disabled in the default profile. The dedicated SOC profile enables the broader investigation environment. Defender for Cloud and Defender connectors remain separate choices even there, because licensing and tenant onboarding requirements vary.

Entra test identities, report-only Conditional Access, and Bastion also need deliberate configuration. GitHub Actions supplies formatting, Terraform validation, linting, infrastructure scanning, and secret scanning. Cloud deployment remains an explicit operational step.

Read the dated validation evidence

The default environment report records an apply, runtime-test, and destroy cycle on 7 June 2026. It includes successful private HTTP, blocked protected RDP, and firewall log evidence.

The SOC report dated 7 July 2026 records domain joins, telemetry, Sentinel content, firewall and Key Vault incidents, and teardown. It also identifies unvalidated IIS file-log ingestion and follow-up validation for updated analytics queries. These records describe specific runs and their limits.

Keep practice sessions bounded

Azure Firewall is the main default cost driver. Additional VMs, Bastion, Sentinel ingestion, and optional licensed services can expand the footprint. Select the features needed for your exercise and destroy the environment when finished. Budget alerts support awareness; they do not impose a hard spending cap.

Start with the GitHub repository, follow the wiki, and use the test matrix to build an evidence record for your own run.

Which would you practise first: segmentation, firewall investigation, Key Vault auditing, or SOC incident triage?