Core Terraform workflow practice questions

Provider installation is one of terraform init's core jobs. Terraform reads the required_providers block, selects versions that satisfy the constraints, downloads the plugins, and records the selections in the dependency lock file.

Providers are executable plugins that Terraform Core does not ship with, so they must be fetched before any other command can use them. init performs that download into the local .terraform directory and writes .terraform.lock.hcl so future runs select identical versions. It does not publish anything, does not create infrastructure, and does not test credentials - those misconceptions confuse init with apply or with provider development workflows.

1. Declare providers and version constraints in the required_providers block.
2. Run terraform init to download matching provider plugins into .terraform.
3. Check the generated .terraform.lock.hcl into version control so teammates get the same versions.

Exam tip: terraform init downloads and locks provider plugins; it never touches real infrastructure.

terraform validate is a static check of the configuration in the current working directory. It verifies syntax and internal consistency - valid block structure, known argument names, and correct reference types - using provider schemas installed by init.

validate is deliberately offline: it needs no cloud credentials and makes no remote API calls, which makes it fast and safe to run in CI on every commit. It cannot detect drift because it never looks at state or real infrastructure, it cannot apply anything, and it does not reformat files. Its scope is purely whether the configuration itself is well-formed and coherent.

1. Run terraform init once so provider schemas are available locally.
2. Run terraform validate to check syntax and internal consistency.
3. Fix any reported errors, then proceed to terraform plan.

Exam tip: validate is an offline correctness check of the configuration - no credentials, no state, no infrastructure.

terraform plan is the preview step of the core workflow. It refreshes its in-memory view of state, compares the desired configuration with the recorded state, and prints the set of create, update, and destroy actions that an apply would perform.

The safety of plan comes from being read-only with respect to infrastructure: it may query provider APIs to read current attributes, but it never issues create, update, or delete calls. That lets teams run plan freely against production to review pending changes. It is not offline (it reads state and providers), it does not lock infrastructure, and it certainly does not apply-then-rollback.

1. Edit the configuration to describe the desired infrastructure.
2. Run terraform plan and read the proposed actions carefully.
3. Only after review, run terraform apply to execute the changes.

Exam tip: plan is a read-only preview - it can query providers but never changes infrastructure.

Plan output uses action symbols: + for create, - for destroy, ~ for update in place, and -/+ for replace (destroy then create). Reading these symbols correctly is essential to reviewing a plan before approving it.

The ~ prefix specifically means Terraform can achieve the desired change by modifying the existing remote object - for example changing a tag or an instance's monitoring setting - so the object keeps its identity. This is very different from -/+, which means the change forces replacement and the object will be destroyed and recreated, potentially causing downtime or data loss. Distinguishing the two is a key review skill.

1. Run terraform plan after editing configuration.
2. Scan the action symbols: + create, ~ update in place, - destroy, -/+ replace.
3. Pay special attention to -/+ lines and the 'forces replacement' annotations before applying.

Exam tip: ~ means update in place; -/+ means destroy and recreate.

Some resource arguments are immutable at the provider API level. When such an argument changes, Terraform plans a replacement: destroy the existing object, then create a new one. Plan output marks this with -/+ and annotates the specific argument with 'forces replacement'.

An EC2 instance's AMI cannot be changed on a running instance, so the AWS provider declares ami as a replacement-forcing argument. On apply, Terraform will destroy the current instance and create a replacement booted from the new AMI. Reviewers must catch this in the plan because replacement can mean downtime and loss of instance-local data - which is exactly why plan surfaces the reason next to the changed argument.

1. Run terraform plan and look for -/+ prefixes in the output.
2. Find the argument annotated with 'forces replacement' to see what triggered it.
3. Decide whether replacement is acceptable (or mitigate with lifecycle settings) before running apply.

Exam tip: 'forces replacement' in a plan means apply will destroy and recreate the resource, not update it.

terraform init is not a one-time command. It must be re-run whenever the working directory's dependencies change: a new provider is required, a new module is added or a module source changes, or the backend configuration changes.

Adding random_pet makes the configuration depend on the hashicorp/random provider, which was never downloaded during the original init. Re-running terraform init resolves the new requirement, downloads the plugin, and updates the dependency lock file with the selected version. The other options either target the wrong subsystem (backend) or are destructive (deleting state).

1. Add the new resource and, ideally, declare the provider in required_providers.
2. Run terraform init; it downloads only what is newly required.
3. Commit the updated .terraform.lock.hcl and re-run terraform plan.

Exam tip: Re-run terraform init any time you add a provider, add or change a module, or change the backend.