5 questions

Core Workflow & CLI

What is the correct order of the core Terraform workflow when starting a new configuration?

  • a.apply, then plan, then init
  • b.init, then plan, then apply
  • c.plan, then init, then destroy
  • d.validate, then apply, then init

The core workflow is init (initialize the working directory and download providers), plan (preview the changes Terraform will make), then apply (execute those changes). Running init first is required because plan and apply depend on the installed providers and backend configuration.

Core Workflow & CLI

What does the terraform init command do?

  • a.It permanently deletes all managed infrastructure
  • b.It applies the configuration to the target provider immediately
  • c.It initializes the working directory, downloading provider plugins and configuring the backend
  • d.It formats configuration files to the canonical style

terraform init prepares a working directory: it downloads the required provider plugins, initializes the configured backend for state storage, and installs modules. It makes no changes to real infrastructure. Formatting is handled by terraform fmt, and applying changes is done by terraform apply.

Core Workflow & CLI

Why is running terraform plan before terraform apply considered a best practice?

  • a.It shows a preview of the actions Terraform will take so you can review them before making changes
  • b.It is the only way to download provider plugins
  • c.It permanently locks the configuration from further edits
  • d.It uploads your credentials to HashiCorp

terraform plan produces an execution plan describing what will be created, updated, or destroyed, letting you review the impact before applying. This preview reduces the risk of unexpected changes. Provider downloads happen during init, and plan does not lock files or transmit credentials to HashiCorp.

Core Workflow & CLI

Which command safely tears down all resources tracked in the current Terraform state?

  • a.terraform init -upgrade
  • b.terraform fmt
  • c.terraform validate
  • d.terraform destroy

terraform destroy removes all infrastructure managed in the current state, prompting for confirmation first. validate checks configuration syntax and internal consistency, fmt rewrites files to canonical style, and init -upgrade updates providers. Only destroy deprovisions resources.

Core Workflow & CLI

A teammate wants to verify that a configuration is syntactically valid and internally consistent without contacting any provider APIs. Which command fits best?

  • a.terraform apply
  • b.terraform validate
  • c.terraform import
  • d.terraform state rm

terraform validate checks that the configuration is syntactically valid and internally consistent, using only local files, without reaching out to provider APIs or refreshing state. apply makes changes, import brings existing resources under management, and state rm edits state, none of which is a lightweight local validation.

Report