dojo.md 0.2.1 → 0.2.3

package/courses/terraform-infrastructure-setup/scenarios/level-1/hcl-syntax-errors.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: hcl-syntax-errors
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Fix HCL syntax errors — diagnose missing braces, incorrect attribute assignments, string interpolation issues, and block structure problems"
+  tags: [Terraform, HCL, syntax, validation, formatting, beginner]
+
+state: {}
+
+trigger: |
+  You run `terraform validate` and get multiple errors:
+
+  ```
+  Error: Missing closing brace
+
+    on main.tf line 12:
+    12:   tags = {
+    13:     Name = "web-server"
+    14:
+
+  Error: Unsupported argument
+
+    on main.tf line 8, in resource "aws_instance" "web":
+     8:   ami := "ami-0c55b159cbfafe1f0"
+
+  Error: Invalid reference
+
+    on main.tf line 15, in resource "aws_instance" "web":
+    15:   subnet_id = "${var.subnet_id}"
+  ```
+
+  Your main.tf:
+
+  ```hcl
+  resource "aws_instance" "web" {
+    ami := "ami-0c55b159cbfafe1f0"
+    instance_type = var.instance_type
+
+    tags = {
+      Name = "web-server"
+
+    vpc_security_group_ids = [aws_security_group.web.id]
+  }
+  ```
+
+  Task: Explain HCL syntax fundamentals, common syntax errors and
+  how to fix them, the difference between = and := (Terraform only
+  uses =), string interpolation rules, terraform fmt for auto-formatting,
+  terraform validate for catching errors before plan, and block structure
+  (resource, data, variable, output, locals).
+
+assertions:
+  - type: llm_judge
+    criteria: "HCL syntax fundamentals are explained — blocks: resource, data, variable, output, locals, terraform, provider. Attribute assignment uses = (not :=, that's Go syntax). String interpolation: use ${} inside quoted strings, but for simple references just use var.name directly (no interpolation needed since Terraform 0.12). Heredoc syntax: <<-EOT for multi-line strings. Comments: # for single line, /* */ for multi-line. Lists: [], maps: {}. The specific errors: (1) := should be =, (2) missing closing brace for tags block, (3) bare ${var.subnet_id} should be just var.subnet_id (interpolation-only expressions are deprecated)"
+    weight: 0.35
+    description: "HCL fundamentals"
+  - type: llm_judge
+    criteria: "terraform fmt and validate workflow is covered — terraform fmt: auto-formats HCL files to canonical style (consistent indentation, alignment). Run before committing. terraform fmt -check in CI to enforce formatting. terraform validate: checks configuration for internal consistency (syntax, attribute names, required arguments). Does NOT check against cloud APIs. Workflow order: fmt → validate → plan → apply. validate catches: missing required arguments, unknown attributes, type mismatches, invalid references"
+    weight: 0.35
+    description: "Formatting and validation"
+  - type: llm_judge
+    criteria: "Block structure is explained — resource 'type' 'name' {}: creates infrastructure. data 'type' 'name' {}: reads existing infrastructure. variable 'name' {}: input parameters (type, default, description, validation). output 'name' {}: export values. locals {}: computed local values (like constants). terraform {}: settings (required_version, required_providers, backend). provider 'name' {}: provider configuration. Each block type has specific allowed arguments. Meta-arguments available on resources: depends_on, count, for_each, provider, lifecycle"
+    weight: 0.30
+    description: "Block structure"

package/courses/terraform-infrastructure-setup/scenarios/level-1/plan-output-reading.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: plan-output-reading
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Read terraform plan output — interpret change symbols, understand resource actions, identify destructive changes before apply"
+  tags: [Terraform, plan, output, changes, destroy, beginner]
+
+state: {}
+
+trigger: |
+  Your terraform plan shows this output and you need to understand
+  what will happen before approving:
+
+  ```
+  Terraform will perform the following actions:
+
+    # aws_instance.web will be destroyed and re-created
+    # (because ami has changed)
+  -/+ resource "aws_instance" "web" {
+      ~ ami                    = "ami-old123" -> "ami-new456" # forces replacement
+      ~ arn                    = "arn:aws:ec2:..." -> (known after apply)
+      ~ id                     = "i-abc123" -> (known after apply)
+        instance_type          = "t3.micro"
+      ~ public_ip              = "54.1.2.3" -> (known after apply)
+      + secondary_private_ips  = (known after apply)
+      - tags                   = {} -> null
+        # (15 unchanged attributes hidden)
+      }
+
+    # aws_s3_bucket.data will be updated in-place
+    ~ resource "aws_s3_bucket" "data" {
+        id     = "my-data-bucket"
+      ~ tags   = {
+          + "Environment" = "prod"
+          }
+      }
+
+    # aws_security_group.old will be destroyed
+    - resource "aws_security_group" "old" {
+      - id   = "sg-old789" -> null
+      - name = "old-sg" -> null
+      }
+
+    # aws_security_group.new will be created
+    + resource "aws_security_group" "new" {
+      + id   = (known after apply)
+      + name = "new-sg"
+      }
+
+  Plan: 2 to add, 1 to change, 2 to destroy.
+  ```
+
+  Task: Explain how to read terraform plan output, what each symbol
+  means (+, -, ~, -/+), what "forces replacement" means and why it's
+  dangerous, "known after apply" values, and best practices for
+  reviewing plans before apply.
+
+assertions:
+  - type: llm_judge
+    criteria: "Plan symbols are explained — + (create): new resource will be created. - (destroy): existing resource will be deleted. ~ (update in-place): resource will be modified without recreation. -/+ (destroy and recreate): resource must be destroyed and recreated (replacement). +/- (create before destroy): new resource created first, then old destroyed (lifecycle create_before_destroy). Within attributes: + (added), - (removed), ~ (changed). 'forces replacement' means changing that attribute requires destroying and recreating the resource (e.g., changing AMI on EC2 instance). '(known after apply)' means the value will be determined by the cloud provider during creation"
+    weight: 0.35
+    description: "Plan symbols"
+  - type: llm_judge
+    criteria: "Dangerous changes are identified — destroy and recreate (-/+) is dangerous: causes downtime, new IP address, new resource ID. The example: changing AMI forces EC2 instance replacement — means the server goes down, gets a new public IP, loses ephemeral storage. Review all -/+ changes carefully. Mitigation: lifecycle { create_before_destroy = true } creates the new resource before destroying the old one (reduces downtime). Pure destroy (-) is also dangerous: verify you actually want to remove the resource. Summary line 'Plan: 2 to add, 1 to change, 2 to destroy' is the quick check"
+    weight: 0.35
+    description: "Dangerous changes"
+  - type: llm_judge
+    criteria: "Plan review best practices are practical — always run plan before apply. Save plan: terraform plan -out=plan.tfplan, then terraform apply plan.tfplan (prevents drift between plan and apply). In CI/CD: plan on PR, apply on merge. Review checklist: (1) any destroys? expected? (2) any replacements? understand why? (3) count of changes matches expectations? (4) no sensitive data exposed in plan output? Use terraform plan -target=resource to plan specific resources. terraform plan -detailed-exitcode: exit 0 (no changes), exit 1 (error), exit 2 (changes present) — useful in scripts"
+    weight: 0.30
+    description: "Review practices"

package/courses/terraform-infrastructure-setup/scenarios/level-1/provider-configuration.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: provider-configuration
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Configure Terraform providers — set up AWS credentials, handle authentication errors, manage provider aliases for multi-region deployments"
+  tags: [Terraform, providers, AWS, authentication, credentials, beginner]
+
+state: {}
+
+trigger: |
+  You run `terraform plan` and get this error:
+
+  ```
+  Error: No valid credential sources found
+
+    with provider["registry.terraform.io/hashicorp/aws"],
+    on main.tf line 5, in provider "aws":
+     5: provider "aws" {
+
+  Please see https://registry.terraform.io/providers/hashicorp/aws
+  for more information about providing credentials.
+  ```
+
+  Your configuration:
+
+  ```hcl
+  provider "aws" {
+    region = "us-east-1"
+  }
+
+  resource "aws_s3_bucket" "data" {
+    bucket = "my-data-bucket-12345"
+  }
+
+  resource "aws_s3_bucket" "logs" {
+    provider = aws.west
+    bucket   = "my-logs-bucket-12345"
+  }
+  ```
+
+  You have AWS CLI installed with a profile named "dev" but haven't
+  configured any credentials for Terraform.
+
+  Task: Explain Terraform provider configuration, AWS credential
+  chain (how Terraform finds credentials), provider aliases for
+  multi-region, common authentication errors and fixes, and best
+  practices for credential management (never hardcode keys).
+
+assertions:
+  - type: llm_judge
+    criteria: "AWS credential chain is explained — Terraform AWS provider checks credentials in order: (1) provider block (access_key/secret_key — NEVER do this), (2) environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN), (3) shared credentials file (~/.aws/credentials), (4) shared config file (~/.aws/config with profile), (5) EC2 instance metadata / ECS task role / Lambda execution role. Fix: export AWS_PROFILE=dev or set profile in provider block. For CI/CD: use environment variables or OIDC federation (GitHub Actions → AWS IAM role)"
+    weight: 0.35
+    description: "Credential chain"
+  - type: llm_judge
+    criteria: "Provider aliases are explained — to use multiple regions, define provider aliases: provider 'aws' { region = 'us-east-1' } and provider 'aws' { alias = 'west', region = 'us-west-2' }. Reference alias: provider = aws.west in resource block. Without the alias provider block defined, the aws.west reference will fail. Default provider (no alias) is used when provider isn't specified. Each alias can have different credentials, regions, or assume_role configurations"
+    weight: 0.35
+    description: "Provider aliases"
+  - type: llm_judge
+    criteria: "Security best practices are covered — NEVER hardcode credentials in .tf files (they end up in version control and state files). Use: environment variables, AWS profiles, IAM roles (instance profiles, task roles), or OIDC federation. For assume_role: provider block supports assume_role {} for cross-account access. State files contain provider config — ensure state is encrypted and access-controlled. Use terraform plan output to verify no credentials are exposed. Add *.tfvars with secrets to .gitignore"
+    weight: 0.30
+    description: "Security practices"

package/courses/terraform-infrastructure-setup/scenarios/level-1/resource-creation-failures.yaml

@@ -0,0 +1,54 @@
+meta:
+  id: resource-creation-failures
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Debug resource creation failures — diagnose API errors, dependency issues, naming conflicts, and partial apply states"
+  tags: [Terraform, resources, apply, errors, dependencies, beginner]
+
+state: {}
+
+trigger: |
+  You run `terraform apply` and it partially succeeds:
+
+  ```
+  aws_vpc.main: Creating...
+  aws_vpc.main: Creation complete after 3s [id=vpc-0abc123def456]
+  aws_subnet.public: Creating...
+  aws_subnet.public: Creation complete after 1s [id=subnet-0abc789]
+  aws_security_group.web: Creating...
+
+  Error: creating Security Group (web-sg): InvalidGroup.Duplicate:
+  The security group 'web-sg' already exists for VPC 'vpc-0abc123def456'
+
+  aws_instance.web: Creating...
+
+  Error: creating EC2 Instance: UnauthorizedOperation: You are not
+  authorized to perform this operation. Encoded authorization failure
+  message: ...
+  ```
+
+  State after partial apply:
+  - VPC: created ✓
+  - Subnet: created ✓
+  - Security Group: FAILED ✗
+  - EC2 Instance: FAILED ✗
+
+  Task: Explain how terraform apply works (dependency graph, parallel
+  creation, partial state), what happens when apply partially fails,
+  how to recover from partial failures, common resource creation errors
+  (duplicates, permissions, quotas), and terraform plan vs apply workflow.
+
+assertions:
+  - type: llm_judge
+    criteria: "Apply process is explained — terraform builds a dependency graph (DAG) and creates resources in parallel where possible. Resources with dependencies wait for their dependencies. Partial failure: successfully created resources are saved to state. Failed resources are not in state. On next apply, Terraform will try to create the failed resources again (it won't recreate already-created ones). The state file tracks what exists. Recovery: fix the errors and run apply again. terraform plan shows what will happen without making changes"
+    weight: 0.35
+    description: "Apply process"
+  - type: llm_judge
+    criteria: "Common creation errors are diagnosed — (1) Duplicate resource: security group already exists outside Terraform. Fix: import it (terraform import) or use a unique name. (2) UnauthorizedOperation: IAM permissions missing. Decode the message: aws sts decode-authorization-message. Fix: add required IAM permissions. (3) Quota exceeded: AWS service limits. Fix: request limit increase. (4) Invalid parameter: wrong AMI for region, invalid CIDR block. (5) Timeout: resource takes too long to create (increase timeouts in resource block)"
+    weight: 0.35
+    description: "Common errors"
+  - type: llm_judge
+    criteria: "Plan vs apply workflow is practical — terraform plan: preview changes without modifying infrastructure. Shows: resources to add (+), change (~), destroy (-). Save plan: terraform plan -out=tfplan, then terraform apply tfplan (ensures exactly the planned changes are applied). Always review plan before apply in production. terraform apply -auto-approve: skips confirmation (only for CI/CD, not manual runs). terraform destroy: removes all managed resources. Partial state: use terraform state list to see what's managed, terraform show for current state"
+    weight: 0.30
+    description: "Plan vs apply"

package/courses/terraform-infrastructure-setup/scenarios/level-1/resource-references.yaml

@@ -0,0 +1,70 @@
+meta:
+  id: resource-references
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Fix resource reference errors — debug circular dependencies, missing attributes, implicit vs explicit dependencies, and data source lookups"
+  tags: [Terraform, references, dependencies, data-sources, expressions, beginner]
+
+state: {}
+
+trigger: |
+  Your Terraform configuration has reference errors:
+
+  ```
+  Error: Cycle: aws_security_group.web, aws_security_group.db
+
+  Error: Unsupported attribute
+
+    on main.tf line 25:
+    25:   vpc_id = aws_vpc.main.vpc_id
+
+  A managed resource "aws_vpc" "main" has not been declared in the
+  root module.
+  ```
+
+  Your configuration:
+
+  ```hcl
+  resource "aws_security_group" "web" {
+    ingress {
+      from_port       = 443
+      to_port         = 443
+      security_groups = [aws_security_group.db.id]
+    }
+  }
+
+  resource "aws_security_group" "db" {
+    ingress {
+      from_port       = 5432
+      to_port         = 5432
+      security_groups = [aws_security_group.web.id]
+    }
+  }
+
+  resource "aws_subnet" "public" {
+    vpc_id = aws_vpc.main.vpc_id
+  }
+  ```
+
+  The VPC already exists in AWS (created by another team) — you need
+  to reference it, not create it.
+
+  Task: Explain Terraform resource references, implicit vs explicit
+  dependencies, circular dependency detection and resolution, data
+  sources for reading existing infrastructure, and expression syntax
+  for accessing resource attributes.
+
+assertions:
+  - type: llm_judge
+    criteria: "Resource references and dependencies are explained — implicit dependency: when resource A references resource B's attribute (aws_security_group.web.id), Terraform automatically creates A after B. Explicit dependency: depends_on = [aws_security_group.web] when there's no attribute reference but order matters. Circular dependency: A references B and B references A — Terraform can't determine creation order. Fix: break the cycle by using aws_security_group_rule as separate resources instead of inline ingress blocks, or use depends_on with one direction only"
+    weight: 0.35
+    description: "Dependencies"
+  - type: llm_judge
+    criteria: "Data sources are explained — data sources read existing infrastructure without managing it. data 'aws_vpc' 'main' { filter { name = 'tag:Name', values = ['production'] } } reads the VPC. Reference: data.aws_vpc.main.id. Use data sources when: resource exists outside your Terraform config, managed by another team/state, or pre-existing infrastructure. Common data sources: aws_ami (find latest AMI), aws_vpc, aws_subnet, aws_caller_identity (current AWS account), aws_region. Data sources are refreshed on every plan"
+    weight: 0.35
+    description: "Data sources"
+  - type: llm_judge
+    criteria: "Expression syntax is covered — resource attributes: aws_instance.web.id, aws_instance.web.public_ip. With count: aws_instance.web[0].id or aws_instance.web[*].id (splat). With for_each: aws_instance.web['key'].id. Module outputs: module.vpc.vpc_id. Data sources: data.aws_vpc.main.id. Local values: local.common_tags. Built-in functions: lookup(), element(), concat(), join(). Conditional: condition ? true_val : false_val. For expressions: [for s in var.list : upper(s)]"
+    weight: 0.30
+    description: "Expression syntax"

package/courses/terraform-infrastructure-setup/scenarios/level-1/state-file-basics.yaml

@@ -0,0 +1,73 @@
+meta:
+  id: state-file-basics
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Understand Terraform state — diagnose state file corruption, lock conflicts, state drift, and local vs remote state tradeoffs"
+  tags: [Terraform, state, tfstate, locking, drift, beginner]
+
+state: {}
+
+trigger: |
+  Your colleague runs `terraform plan` and gets unexpected results:
+
+  ```
+  $ terraform plan
+
+  Note: Objects have changed outside of Terraform
+
+  Terraform detected the following changes made outside of Terraform
+  since the last "terraform apply":
+
+    # aws_instance.web has been changed
+    ~ resource "aws_instance" "web" {
+        ~ instance_type = "t3.micro" -> "t3.large"
+          # (10 unchanged attributes hidden)
+      }
+
+  Terraform will perform the following actions:
+
+    # aws_instance.web will be updated in-place
+    ~ resource "aws_instance" "web" {
+        ~ instance_type = "t3.large" -> "t3.micro"
+      }
+
+  Plan: 0 to add, 1 to change, 0 to destroy.
+  ```
+
+  Someone changed the instance type in the AWS console from t3.micro
+  to t3.large. Terraform wants to revert it back to match the code.
+
+  Also, when two people run terraform at the same time:
+  ```
+  Error: Error acquiring the state lock
+
+  Error message: ConditionalCheckFailedException: The conditional
+  request failed
+  Lock Info:
+    ID:        12345-abcde
+    Path:      my-bucket/prod/terraform.tfstate
+    Operation: OperationTypeApply
+    Who:       colleague@laptop
+    Version:   1.7.0
+    Created:   2024-01-15 10:30:00 UTC
+  ```
+
+  Task: Explain Terraform state fundamentals, what the state file
+  contains and why it exists, state drift detection and resolution,
+  state locking (why it matters, how it works with DynamoDB), and
+  local vs remote state.
+
+assertions:
+  - type: llm_judge
+    criteria: "State fundamentals are explained — terraform.tfstate is a JSON file mapping configuration to real infrastructure IDs. It tracks: resource IDs, attribute values, dependencies, metadata. Why state exists: (1) map config to real resources (Terraform needs to know which aws_instance.web is vpc-abc123), (2) track metadata (dependencies), (3) performance (cache attribute values instead of querying APIs every time). State is the source of truth for what Terraform manages. Drift: when real infrastructure differs from state, detected during plan/apply refresh"
+    weight: 0.35
+    description: "State fundamentals"
+  - type: llm_judge
+    criteria: "Drift detection and resolution are covered — Terraform refreshes state before plan (compares real infrastructure to state). Drift detected: plan shows changes to revert. Options: (1) apply to revert to code (desired state wins), (2) update code to match reality (if the manual change was intentional), (3) terraform apply -refresh-only to update state without changing infrastructure. Best practice: all changes through Terraform, never manual. If manual changes are needed: update the .tf files to match, then plan to confirm no changes"
+    weight: 0.35
+    description: "Drift resolution"
+  - type: llm_judge
+    criteria: "Locking and remote state are practical — local state: terraform.tfstate in working directory. Problem: not shared, no locking, easy to lose. Remote state: store in S3, GCS, Azure Blob, Terraform Cloud. S3 backend with DynamoDB: S3 stores state file, DynamoDB provides locking (prevents concurrent modifications). Lock error: someone else is running terraform. Fix: wait for them to finish, or terraform force-unlock <ID> (dangerous, only if lock is stale). Never commit terraform.tfstate to git (contains secrets). Add to .gitignore"
+    weight: 0.30
+    description: "Locking and remote"

package/courses/terraform-infrastructure-setup/scenarios/level-1/terraform-fmt-validate.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: terraform-fmt-validate
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Use terraform fmt and validate — enforce consistent formatting, catch configuration errors before plan, and set up pre-commit hooks"
+  tags: [Terraform, fmt, validate, formatting, pre-commit, beginner]
+
+state: {}
+
+trigger: |
+  Your team's Terraform codebase is a formatting mess. Every developer
+  uses different indentation, alignment, and spacing. Code reviews are
+  full of style nitpicks instead of substance:
+
+  ```hcl
+  resource "aws_instance" "web" {
+      ami = "ami-0c55b159cbfafe1f0"
+    instance_type="t3.micro"
+        tags={
+      Name ="web-server"
+    Environment= "prod"
+        }
+  }
+
+  variable "region" {
+  type=string
+    default ="us-east-1"
+  }
+  ```
+
+  Additionally, a developer pushed this broken config that wasn't caught
+  until CI ran terraform plan (wasting 10 minutes):
+
+  ```hcl
+  resource "aws_s3_bucket" "data" {
+    bucket = var.bucket_name
+    acl    = "private"  # acl argument removed in AWS provider v4+
+  }
+  ```
+
+  Task: Explain terraform fmt (auto-formatting), terraform validate
+  (configuration checking), how to enforce both in CI/CD and pre-commit
+  hooks, and the difference between validate and plan for error catching.
+
+assertions:
+  - type: llm_judge
+    criteria: "terraform fmt is explained — terraform fmt rewrites .tf files to canonical format (2-space indent, aligned equals signs, consistent spacing). terraform fmt -check: returns non-zero exit code if files need formatting (for CI). terraform fmt -recursive: formats all .tf files in subdirectories. terraform fmt -diff: shows the formatting changes. The example code would be auto-fixed to consistent 2-space indentation with aligned = signs. Best practice: run fmt before every commit"
+    weight: 0.35
+    description: "Formatting"
+  - type: llm_judge
+    criteria: "terraform validate is explained with its limitations — validate checks: syntax errors, invalid argument names, type mismatches, missing required arguments, invalid resource references. validate does NOT check: cloud API validity (wrong AMI ID), permissions, resource existence, provider-specific logic. The acl argument error: validate might not catch this because it depends on provider version schema. Plan catches more because it initializes providers and checks against their schemas. Workflow: fmt → validate → plan → apply. validate is fast (no API calls), plan is thorough (makes API calls)"
+    weight: 0.35
+    description: "Validation"
+  - type: llm_judge
+    criteria: "CI/CD and pre-commit integration are practical — pre-commit hook: use pre-commit framework with terraform_fmt and terraform_validate hooks. CI pipeline: (1) terraform fmt -check -recursive (fail if unformatted), (2) terraform init -backend=false (for validate only), (3) terraform validate, (4) terraform plan. This catches formatting issues before PR, validation errors without cloud access, and full errors with plan. Tools: pre-commit-terraform hooks, GitHub Actions, GitLab CI. TFLint for additional linting beyond validate (naming conventions, deprecated syntax, best practices)"
+    weight: 0.30
+    description: "CI integration"

package/courses/terraform-infrastructure-setup/scenarios/level-1/variable-and-output-errors.yaml

@@ -0,0 +1,78 @@
+meta:
+  id: variable-and-output-errors
+  level: 1
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Debug variable and output errors — fix type mismatches, missing required variables, default values, and output reference issues"
+  tags: [Terraform, variables, outputs, types, validation, beginner]
+
+state: {}
+
+trigger: |
+  You run `terraform plan` and hit these errors:
+
+  ```
+  Error: No value for required variable
+
+    on variables.tf line 1:
+     1: variable "environment" {
+
+  The root module input variable "environment" is not set, and has
+  no default value.
+
+  Error: Invalid value for variable
+
+    on variables.tf line 7:
+     7: variable "instance_count" {
+
+  This variable does not accept the value "three". Expected type number.
+
+  Error: Unsupported attribute
+
+    on outputs.tf line 3:
+     3:   value = aws_instance.web.public_dns
+  ```
+
+  Your files:
+
+  variables.tf:
+  ```hcl
+  variable "environment" {
+    type        = string
+    description = "Deployment environment"
+  }
+
+  variable "instance_count" {
+    type    = number
+    default = 1
+  }
+
+  variable "allowed_cidrs" {
+    type    = list(string)
+    default = ["0.0.0.0/0"]
+  }
+  ```
+
+  terraform.tfvars:
+  ```hcl
+  instance_count = "three"
+  ```
+
+  Task: Explain Terraform variables (types, defaults, validation),
+  how to pass values (tfvars, CLI, env vars, auto.tfvars), output
+  values and their uses, type system (string, number, bool, list,
+  map, object, tuple), and common variable/output errors.
+
+assertions:
+  - type: llm_judge
+    criteria: "Variable system is explained — types: string, number, bool (primitives), list(type), set(type), map(type), object({key=type}), tuple([types]) (complex). Required vs optional: variables without default are required. Validation blocks: variable 'env' { validation { condition = contains(['dev','prod'], var.env), error_message = '...' } }. Sensitive = true: hides value in plan output. Nullable = false: disallows null values. The errors: (1) environment has no default and no value provided, (2) instance_count expects number but got string 'three', (3) public_dns might not exist if count = 0 or resource uses for_each"
+    weight: 0.35
+    description: "Variable system"
+  - type: llm_judge
+    criteria: "Value passing methods are covered in precedence order — (1) -var flag on CLI: terraform plan -var='environment=prod'. (2) -var-file flag: terraform plan -var-file=prod.tfvars. (3) terraform.tfvars or terraform.tfvars.json (auto-loaded). (4) *.auto.tfvars files (auto-loaded, alphabetical order). (5) TF_VAR_name environment variables: TF_VAR_environment=prod. Later sources override earlier ones. Best practice: use terraform.tfvars for defaults, environment-specific .tfvars files for overrides, never commit secrets in tfvars"
+    weight: 0.35
+    description: "Value passing"
+  - type: llm_judge
+    criteria: "Outputs are explained — output blocks export values after apply. Uses: display information, pass data between modules (module.vpc.vpc_id), feed into other tools. Attributes: value (required), description, sensitive, depends_on. terraform output command to retrieve values. terraform output -json for machine-readable format. Common errors: referencing attribute that doesn't exist on resource type, referencing resource with count/for_each without index (aws_instance.web[0].public_dns or aws_instance.web[*].public_dns)"
+    weight: 0.30
+    description: "Outputs"

package/courses/terraform-infrastructure-setup/scenarios/level-2/count-vs-for-each.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: count-vs-for-each
+  level: 2
+  course: terraform-infrastructure-setup
+  type: output
+  description: "Choose between count and for_each — understand index-based vs key-based resources, migration pitfalls, and when to use each"
+  tags: [Terraform, count, for_each, meta-arguments, iteration, intermediate]
+
+state: {}
+
+trigger: |
+  Your infrastructure uses count for EC2 instances:
+
+  ```hcl
+  variable "instances" {
+    default = ["web-1", "web-2", "web-3"]
+  }
+
+  resource "aws_instance" "web" {
+    count         = length(var.instances)
+    ami           = "ami-0c55b159cbfafe1f0"
+    instance_type = "t3.micro"
+    tags = {
+      Name = var.instances[count.index]
+    }
+  }
+  ```
+
+  A developer removes "web-2" from the list. Terraform plan shows:
+
+  ```
+  # aws_instance.web[1] will be updated in-place (web-3 → web-2 tags)
+  # aws_instance.web[2] will be destroyed
+
+  Plan: 0 to add, 1 to change, 1 to destroy.
+  ```
+
+  The web-3 instance gets renamed to web-2, and the real web-3 instance
+  gets destroyed! This is the wrong behavior — you wanted to remove
+  web-2, not web-3.
+
+  Task: Explain count vs for_each, why count causes index shift problems,
+  how for_each solves this with stable keys, how to migrate from count
+  to for_each safely, and when to use each approach.
+
+assertions:
+  - type: llm_judge
+    criteria: "Count problems are explained — count uses numeric indices: web[0], web[1], web[2]. Removing a middle element shifts all subsequent indices. Removing 'web-2' (index 1) makes 'web-3' become index 1 — Terraform sees index 1 changed and index 2 disappeared. Result: wrong instance modified, wrong instance destroyed. This is a fundamental limitation of count with lists that can have elements removed. Count is safe only when: (1) all elements are identical, (2) you only add/remove from the end, (3) the count is a simple number not derived from a list"
+    weight: 0.35
+    description: "Count problems"
+  - type: llm_judge
+    criteria: "for_each solution is explained — for_each uses stable map keys: web['web-1'], web['web-2'], web['web-3']. Removing 'web-2' only affects web['web-2'] — other instances untouched. Implementation: resource 'aws_instance' 'web' { for_each = toset(var.instances), tags = { Name = each.key } } or with a map: for_each = var.instances_map, using each.key and each.value. for_each accepts: set(string) or map. Not list — use toset() to convert. Access instances: aws_instance.web['web-1'].id"
+    weight: 0.35
+    description: "for_each solution"
+  - type: llm_judge
+    criteria: "Migration strategy is covered — migrating count to for_each changes resource addresses (web[0] → web['web-1']). Without state management, Terraform destroys and recreates all instances. Safe migration: (1) use moved blocks (Terraform 1.1+): moved { from = aws_instance.web[0], to = aws_instance.web['web-1'] }. (2) Or use terraform state mv: terraform state mv 'aws_instance.web[0]' 'aws_instance.web[\"web-1\"]'. Verify with plan — should show no changes. When to use count: simple numeric repetition (create N identical resources). When to use for_each: named resources, resources that may be individually added/removed"
+    weight: 0.30
+    description: "Migration"