Quiz results are saved to your browser's local storage and will persist between sessions.
Not Terraform mechanics — method. How to order hypotheses, and why a green apply is evidence of an API call succeeding rather than evidence of a working system.
Two different Terraform learners hit the same unfamiliar syntax. One says 'I never knew that' after seeing the answer; the other says 'I should have thought of that.' What's the practical teaching implication of this difference?
A knowledge-gap-dominant profile means genuinely new mechanics (like HCL-specific behaviors) are more efficiently closed by direct explanation than by extended discovery-based questioning, since the person has no prior exposure to draw on. A recognition-gap-dominant profile, by contrast, benefits more from Socratic prompting since the underlying pieces are already known — the gap is in noticing when to apply them.
When a real, unexpected Terraform error appears with more than one plausible cause, what's the better debugging approach — testing hypotheses in order with direct evidence, or reading through the whole codebase first to find the bug?
Real incident: environment/terminal mismatch was ruled out via pgrep + consul kv get (fast, direct). Wrong workspace was ruled out via terraformworkspaceshow (fast, direct). Only once both cheap hypotheses were exhausted did reading the actual code pay off — a hardcoded, non-parameterized path sitting right next to a correctly parameterized one. Cheap checks first, code review once those are exhausted, is generally faster than either extreme alone.
terraform apply finishes with no errors and prints a Kubernetes namespace name as an output. Is that sufficient proof the namespace actually exists and is healthy on the real cluster?
A helm_release can report "created but has a failed status" — Terraform successfully told Kubernetes what to do, but that doesn't mean the workload came up healthy. kubectl reading the same live cluster independently is stronger evidence than trusting Terraform's own state or apply log alone.
A verification script checks GKE cluster status via gcloud, checks node pool existence, and separately checks kubectl get nodes for Ready status. Why check all three instead of just confirming the cluster status is RUNNING?
This happened for real: gcloud container clusters describe reported RUNNING, but the node pool had been destroyed independently (e.g. during a machine-type change or an interrupted apply), leaving zero schedulable capacity. A single high-level status check would have missed this entirely — independent checks at each layer (cluster, node pool, node readiness, namespace, workload) catch failures a single check can't.