Skip to main content

Learn any cloudTerraform LearnLabsValidate a Landing Zone Builder download

Validate a Landing Zone Builder download

WorkspacesUnknown

Take the zip the Landing Zone Builder at /tools/landing-zone hands you, unpack it in the workspace, and run terraform init, fmt and validate against the Azure Verified Modules it declares — the same checks the lab runner applies before anything is planned.

Intermediateabout 25 minutesToolsterraform, az

Opening your lab workspace…

Steps

  1. Step 1: Build and download a landing zone

    Open the Landing Zone Builder, choose the components you want (management groups, policy, management, a hub and spokes) and download the zip. The builder writes plain Terraform on Azure Verified Modules: every module block names a registry module and a version, so the files initialise anywhere Terraform can reach the registry.

  2. Step 2: Upload it into the workspace and unzip

    The lab folder starts empty apart from a README. Drag the zip into the file explorer (or use File > Upload), then in the terminal:

    unzip landing-zone-*.zip -d landing-zone && cd landing-zone && ls
    

    You should see nine .tf files. Read main.tf first: the comments say why each call looks the way it does, not only what it is.

  3. Step 3: terraform init, with the network on

    terraform init
    

    This workspace reaches the Terraform registry, so init downloads the Azure Verified Modules and their providers — tens of megabytes for a full landing zone. Note how long it takes and what lands in .terraform/; the lab runner at the end does the same work with no network at all, from offline copies of these modules.

  4. Step 4: fmt and validate, then break something

    terraform fmt -check -diff
    terraform validate
    

    fmt -check reports formatting only and changes nothing; validate checks that every reference resolves and every argument is one the provider or module accepts. Now open main.tf, misspell a reference inside one module call (for example the resource group name a module reads), and run terraform validate again. It names the file and line. Fix it and re-run until both pass.

  5. Step 5: What validate cannot tell you

    Validate never contacts Azure, so it cannot know whether a name is taken, whether a policy definition exists, or what will be created. That is a plan. If you want to see one:

    az login --use-device-code
    terraform plan
    

    A plan needs a subscription and read permissions; it changes nothing. Stop there: the articles for this lab explain why nothing from a lab is ever applied.

  6. Step 6: Check it on the lab runner

    The Landing Zone Builder page offers to validate your download on the lab: the runner receives the root, swaps each module source for its offline copy of that Azure Verified Module at a version that satisfies your constraint, and runs terraform init -backend=false and terraform validate with the network switched off. Compare its log with what you ran here — same result, no download.

    Checked by the agent (terraform-validate): The runner takes one main.tf as text or a whole root as a tar archive, and inits it with no network from offline copies of the Azure Verified Modules the builder emits.