Terraform 004 flashcards

Infrastructure as Code (IaC) with Terraform

• IaC defines infrastructure in machine-readable, version-controlled files — the definition files are the source of truth, not the console
• The advantages of IaC patterns: versioning, repeatability, automation, reduced human error, and self-service
• Terraform is declarative: you state the desired end state and Terraform computes the create/change/destroy steps and their order
• Applying the same configuration twice is safe — idempotency means a no-change apply does nothing
• One workflow (write, plan, apply) spans multi-cloud, hybrid cloud, and any API with a provider, because all platform knowledge lives in provider plugins
• The workflow is cloud-agnostic but the configuration is not — resource types are provider-specific and do not port between clouds
• Terraform provisions infrastructure lifecycle (immutable, replace-on-change); Ansible, Chef, and Puppet manage software on existing servers — complementary, not competing

Terraform fundamentals

• Providers are plugins that map resource types to platform API calls; Terraform core makes no cloud API calls itself
• required_providers (inside the terraform block) pins each provider's source and version; hashicorp/aws is shorthand for registry.terraform.io/hashicorp/aws
• terraform init downloads provider plugins into .terraform/providers and records selections in the lock file — providers are never installed during plan or apply
• ~> 5.1 allows 5.x releases from 5.1 upward but never 6.0; ~> 5.1.0 allows only 5.1.x patch releases — the rightmost stated component is the one that may increase
• Commit .terraform.lock.hcl to version control; terraform init -upgrade is the deliberate way to change locked provider versions
• alias creates additional configurations of the same provider; a resource selects one with provider = aws.west, and resources without it use the default unaliased configuration
• version in required_providers constrains the provider plugin; required_version constrains the Terraform CLI — do not swap them
• State exists to map configuration to real resource IDs, store dependency metadata, and cache attributes for performance — it can hold sensitive data in plain text, so protect it and never edit it by hand

Core Terraform workflow

• The core workflow is Write, Plan, Apply — plan previews changes as a diff, apply executes them, and the loop repeats for every change.
• terraform init must run first in any new or cloned directory, and again whenever providers, modules, or the backend configuration change; it is always safe to rerun.
• Init writes .terraform.lock.hcl, which pins provider versions and checksums and belongs in version control; the .terraform directory does not. The lock file covers providers only, never modules.
• terraform validate checks syntax and internal consistency offline — it needs provider schemas from init (use init -backend=false in CI) but never contacts cloud APIs or reads state.
• terraform plan is read-only: it refreshes in memory, compares state to configuration, and proposes actions without modifying infrastructure or the stored state.
• Plan symbols: + create, ~ update in-place, - destroy, -/+ replace (forced when an argument cannot change in place); replacements count as one add plus one destroy.
• terraform plan -out=tfplan saves a binary plan; terraform apply tfplan executes exactly what was reviewed, skips the approval prompt, embeds variable values, and fails if the state has changed since.
• plan -detailed-exitcode returns 2 when changes are pending — the standard CI mechanism for detecting drift.

• terraform apply is the only core-workflow command that changes infrastructure: it plans, waits for you to type yes, executes in dependency order, and records results in state while holding the state lock.
• Apply skips the approval prompt in exactly two cases: -auto-approve, or applying a saved plan file that was already reviewed at plan time.
• A saved plan (plan -out=tfplan, apply tfplan) embeds variable values, is inspected with terraform show, and is rejected as stale if the state changed since it was created.
• Apply performs up to 10 concurrent operations by default; -parallelism=n adjusts the ceiling at runtime but never overrides dependency ordering.
• terraform destroy removes everything in state, prompting like apply and destroying in reverse dependency order; it is an alias for terraform apply -destroy, and terraform plan -destroy previews it.
• -target limits plan/apply/destroy to named resource or module addresses plus their required dependencies — an exceptional-use tool that Terraform warns about, not a routine workflow.
• terraform fmt rewrites .tf and .tfvars files to canonical style; -recursive covers subdirectories, -check exits non-zero on unformatted files for CI, and -diff shows the changes. fmt never validates.
• Pipeline order: fmt -check, init, validate, plan -out, apply the saved plan.

Terraform configuration

• resource blocks create and manage infrastructure; data blocks only read existing infrastructure and never change it.
• Resources are referenced as type.name (aws_instance.web); data sources take the data. prefix (data.aws_ami.ubuntu).
• Referencing another resource's attribute, such as aws_subnet.app.id, creates an implicit dependency that orders operations automatically.
• Variable blocks support type, default, description, sensitive, and validation; a variable with no default is required input.
• Variable precedence from lowest to highest: TF_VAR_ environment variables, terraform.tfvars, terraform.tfvars.json, *.auto.tfvars in lexical order, then -var and -var-file flags.
• Outputs are the only way a parent module reads values from a child module, accessed as module.name.output_name.
• sensitive = true redacts values from CLI output only — variables and outputs are still stored in plaintext in the state file.
• Know the type families: list/set/map are collections of one element type; object and tuple are structural types with per-attribute or per-position types.

• The conditional expression is condition ? true_val : false_val; for expressions build lists with brackets and maps with braces, with an optional if filter.
• Splat (resource[*].attribute) works on count-created lists; for_each-created resources form a map, so use values() or a for expression.
• You cannot write custom functions in Terraform configuration — only built-ins (and provider-published functions) exist; test them in terraform console.
• count takes a number and yields indexed instances; for_each takes a map or set of strings and yields stable, key-addressed instances — never use both on one resource.
• Removing a middle element under count reindexes and recreates later instances; for_each only touches the removed key.
• Implicit dependencies from attribute references are preferred; depends_on is the explicit last resort for dependencies Terraform cannot infer.
• Variable validation, precondition, and postcondition all pair a condition with an error_message and fail the run; postconditions can inspect self.
• sensitive = true redacts CLI output only — state and plan files hold secrets in plaintext, so use Vault for secrets management and lock down state.

Terraform modules

• A module is a container for multiple resources used together; the directory where you run Terraform is the root module, and anything called via a module block is a child module.
• The source argument is required, must be a literal string, and its format selects the install method: local paths start with ./ or ../, registry sources use NAMESPACE/NAME/PROVIDER, and Git, HTTP, S3, and GCS each have their own address forms.
• Module variables are not global: values enter a child only through declared input variables passed in the module block, and leave only through declared outputs read as module.NAME.OUTPUT.
• Module blocks support four meta-arguments — count, for_each, depends_on, and providers — and a module used with count or for_each must not contain its own provider blocks.
• The version argument works only for registry modules; Git sources pin with ?ref= and local paths cannot be versioned at all.
• Use constraint operators to pin versions — ~> allows only rightmost-component increases — because the lock file tracks provider versions, not module versions.
• terraform init installs modules into .terraform/modules; terraform get downloads modules only; and only the -upgrade (or -update) flag moves an installed module to a newer acceptable version.

Terraform state management

• The local backend is the default: state lives in terraform.tfstate in the working directory, with terraform.tfstate.backup as the previous version - workable solo, unshareable for teams.
• State locking is automatic on supporting backends (local, s3, gcs, azurerm, kubernetes, consul, pg, remote); -lock-timeout waits for a lock, -lock=false skips it, and force-unlock LOCK_ID is strictly a last resort.
• The backend block lives inside the terraform block, allows one backend per configuration, and cannot reference variables - every value is a literal or supplied at init.
• Partial configuration with terraform init -backend-config (a file or key=value pairs) keeps secrets and per-environment settings out of version control.
• Changing backends requires re-running terraform init: -migrate-state copies existing state to the new backend, -reconfigure adopts the new config without migrating.
• terraform_remote_state exposes only the producing configuration's root module outputs, and the consumer needs read access to the whole state file.
• Drift is detected by refreshing: terraform plan -refresh-only previews it, terraform apply -refresh-only accepts it into state, and the old terraform refresh command is deprecated.
• terraform taint is deprecated in favor of terraform apply -replace=ADDRESS; state rm forgets a resource without destroying it.

Maintain infrastructure with Terraform

• terraform import ADDRESS ID updates state only and requires the resource block to exist in configuration first - it never generates or edits .tf files.
• Import IDs are provider-specific (instance ID, bucket name, resource path); check the provider docs for each resource type's expected format.
• The import block (Terraform 1.5+) makes import plannable and reviewable, supports for_each for bulk imports, and is the recommended approach in 1.12.
• terraform plan -generate-config-out=FILE writes starter HCL for import targets that have no resource block; the file must not already exist and the output needs review.
• terraform state list shows addresses only; terraform state show ADDRESS shows one resource's attributes; terraform show dumps the whole state or a saved plan; terraform output prints root outputs.
• TF_LOG enables verbose logging at TRACE, DEBUG, INFO, WARN, or ERROR; TRACE is the most verbose, and unrecognized values are treated as TRACE.
• TF_LOG_PATH appends logs to a file but only works when logging is enabled via TF_LOG; TF_LOG_CORE and TF_LOG_PROVIDER scope levels to Terraform core versus provider plugins.
• Verbose logs can include sensitive API payloads - enable them to reproduce an issue, then disable and protect the captured output.

HCP Terraform

• HCP Terraform (formerly Terraform Cloud) is HashiCorp's managed platform: remote runs, remote state with automatic locking, stored variables, and team governance; Terraform Enterprise is the self-hosted version.
• Integration is two steps: terraform login stores an API token in credentials.tfrc.json, and a cloud block (organization + workspaces name or tags) connects the configuration — then terraform init, which can migrate existing local state.
• The cloud block replaces the older remote backend and cannot coexist with a backend block; runs can be triggered CLI-driven, VCS-driven (merge to tracked branch, speculative plans on PRs), or API-driven.
• An HCP Terraform workspace owns state, variables, run history, and permissions — a CLI workspace is only an alternate state file for one configuration. The standard pattern is one workspace per environment; projects group related workspaces for permissions and shared variable sets.
• Workspace variables come as Terraform variables and environment variables; marking one sensitive makes it write-only. Variable sets share values across workspaces, projects, or the whole organization, with the most specific scope winning.
• Execution modes: remote (default, runs on HCP Terraform), local (runs on your machine, state stays remote), and agent (self-hosted agents inside private networks).
• Sentinel policy-as-code evaluates between plan and apply with three enforcement levels — advisory (warn), soft mandatory (overridable block), hard mandatory (no override); run tasks call external services during a run.
• Cost estimation shows the projected monthly cost and delta for AWS, Azure, and GCP resources before apply, and Sentinel policies can enforce limits on it.

Yes — the whole Terraform 004 deck is free and needs no account. Create a free account only if you want to save progress and drill full practice questions and mock exams.