Terraform Interview Questions - Practice with Instant Scoring

Move state to a shared remote backend such as an appropriately configured S3 backend or HCP Terraform. Enable supported state locking to prevent concurrent modifications and restrict state access through IAM or equivalent controls. Use encryption, versioning or recovery mechanisms, and separate state boundaries for independent environments.

First verify that no Terraform operation is still running against the affected state. Investigate the backend and confirm that the lock is stale before using terraform force-unlock with the correct lock ID. Never force-unlock an active operation because concurrent writes may corrupt state or produce inconsistent infrastructure.

Inspect the plan to identify which changed attribute requires replacement and whether it is immutable in the provider. Check configuration changes, provider upgrades, state mappings, and external infrastructure modifications. Avoid applying until the impact is understood; consider configuration corrections, state moves, or migration strategies that preserve data.

ignore_changes tells Terraform to disregard configured attribute differences during update planning for existing resources. It is useful when another authorized system controls selected attributes, such as externally managed tags. Overusing it can conceal configuration drift and prevent Terraform from correcting unintended changes.

count identifies instances using numeric indexes such as resource.server[0] and resource.server[1]. Removing an earlier list element shifts later values into different indexes, potentially causing updates or replacements. Use for_each with stable keys when resource identity should follow a server name rather than its list position.

Create focused modules with explicit input variables, output contracts, and documented provider requirements. Keep environment-specific values in root configurations rather than hardcoding them inside modules. Version modules, expose only necessary customization, and avoid tightly coupling unrelated infrastructure components.

Multi-account configurations require explicit credential boundaries, provider aliases, and carefully scoped IAM permissions. Cross-account resource dependencies and state ownership must be designed to avoid accidental changes in the wrong account. Use role assumption, separate deployment identities, and independent state where appropriate.

Use separate root configurations or carefully managed workspaces with isolated state and environment-specific variables. Apply distinct cloud credentials, access policies, and deployment approvals for production. Validate the selected backend, workspace, account, and plan before allowing an apply operation.

A moved block declares an address migration in configuration so Terraform can recognize resource renames during planning. terraform state mv directly changes resource address mappings in state. Moved blocks are preferable for reviewable, repeatable module refactoring, while direct state operations require careful coordination.

Configure the S3 backend with the appropriate bucket, state key, region, access permissions, and locking strategy. Run terraform init -migrate-state and follow the migration prompts after taking a verified backup. Confirm that the remote state contains the expected resource mappings and that subsequent plans do not propose unintended changes.

Mark sensitive inputs and outputs appropriately to reduce accidental disclosure in CLI output. Remember that sensitive values can still be stored in state and plan files, so protect backend access and encryption. Prefer short-lived credentials, secret managers, and supported ephemeral or write-only mechanisms when available.

Run formatting, validation, security checks, and terraform plan for every proposed infrastructure change. Publish the plan for review and require approval before production deployment. Use short-lived cloud credentials, restricted backend permissions, state locking, and serialized apply operations. Apply a saved plan when appropriate to ensure the reviewed changes match the deployment.

A fresh apply recalculates the plan, so changed configuration, variables, provider selections, or infrastructure state may produce different actions. Saving a plan with terraform plan -out and applying that file preserves the reviewed operation set. Saved plans contain potentially sensitive information and must be secured and used against the intended state.

Preconditions validate assumptions before relevant resource operations, while postconditions verify conditions after resource evaluation. Check blocks support assertions about infrastructure health and configuration expectations. Failed preconditions or postconditions can block operations, whereas failed check assertions generally produce warnings rather than stopping the run.

Use policy-as-code tooling such as Sentinel, OPA, or suitable infrastructure security scanners in the delivery pipeline. Evaluate Terraform configuration or plan data against organizational security rules before applying changes. Combine policy checks with cloud IAM restrictions and preventive organization-level controls for stronger enforcement.

Terraform does not automatically roll back all previously completed infrastructure operations when an apply fails. Successfully recorded changes normally remain in state, while partially completed or failed operations require reconciliation. The next plan refreshes managed objects and determines the remaining changes needed to reach the desired configuration.

Terraform represents values as unknown when they depend on information that becomes available only during apply. Trace references and dependencies to identify the resource producing the computed value. Avoid using apply-time unknown values as for_each keys or count expressions, which must be known during planning.

Terraform must know resource instance addresses before it can construct the execution plan. Resource IDs generated during apply cannot reliably determine for_each keys during planning. Use stable configuration-defined keys and place computed IDs in map values instead of keys.

Expose stable outputs from the producing configuration and consume them through an appropriate data source or published service interface. terraform_remote_state can retrieve root outputs when backend access is available, but it also requires access to the state snapshot. Prefer dedicated configuration stores or cloud data sources when consumers should not receive broad state access.

Provisioners introduce imperative operations that are harder for Terraform to model, retry, and track reliably. Their side effects may not be represented accurately in state, complicating drift detection and recovery. Prefer cloud-init, immutable images, configuration management, or dedicated deployment tools for application configuration.

Provision the replacement instance alongside the existing one and validate its health before switching traffic. Use load balancer target registration, rolling deployment strategies, or controlled DNS changes as appropriate. Separate persistent data from disposable compute resources and plan rollback before destroying the old instance.

Measure provider API latency, state refresh time, dependency graph constraints, and resource operation concurrency. Split infrastructure into independently managed state boundaries when ownership and dependencies justify it. Tune parallelism cautiously, reduce unnecessary data lookups, and avoid exceeding provider API rate limits.

Higher parallelism allows more independent operations to execute concurrently but can overwhelm provider APIs or backend services. Cloud rate limits may cause throttling, retries, and increased execution time. Select parallelism based on observed API limits, dependency characteristics, and deployment stability rather than maximizing concurrency.

Enable appropriate backend encryption, access controls, versioning, and recovery capabilities. Maintain a documented recovery process that identifies the correct state version and verifies infrastructure consistency before restoration. Test recovery procedures periodically and protect backups from accidental deletion or unauthorized modification.

Compare module versions for changes to resource addresses, immutable arguments, provider requirements, and default values. Review the plan to distinguish actual infrastructure changes from address refactoring. Use moved blocks for compatible address migrations and test module upgrades in a non-production environment before rollout.

Establish reusable versioned modules, clear infrastructure ownership, isolated state boundaries, and standardized provider configurations. Use federated identities, least-privilege permissions, encrypted remote state, locking, and policy-as-code enforcement. Automate validation, security scanning, reviewed plans, approval gates, and controlled applies through CI/CD. Add drift monitoring, audit trails, cost visibility, disaster recovery procedures, and module lifecycle governance.