External Exercise Lanes

This module is artifact-driven. Use these lanes after you have finished the concept pages and produced each practice file's artifact. Lanes exist to give you extra volume on one specific failure mode, not as a reading list.

How To Use This Page

1. Finish the relevant concept and practice page.
2. Produce the artifact (a plan, a module, a refactor PR, a policy).
3. Prefer the local validation alternative first: terraform fmt, terraform validate, saved plan review, static scan, and a mock resource diagram. Apply to real cloud only when the exercise explicitly needs provider behavior.
4. If the artifact felt shaky, open the matching lane and work through its target outcomes.
5. Keep a mistake log with tags such as state rm without import, missed -/+ in plan, module with provider block, workspaces for environments, plan not in PR, moved block skipped, prevent_destroy removed without review, policy bypass instead of amend.

Lane 1: Terraform Core Volume

Use this lane when the issue is fluency with HCL syntax, providers, and the plan/apply loop.

• Terraform Tutorials: AWS -- Get Started
• Terraform Tutorials: Configuration Language
• Terraform Language: Resources
• Terraform Language: Providers
• Terraform Language: Data Sources

Target outcomes:

• 5 small root configurations built from scratch (one resource each, different cloud or different service), each validated locally with terraform validate, saved plan.txt, and either deployed/destroyed in a budgeted sandbox or represented with a mock resource diagram
• 3 configurations where the resource uses a data source for one of its attributes (AMI lookup, caller identity, DNS zone, etc.)
• 1 configuration with at least three providers (e.g., aws + random + tls) interacting
• 2 broken configurations you fix from the plan output alone -- no Googling the error

Lane 2: Module Design Volume

Use this lane when the issue is drawing module boundaries and writing reusable modules.

• Terraform Tutorials: Create a Module
• Terraform Tutorials: Module Structure
• Terraform Best Practices: Code Structure
• Terraform Best Practices: Key Concepts
• Terraform Language: Input Variables
• Terraform Language: Output Values

Target outcomes:

• 4 reusable modules with proper contracts (inputs, outputs, README, no provider block)
• 2 module versioning scenarios (major, minor, patch) written up with example PRs
• 2 module README files peer-reviewed by someone outside your project
• 1 refactor of an existing root module into 2-3 smaller modules, with moved blocks preserving state

Lane 3: State and Collaboration Volume

Use this lane when the issue is shared state, locking, and multi-engineer safety.

• Terraform Language: Backends
• Terraform Language: S3 Backend
• Terraform Language: Remote State
• Terraform Language: State Locking
• Terraform Language: Workspaces
• Terraform Tutorials: Use Remote State

Target outcomes:

• 2 backend exercises: at least one local-backend migration/inspection and, only if using cloud sandbox, S3+DynamoDB or HCP Terraform with state migrated from local
• 1 deliberate lock-race demonstration (two apply runs in parallel) with the lock error captured
• 1 terraform_remote_state integration where one stack consumes another stack's outputs
• 1 directory-per-environment and 1 repo-per-environment layout, each deployed to at least two envs

Lane 4: Refactoring and Incident-Grade Volume

Use this lane when the issue is refactoring under pressure or repairing broken state.

• Terraform Language: Refactoring with moved
• Terraform Language: Import
• Terraform Command: state
• Terraform Language: lifecycle
• Terraform Best Practices: Running Terraform

Target outcomes:

• 5 refactors using moved blocks (intra-module, cross-module, renaming, module-extraction)
• 3 import block adoption drills using either disposable sandbox resources or mocked fixtures, each with a "plan is clean" screenshot or plan excerpt
• 1 deliberate state corruption (in a scratch env) repaired via terraform state rm + terraform import
• 2 PRs where a reviewer caught a destructive plan in the diff and rejected; write both perspectives

Lane 5: Policy and Governance Volume

Use this lane when the issue is enforcing organizational invariants on IaC changes.

• Open Policy Agent: Docs
• Open Policy Agent: Policy Language
• HashiCorp Sentinel: Documentation
• tfsec docs (migrating to Trivy)
• Trivy: Misconfiguration scanning

Target outcomes:

• 3 Rego policies written, tested (opa test), and run against real plan.json fixtures
• 1 CI pipeline that runs tfsec/Trivy on every PR against an IaC repo
• 1 Sentinel policy equivalent of one of your Rego policies (can be read-only, no HCP required)
• 1 written memo: "here is the set of 5-10 policies our org needs; here is what each catches"

Self-Curated Exercise Set

Build a custom set with these minimums:

• 10 validate/plan review cycles across different providers or modules; cloud apply/destroy cycles count only when budget alerts and teardown are in place
• 5 modules with published READMEs, inputs, and outputs
• 3 refactors with moved blocks, zero destructive plans
• 3 Rego policies in CI
• 2 backend migrations or simulations (local -> local variant, local -> remote, or backend-A -> backend-B)
• 1 drift-detection demonstration (intentional out-of-band change + plan showing it)

Completion Checklist

• Completed at least one lane in full
• Logged at least 10 mistakes with tags
• Shipped at least 3 modules with published contracts
• Performed at least 1 import-block adoption on disposable real infrastructure or a documented mock fixture
• Run at least 1 policy (OPA or tfsec/Trivy) in CI against a real IaC repo
• Facilitated at least 1 Terraform PR review as a reviewer (not the author) with substantive comments on the plan