Terraform Associate Practice

Terraform is an infrastructure as code tool that lets you define and manage cloud resources declaratively. It is not a database, web server, or monitoring agent.

Infrastructure as code means defining and provisioning infrastructure through version-controlled configuration files. This makes changes repeatable and auditable.

HCL is the HashiCorp Configuration Language used by Terraform. It is designed to be readable by humans and machines.

A provider is a plugin that translates Terraform configuration into API calls for a specific platform such as AWS, Azure, or GCP.

A resource is an infrastructure object such as a virtual machine, network, or database that Terraform creates and manages.

A data source lets Terraform read information from existing infrastructure without creating or changing it.

terraform plan compares the configuration with current state and shows what will be created, changed, or destroyed without applying it.

terraform apply executes the changes needed to make real infrastructure match the configuration. It should usually follow a plan.

terraform destroy removes the resources managed by the current configuration. It is destructive and should be used carefully.

terraform init prepares the working directory by downloading providers and modules and configuring the backend. It is usually the first command.

terraform validate checks whether configuration is syntactically valid and internally consistent without contacting providers, which helps catch errors before planning or applying changes.

terraform fmt rewrites .tf files using Terraform canonical formatting. It does not change infrastructure or state.

Variables let users pass values into configuration, such as region or instance size. They make modules reusable.

Outputs expose selected values from applied infrastructure, such as IP addresses or endpoint URLs, to users or other modules.

This statement is true. Terraform declares the desired end state, and Terraform figures out how to reach it. This is different from imperative scripts.

Terraform uses HCL, the HashiCorp Configuration Language, to define infrastructure. HCL files usually have .tf extensions.

A provider block tells Terraform which provider plugin to use and includes settings such as region and credentials.

Terraform builds a dependency graph from references between resources and uses it to determine creation and update order.

terraform refresh reads the actual infrastructure and updates the state file without changing resources. Modern versions refresh during plan and apply.

A resource address such as aws_instance.web identifies a resource uniquely so commands like plan, apply, and state can target it.

Terraform state maps configuration to real-world resources. It stores resource metadata and is essential for planning and updates.

State can be stored locally in terraform.tfstate or remotely in a backend such as Terraform Cloud, S3, or Azure Storage.

A backend defines where state is stored and how locking works. Remote backends are important for team collaboration.

State locking prevents two Terraform operations from modifying the same state at the same time, reducing conflicts.

Sensitive values such as passwords can appear in plaintext in state files. You should use secure backends and avoid committing state.

Remote state stores the state file in a shared backend, enabling team collaboration and centralized locking.

terraform state list shows the resource addresses currently tracked in the state file. It is useful for confirming which resources are managed before planning changes.

terraform state show displays the attributes of a specific resource as recorded in state. This is useful when inspecting a single resource without running a plan.

count creates a fixed number of resource instances from one block. for_each is a more flexible alternative.

for_each iterates over a map or set of strings to create resource instances. It is more flexible than count.

depends_on forces Terraform to create one resource before another when the dependency is not automatic.

A lifecycle block includes settings such as create_before_destroy, prevent_destroy, and ignore_changes. These settings control how Terraform replaces and updates resources.

create_before_destroy builds the new resource before removing the old one, which helps reduce downtime during replacement.

Provisioners execute scripts or configuration steps on local or remote machines after a resource is created.

local-exec runs a command on the machine where Terraform runs. remote-exec runs commands on a remote resource.

remote-exec connects to the created resource and runs commands there. local-exec runs on the Terraform host.

This statement is true. State files can store sensitive attribute values, so secure backends and access controls are important.

This statement is false. Not all backends support locking. Backends such as S3 with DynamoDB or Terraform Cloud provide locking.

terraform state list prints resource addresses from state. Other subcommands include show, mv, rm, and pull.

Terraform configuration declares the desired end state. Terraform compares it with real resources to plan changes.

A module is a reusable container of Terraform configuration. Modules can be called from other configurations and the registry.

The root module is the configuration in the working directory where Terraform runs. Child modules are called from it.

Module inputs are variables defined in the child module and set by the calling configuration.

Module outputs expose selected values so the calling configuration can use them, such as endpoint URLs or IDs.

Modules can come from local directories, the Terraform Registry, Git repositories, HTTP URLs, and other sources.

The Terraform Registry is a public repository where users can find and publish reusable providers and modules.

Module versioning uses tags such as v1.0.0 so callers can pin a specific version and receive controlled updates.

Workspaces allow multiple named states for the same configuration, which is useful for environments such as dev and prod.

Terraform Cloud provides remote runs, state storage, variable management, and collaboration features for Terraform. It is used by teams to run infrastructure changes in a controlled way.

A run represents the process of planning and applying changes to infrastructure for a Terraform Cloud workspace.

Terraform Cloud stores variables in workspaces, and they can be marked sensitive so they are hidden after saving.

terraform import attaches an existing real-world resource to a resource block in configuration so Terraform can manage it.

terraform output shows the values of outputs after apply, which is useful for scripts and integrations.

Run triggers in Terraform Cloud start a workspace run when another workspace completes or a source changes.

This statement is true. Modules are designed for reuse across projects and teams, reducing duplicated configuration.

This statement is true. terraform plan -out=plan.tfplan saves a plan that can be applied later with terraform apply plan.tfplan.

This statement is true. Workspaces keep separate state for environments such as development, staging, and production.

This statement is true. Terraform Cloud uses a remote backend for state and provides locking and version history.

terraform init installs providers, downloads modules, and configures the backend. It should be run before plan and apply.

-target limits an operation to a specific resource or module. terraform destroy -target=aws_instance.web removes only that resource.