Before Lab 5.1 — Discover & Fix Compliance Violations

Mitch Mommers14/06/2026About 3 min

Before Lab 5.1 — Discover & Fix Compliance Violations

Day 5 closes the course arc by introducing compliance and policy. Before you start, you need to understand what compliance means in the cloud and why it matters when no one is watching.

What is compliance in the cloud?

Compliance means proving that your systems meet certain standards — not just that they are secure, but that you can show evidence of it. In the cloud, this is harder than it sounds because:

This is where governance comes in — the rules and processes that make sure compliance standards are actually followed.

Security controls — a quick refresher

Before we dive in, remember the three types of security controls you'll encounter throughout this day:

Preventive — stop bad things before they happen (deny policies, require secure transfer)
Detective — report what went wrong (audit missing diagnostic settings, audit public exposure)
Corrective — fix what went wrong automatically (add missing tags, disable public blob access)

For a detailed breakdown with trade-offs and examples, see the Compliance and Governance theory page.

Why start with manual fixes?

Before you automate anything, you need to understand what a fix looks like. Manual fixes teach you three things:

The scope of the problem — how many resources are affected, what types
The effort required — what commands, what steps, what could go wrong
Whether automation is worth it — if the fix is simple and repetitive, it should be automated

For a detailed breakdown of the three approaches to fixing problems (manual, encoded policy, automated remediation) and the Auto-Remediate vs Alert-Only decision framework, see the Security Automation theory page.

Key principle: Fix it once manually, then encode the rule so it never needs to be fixed again.

Deploying Day 5 Infrastructure

Before you can find compliance violations, you need to deploy the Day 5 environment. This lab starts with a fresh repository containing only the Day 5 infrastructure files. You'll run Terraform against the Day 5 configuration to deploy all resources.

Step 1: Clone the Day 5 Start Files

Day 5 Start Files

Step 2: Set up your variables file

Copy the example variables file from the infrastructure directory:

cp terraform.tfvars.example student.tfvars

Open student.tfvars in your editor and set a unique student prefix:

student_prefix = "jdoe"
location       = "westeurope"
environment    = "dev"

Replace jdoe with your own unique prefix.

Warning

Your student_prefix must be unique. Azure resource names such as Storage Accounts and Key Vaults must be globally unique. If two students use the same prefix, deployment may fail.

Step 3: Deploy the infrastructure

Navigate to the infrastructure directory, initialize Terraform, review the plan, and apply:

cd day-5/infrastructure
terraform init
terraform fmt
terraform validate
terraform plan -var-file student.tfvars --out deployment.plan
terraform apply deployment.plan

Tips

Do not skip the plan step. The plan shows what Terraform will create, change, or destroy before it makes any changes in Azure.

After deployment, retrieve useful outputs:

terraform output -raw resource_group_name
terraform output -raw public_backend_url
terraform output -raw key_vault_name
terraform output -raw frontend_storage_account_name

Then verify the created resources:

az resource list `
  --resource-group "$(terraform output -raw resource_group_name)" `
  --output table

You should see:

Microsoft.Web/sites
Microsoft.KeyVault/vaults
Microsoft.Storage/storageAccounts
Microsoft.OperationalInsights/workspaces
Microsoft.Insights/components

Info

Important: The Day 5 infrastructure has intentional compliance violations in the dev environment. These are the violations you will discover in Lab 5.1.

What you will find in this lab

Your Day 5 environment has intentional compliance violations — safe ones, designed for learning. You will discover:

Resources missing required tags (environment, student, managed_by, day)
Storage containers with public blob access enabled — note: In azurerm provider 3.0+, the storage account property that controls whether blobs CAN be made public is called allow_nested_items_to_be_public (Azure ARM name: AllowBlobPublicAccess). Having this set to true means public access IS POSSIBLE but doesn't guarantee it — individual containers/blobs must also be configured with public access level separately. The violation here is a container explicitly set to public access.
Key Vault without diagnostic settings enabled
Resources with inconsistent tag values across resource groups

Important: These violations are intentional. You are finding problems that would exist in a real environment before governance controls were applied.

After this lab

In Lab 5.1, your goal is to observe and document — do not fix anything yet. You will fix these manually in a later lab once you understand the automated approaches.