Understand IaC concepts practice questions

The same code can be used for any cloud provider without modification.

Why it fails: Terraform, while a cloud-agnostic tool, relies on distinct providers for each cloud platform (e.g., AWS, Azure, GCP). The specific resource types (e.g., `aws_instance`, `azurerm_virtual_machine`) and their attributes within the configuration code are inherently provider-specific. Consequently, porting infrastructure definitions between different cloud ecosystems requires substantial modifications to adapt to each provider's unique API schema and resource definitions.

No learning curve is required; existing knowledge of manual processes applies directly.

Why it fails: Adopting Infrastructure as Code requires a significant learning curve, as it introduces new tools, languages like HashiCorp Configuration Language (HCL), and a fundamentally different declarative paradigm for managing infrastructure. This shift from manual, imperative steps to defining desired end states necessitates understanding concepts such as state management, provider interactions, and module design, which do not directly translate from existing manual processes.

The AMI ID is incorrect.

Why it fails: This statement is incorrect because the provided AMI ID, `ami-0abcdef1234567890`, is syntactically valid and represents a plausible Amazon Machine Image identifier. Terraform validates AMI IDs against AWS's format and existence during the plan phase or at apply time. Assuming this ID refers to an existing, accessible Amazon Linux 2 image, Terraform would successfully locate and use it for instance creation, making this option an invalid reason for failure.

The local-exec provisioner requires network access to the instance.

Why it fails: This statement is incorrect because the `local-exec` provisioner executes commands directly on the machine where Terraform is being run, not on the newly created AWS EC2 instance. Consequently, it does not require network access *to* the instance itself to function. Its operations are confined to the local environment, making network connectivity to the remote resource irrelevant for its execution.

The provisioner runs before the state file is written.

Why it fails: This statement is incorrect. Terraform's resource lifecycle dictates that provisioners, including `local-exec`, execute *after* the associated resource has been successfully created in the cloud provider. Only *after* the resource is created and any provisioners have run successfully does Terraform write the updated state information, including the resource's attributes, to the state file. Therefore, provisioners run *before* the state file is finalized for that resource, but *after* the resource's creation.

In Terraform, the desired state is described imperatively, meaning you specify the exact commands to create, modify, or delete resources in order.

Why it fails: This statement is incorrect because Terraform operates on a declarative model, not an imperative one. In a declarative approach, users define the *desired end state* of their infrastructure, and Terraform figures out the necessary steps to reach that state. An imperative approach, conversely, would require specifying a precise sequence of commands or scripts to execute, detailing *how* to achieve the state, which is fundamentally different from Terraform's design.

Terraform relies on a mutable infrastructure model, where changes are applied directly to existing resources without destroying and recreating them.

Why it fails: This statement is incorrect as Terraform generally promotes an immutable infrastructure model, particularly for significant changes. While Terraform can perform in-place updates (mutations) on certain resource attributes, the best practice and often the default behavior for substantial configuration changes or updates to core components is to destroy the old resource and provision a new one. This ensures consistency and prevents configuration drift, contrasting with a purely mutable model where resources are continuously modified over their lifespan.

IaC eliminates the need for manual configuration entirely by automatically detecting and fixing all configuration drift without human intervention.

Why it fails: This statement is incorrect because while Infrastructure as Code significantly reduces manual configuration and helps manage configuration drift, it does not eliminate it entirely or automatically fix all drift without human intervention. IaC tools can detect drift by comparing the desired state with the actual state, but remediation often requires an explicit `apply` action or human review. Furthermore, some manual tasks or out-of-band changes might still occur, necessitating periodic reconciliation.

The backend configuration changed after the last apply.

Why it fails: If the backend configuration changed after the last apply, Terraform would typically detect a mismatch or an uninitialized backend. It would likely prompt the user to run 'terraform init -reconfigure' or report an error related to backend access or initialization, such as "Error: Backend configuration changed." It would not usually result in a generic "no state file" error, as Terraform would still know where the state *should* be located, even if it couldn't properly access it.

The state file was manually edited in S3.

Why it fails: Manually editing a remote state file, such as one stored in S3, would most likely lead to state corruption, checksum mismatches, or parsing errors when Terraform attempts to read it. Terraform would typically report an error indicating an invalid or unreadable state file, or a state lock issue if the file was partially modified, rather than stating that no state file exists at all. The file would still physically be present, just malformed.

Another user ran 'terraform apply' concurrently.

Why it fails: Concurrent 'terraform apply' operations, especially with a configured remote backend, are designed to be prevented by state locking mechanisms. If another user were running 'apply', Terraform would typically report a state lock error, indicating that the state is currently in use and cannot be modified. It would not result in an error suggesting the state file itself is entirely absent, as the file would still exist and be accessible, just temporarily locked.

Use a single DynamoDB table but increase the lock timeout

Why it fails: Using a single DynamoDB table for multiple Terraform workspaces means all workspaces will attempt to acquire locks within that same table. Increasing the lock timeout merely prolongs the waiting period for other operations when a lock is held, rather than preventing the contention itself. Since Terraform's DynamoDB backend uses a single lock item per state file (or workspace if configured to share a state file), a single table will still serialize operations across workspaces, leading to bottlenecks and failed applies due to lock conflicts, regardless of the timeout duration.

Remove the backend configuration and use local state with manual locking

Why it fails: Removing the backend configuration forces Terraform to use local state files, which are stored on the individual's machine where `terraform apply` is executed. This approach completely lacks centralization, making it impossible for team members to share state or ensure consistency. Relying on manual locking mechanisms is highly error-prone, susceptible to human forgetfulness, and offers no robust protection against concurrent operations, inevitably leading to state corruption and resource conflicts in a collaborative environment.

Disable locking to allow parallel operations

Why it fails: Disabling state locking altogether, while seemingly allowing parallel operations, introduces severe risks of state corruption and resource conflicts. Without a robust locking mechanism, multiple `terraform apply` processes could simultaneously attempt to modify the same remote state file or provision the same infrastructure resources. This concurrency without coordination leads to race conditions, partial updates, overwritten state, and ultimately, an inconsistent and unmanageable infrastructure state, making it an unacceptable practice for any shared or production environment.

Store Terraform state in a shared S3 bucket with DynamoDB locking, and have each team member apply their own changes locally after review.

Why it fails: Storing Terraform state in an S3 bucket with DynamoDB locking effectively manages concurrent access to the state file, but allowing team members to apply changes locally after review still introduces significant risk of configuration drift. This approach lacks centralized enforcement, meaning unreviewed or incorrect changes can still be applied, and it does not prevent manual out-of-band modifications to resources, making drift detection and prevention difficult.

Use Terraform workspaces to manage environments and enforce that all changes go through version-controlled Terraform configs, disabling direct console changes via IAM policies.

Why it fails: While Terraform workspaces are excellent for isolating state files across different environments (e.g., dev, staging, prod) within a single configuration, they do not inherently prevent configuration drift. Workspaces manage distinct state files, but they do not enforce *how* changes are applied to those states. Disabling direct console changes via IAM policies is a crucial security measure, but it's an external control and doesn't prevent an authorized user from applying an unreviewed or incorrect Terraform configuration, nor does it detect drift caused by other automated processes.

Assign each environment to a different Terraform provider alias and use manual planning to ensure correctness.

Why it fails: Terraform provider aliases are designed to manage multiple configurations for the *same* provider within a single Terraform configuration, such as deploying resources into different AWS accounts from one codebase. They are not a mechanism for isolating distinct environments or preventing configuration drift. Relying on manual planning is insufficient as it is prone to human error, lacks automated enforcement, and cannot proactively detect or prevent out-of-band changes that lead to drift, making it an unreliable strategy for maintaining infrastructure consistency.

Store state locally and use a manual approval process outside of Terraform.

Why it fails: Local state cannot be locked or shared, so concurrent applies corrupt it and it drifts from reality; an external approval step does not enforce review inside Terraform. It is tempting because it appears to add governance, but the correct practice is remote state with CI-driven plan and apply.

Store state locally and use a shared network drive for team access.

Why it fails: A shared network drive gives no locking, so concurrent applies corrupt state and it captures nothing about deployed reality; review and approval happen in version control and CI, not in state storage. Remote backends with state locking exist precisely for team collaboration, which is the scenario this option superficially resembles.

Have each team member run terraform apply from their local machine after informal discussion.

Why it fails: Local applies bypass any review gate and let each engineer's state diverge from the shared remote backend, so the state no longer reflects deployed infrastructure. It is tempting because local runs feel quick, but the correct practice is a CI pipeline with remote state and pull-request approval.

Use a separate Git branch for each environment, each with its own Terraform configuration.

Why it fails: Using a separate Git branch for each environment, each with its own Terraform configuration, quickly leads to significant configuration drift and merge conflicts. Propagating common infrastructure changes or security updates across all environments becomes a complex, error-prone task requiring frequent, difficult merges. This strategy undermines consistency and reusability, making environment management cumbersome and increasing the risk of deployment failures.

Write a single Terraform configuration that uses count and conditional expressions to create resources based on environment variable.

Why it fails: Writing a single, monolithic Terraform configuration that relies heavily on `count` and conditional expressions to differentiate resources by environment severely reduces readability and maintainability. This approach makes the configuration difficult to understand, test, and debug, as all environment-specific logic is intertwined. It increases the likelihood of unintended resource creation or misconfiguration, hindering collaboration and efficient infrastructure management.

Use Terraform workspaces with a single configuration and define all variable values in one .tfvars file.

Why it fails: While Terraform workspaces enable distinct state files for different environments, defining all variable values for every environment within a single `.tfvars` file is highly impractical and error-prone. This method would require complex conditional logic within the `.tfvars` file itself or manual modifications, defeating the purpose of clear environment separation. It complicates variable management and makes it difficult to ensure the correct values are applied to each specific workspace.

The instance type chosen does not support public IP addresses.

Why it fails: The instance type chosen does not support public IP addresses. This statement is incorrect because the ability to assign a public IP address to an instance is primarily a function of its network interface configuration within the Virtual Private Cloud (VPC) and whether the subnet it resides in is public. All standard cloud instance types, regardless of their size or family, are capable of being associated with a public IP address (either an Elastic IP or an automatically assigned public IP) provided the network settings permit it. Therefore, the instance type itself is not a limiting factor for public IP support.

The terraform init command failed and the apply did not actually create resources.

Why it fails: The terraform init command failed and the apply did not actually create resources. This option is incorrect because `terraform init` is a crucial prerequisite step that initializes the working directory, downloads provider plugins, and sets up backend configuration. If `terraform init` were to fail, the subsequent `terraform apply` command would not be able to execute successfully or create any resources at all. The problem statement implies that resources were deployed but inaccessible, which contradicts a scenario where `init` failed and no resources were created.

The subnet is configured as private and does not have a route to the internet.

Why it fails: The subnet is configured as private and does not have a route to the internet. While a private subnet without an internet gateway route would indeed prevent any inbound internet access to the instance, this option is less specific than a security group issue when the problem specifically mentions inability to access via HTTP/HTTPS. If the subnet were truly private, *no* internet traffic, regardless of port, would reach the instance. A security group, however, acts as a virtual firewall that can selectively block specific ports (like 80 and 443) even if the instance has a public IP and resides in a public subnet with a route to the internet.

Remove the DynamoDB table and use local state files to avoid locking issues.

Why it fails: Removing the DynamoDB table eliminates the crucial remote state locking mechanism, which is essential for preventing concurrent modifications to the Terraform state in a team environment. Relying solely on local state files makes collaboration impossible, as it creates a high risk of state corruption and overwrites when multiple team members attempt to apply changes simultaneously. This approach severely undermines the integrity and reliability of infrastructure management.

Configure all team members to use the same workspace so that only one person can apply at a time.

Why it fails: Configuring all team members to use a single workspace fundamentally defeats the purpose of Terraform workspaces, which are designed to provide isolated environments for different stages or features. This approach severely limits team productivity by enforcing serial operations, as only one person can safely apply changes at any given time. It also eliminates the ability to manage distinct infrastructure configurations for development, staging, and production environments within the same backend.

Keep the current setup because the error is harmless and users can retry.

Why it fails: While some transient errors might resolve with a retry, consistently encountering state locking issues indicates a fundamental problem with concurrent operations or backend configuration that should be addressed. Accepting repeated errors and requiring manual retries introduces significant operational friction and diminishes the developer experience. A robust Terraform setup aims for predictable and reliable execution, not one that frequently demands user intervention for expected issues.

Install Terraform on the existing instance, run terraform init and apply directly to manage it, and store state locally. Have team members share the state file via a shared folder.

Why it fails: Storing Terraform state locally on an instance prevents collaborative infrastructure management, as team members cannot access or update a shared source of truth. Sharing state files manually via a shared folder is highly prone to corruption, race conditions, and inconsistent views of the infrastructure, leading to unexpected changes and operational errors. This method lacks state locking and versioning, making it unsuitable for team environments.

Write Terraform configuration from scratch to match the existing instance, but do not import; instead, destroy the old instance and recreate it with Terraform.

Why it fails: Destroying an existing production EC2 instance and recreating it from scratch using Terraform, rather than importing it, would cause significant downtime and potential data loss for any services running on that instance. The `terraform import` command is specifically designed to bring existing infrastructure under Terraform management non-disruptively, making this approach unnecessarily risky and disruptive to ongoing operations.

Create separate Git branches for each environment (dev, staging, prod) and have each team member work independently on their branch, merging occasionally.

Why it fails: Utilizing separate Git branches for each environment (dev, staging, prod) where team members work independently without consistent merging creates significant configuration drift between environments. This approach eliminates a single source of truth for infrastructure definitions, makes tracking changes difficult, and inevitably leads to complex merge conflicts and inconsistent deployments across the startup's infrastructure.

IaC is only applicable to cloud-based infrastructure.

Why it fails: This statement is incorrect because Infrastructure as Code (IaC) principles and tools are designed to manage infrastructure across various environments, not exclusively cloud-based ones. Many IaC solutions, including Terraform, support providers for on-premises virtualization platforms like VMware vSphere, network devices, and even bare-metal servers, facilitating hybrid cloud strategies. The core benefit of declarative configuration applies universally to any programmable infrastructure, regardless of its hosting location.

IaC eliminates configuration drift entirely.

Why it fails: While Infrastructure as Code significantly mitigates configuration drift by defining desired states and enabling automated reconciliation, it does not entirely eliminate it. Manual, out-of-band changes made directly to infrastructure components can still occur, causing the actual state to diverge from the declared IaC state. Continuous application of IaC configurations and robust change management processes are necessary to detect and correct drift, rather than preventing its possibility altogether.

IaC tools require manual execution of scripts.

Why it fails: This statement is incorrect because IaC tools are specifically designed to integrate seamlessly into automated workflows, such as Continuous Integration/Continuous Deployment (CI/CD) pipelines. While manual execution of IaC commands is possible for development or testing, the true power and efficiency of IaC are realized when its configurations are automatically applied by a system upon code commits or scheduled events. This automation eliminates the need for manual script execution in production environments, ensuring consistency and speed.

Improve SSH key management and use configuration management tools like Ansible to apply changes.

Why it fails: Improving SSH key management and using configuration management tools like Ansible primarily addresses post-provisioning configuration and application deployment, not the declarative provisioning and lifecycle management of the underlying infrastructure itself. While Ansible can configure existing servers, it does not define or manage cloud resources such as virtual machines, networks, or databases from creation to destruction, nor does it inherently enforce version-controlled infrastructure state.

Migrate all applications to containers and use Kubernetes for orchestration.

Why it fails: Migrating applications to containers and orchestrating them with Kubernetes focuses on application deployment, scaling, and runtime management, not the provisioning of the underlying infrastructure. Kubernetes itself requires servers, networking, and storage to operate, which still need to be provisioned and managed. This approach shifts application concerns but leaves the fundamental infrastructure provisioning challenges unaddressed by IaC principles.

Create more detailed runbooks and require peer review for all manual changes.

Why it fails: Creating more detailed runbooks and requiring peer review, while improving documentation and oversight, fundamentally remains a manual process for infrastructure changes. Manual steps are inherently prone to human error, inconsistency, and slow execution, even with stringent review. This approach lacks the automation, idempotency, and state management capabilities essential for scalable, reliable, and rapid infrastructure operations.

Run terraform init, then write Terraform configuration files, then run terraform validate.

Why it fails: `terraform init` is designed to scan existing configuration files to identify and download necessary provider plugins and modules, as well as initialize the backend. Running `init` when no `.tf` files are present means it cannot determine what components to fetch or how to configure the working directory. This will lead to an error indicating no configuration files were found, or an incomplete initialization that lacks essential dependencies.

Write Terraform configuration files, then run terraform validate, then run terraform init.

Why it fails: While configuration files are present, `terraform validate` performs comprehensive checks that extend beyond basic syntax, including verifying provider configurations and module sources. These deeper validations require the provider plugins and module dependencies to be downloaded and the backend initialized by `terraform init`. Running `validate` prematurely will result in errors about missing providers or uninitialized modules because the `.terraform` directory, containing these critical components, has not yet been established.

Run terraform validate, then write Terraform configuration files, then run terraform init.

Why it fails: Attempting to run `terraform validate` before any configuration files are written means there is no code for Terraform to check, resulting in an immediate error. Even if empty files existed, `validate` also performs checks that require provider plugins to be downloaded and the backend initialized by `terraform init`. Therefore, this sequence fails because the necessary configuration and environment setup are entirely absent.

Check current provider versions, then run terraform init to upgrade, then update version constraints, then run terraform plan to validate.

Why it fails: Running `terraform init` before updating provider version constraints means the command will resolve and install the highest allowed provider version based on the *existing* constraints. If new, higher versions are subsequently specified in the configuration, the `init` operation would not have installed the intended target versions. A subsequent `terraform plan` would then operate against the incorrectly installed provider versions, failing to validate the desired upgrade and necessitating another `init`.

Update version constraints, then check current provider versions, then run terraform init to upgrade, then run terraform plan to validate.

Why it fails: Updating provider version constraints without first checking current provider versions is an inefficient and error-prone approach. Without knowing the currently installed versions, or the range of available newer versions, a user might specify an incompatible, non-existent, or overly restrictive version constraint. This lack of foundational context can lead to failed `terraform init` operations or unexpected breaking changes, making the upgrade process less predictable and more difficult to troubleshoot.

Check current provider versions, then update version constraints, then run terraform plan to validate, then run terraform init to upgrade.

Why it fails: Executing `terraform plan` *before* running `terraform init` (after updating version constraints) is fundamentally incorrect. The `plan` command relies on the locally installed provider binaries to generate an execution plan reflecting the current configuration. If `init` has not yet been executed to download and install the newly specified provider versions, `plan` will operate against the *previously installed* (older) provider versions. This results in a plan that does not reflect the desired state with the upgraded providers, rendering the validation step ineffective and misleading.

terraform init: Applies changes to infrastructure

Why it fails: Incorrect — this describes terraform apply, not init.

terraform plan: Destroys all resources

Why it fails: Incorrect — this describes terraform destroy, not plan.

Workspaces: Store and share remote state files for collaboration.

Why it fails: This statement is incorrect because while Terraform Cloud Workspaces *utilize* remote state to store and share state files, their primary purpose extends beyond mere storage and collaboration. The fundamental role of a workspace is to encapsulate and manage a distinct infrastructure environment, complete with its own isolated state, variables, and run history. Remote state itself is the underlying mechanism for storing and sharing, which workspaces leverage for environment separation.

Sentinel: Provide collaborative infrastructure management with separate environments.

Why it fails: This statement incorrectly attributes the functionality of Workspaces to Sentinel. Sentinel's core function is policy enforcement and governance, ensuring that infrastructure changes adhere to predefined rules and standards. It does not provide mechanisms for collaborative infrastructure management or the creation of separate environments; those capabilities are specifically offered by Terraform Cloud Workspaces, which segment state and variables for distinct deployments.

Dynamic provider credentials

Why it fails: Dynamic provider credentials rotate short-lived authentication tokens at runtime; they do not govern whether repeated applies yield identical infrastructure. They are tempting because they harden pipelines against credential leakage, and would be correct when the requirement is eliminating long-lived static secrets from CI/CD.

Modularity

Why it fails: Modularity packages reusable configuration into called modules, but does not itself guarantee identical outcomes across runs; state drift and non-deterministic resources still apply. It is tempting because modules reduce duplication, and would be the right answer if the goal were standardising repeated infrastructure patterns across teams.

Version control

Why it fails: Version control records configuration history but does not reconcile live infrastructure state, so repeated applies can still drift. It is tempting because it underpins collaboration and audit trails, and would be the right answer if the question asked how to track or review changes to Terraform code over time.

Client-server vs agentless

Why it fails: While Terraform generally operates in a client-only mode, interacting directly with cloud provider APIs, and Ansible is agentless, connecting to target nodes via SSH or WinRM, this describes their underlying architectural communication model. This architectural difference, concerning how the tools interact with the infrastructure, is distinct from the fundamental paradigm of how they define and manage changes to that infrastructure, which is the core focus of the question.

Immutable vs mutable

Why it fails: Immutable infrastructure refers to the practice of replacing existing servers or components with new ones whenever a change is needed, rather than modifying them in place, while mutable infrastructure allows for in-place updates. Although Terraform can be used to implement immutable infrastructure patterns (e.g., by provisioning new instances and destroying old ones), and Ansible can manage mutable infrastructure, this concept describes an operational strategy or outcome of infrastructure management, not the inherent language style or core operational paradigm of the tools themselves.

Push vs pull

Why it fails: Push-based configuration management, exemplified by Ansible, involves a central controller initiating connections to target nodes and "pushing" configurations or commands to them. Conversely, pull-based systems have target nodes periodically "pulling" their desired state or configuration from a central server. While Terraform generally operates in a push-like manner (applying changes directly to APIs), this distinction describes the delivery mechanism of configuration, not the fundamental way the infrastructure state is defined or managed by the tool's core language.