3.4. Reflection Checkpoint

Key Takeaways

• The core loop is write → init → plan → apply (with destroy to tear down); init runs at setup and when dependencies change, not every iteration.
• fmt standardizes style and validate checks syntax/internal consistency — both are offline and neither guarantees a successful apply.
• plan is read-only on infrastructure and previews the diff; saving a plan (-out) lets apply enact exactly what you reviewed with no prompt.
• apply is the only command that changes real infrastructure and it updates state; destroy reverses creation in reverse-dependency order, scoped to managed resources.

Connecting Forward

You now know the commands; Phase 4 covers the language you feed them. We'll dig into the configuration itself — resources and data sources, references and dependencies, variables and outputs, complex types and functions, and the newer validation and sensitive-data features that 004 emphasizes. This is the largest objective on the exam.

Self-Check Questions

• Place each command on a spectrum from "changes nothing" to "changes real infrastructure": fmt, validate, plan, apply, destroy. Justify the two endpoints.
• A plan you reviewed looked correct, but a later bare apply did something different. What's the most likely cause, and what practice prevents it?
• Explain why validate can succeed on a configuration that apply then fails to deploy.