Select Two (Multi-Select) Questions

All modules must reside in a separate directory outside the root module.

Why it fails: Terraform modules can be sourced from local paths within the same project directory structure, not exclusively from external locations. While remote sources like the Terraform Registry, Git repositories, or S3 buckets are common for shared modules, local modules are frequently used for organizing components within a single configuration. This flexibility allows for better project structure and development workflows without requiring all modules to be physically separate from the root module's directory.

A module should contain only one resource to keep it simple.

Why it fails: A core purpose of Terraform modules is to encapsulate a collection of related resources that together form a logical, reusable component, such as a VPC, a database instance, or an application tier. Limiting a module to a single resource would negate much of its organizational and reusability benefits, leading to an excessive number of trivial modules and increased complexity in the root configuration. Simplicity in modules comes from clear interfaces and well-defined responsibilities, not from a minimal resource count.

Variables are optional in modules if hardcoded values are acceptable.

Why it fails: While Terraform technically allows hardcoded values within a module, doing so severely diminishes the module's reusability and flexibility, which are primary benefits of modularization. Variables provide the essential mechanism for making modules configurable and adaptable to different environments or use cases without modifying the module's source code. Relying on hardcoded values essentially creates a non-reusable, static component, undermining the principles of infrastructure as code and increasing maintenance overhead.

Provisioners can only be used with the 'local-exec' and 'remote-exec' provisioners.

Why it fails: This statement is incorrect because Terraform supports several provisioner types beyond just 'local-exec' and 'remote-exec'. For instance, the 'file' provisioner is used to upload files or directories to a remote resource, while the 'chef' provisioner can configure a resource by running a Chef client. These additional provisioners demonstrate that the scope is not limited to only executing commands.

Provisioners are the primary way to configure resources after creation.

Why it fails: This statement is incorrect because provisioners are not the primary method for configuring resources after creation. Terraform's declarative model prefers to configure resources directly through resource arguments and provider APIs during the `terraform apply` process. For more complex post-creation configuration, dedicated configuration management tools like Ansible, Chef, or Puppet, or even cloud-init scripts, are generally more robust and idempotent solutions than Terraform provisioners.

Provisioners run only once during initial creation by default.

Why it fails: This statement is incorrect; provisioners do not run only once during initial creation by default. By default, provisioners with `when = create` (the implicit default) will execute every time the resource they are attached to is created or re-created, which can happen during updates or changes to the resource's configuration. To control their execution, the `when` argument can be explicitly set to `create`, `destroy`, or `always`, indicating they can run multiple times or under specific conditions.

Use latest version of all modules

Why it fails: Using the latest version of all modules is not a best practice; instead, explicitly pinning module versions is crucial for ensuring consistent and reproducible infrastructure deployments. Relying on "latest" or unpinned versions introduces significant risk, as upstream module updates can introduce breaking changes, unexpected behavior, or security vulnerabilities without warning. Version pinning guarantees that your infrastructure will always be deployed with the exact, tested module code.

Use provisioners for all software installs

Why it fails: Using provisioners for all software installs is generally discouraged and considered an anti-pattern. Terraform provisioners are primarily designed for bootstrapping tasks, such as installing an agent or running initial setup scripts immediately after resource creation, or for cleanup. For comprehensive and ongoing software installation, configuration, and management within provisioned resources, dedicated configuration management tools like Ansible, Chef, or Puppet offer superior idempotency, error handling, and maintainability.

Faster execution of terraform plan and apply.

Why it fails: Terraform modules do not inherently accelerate the `terraform plan` or `terraform apply` operations. While they promote organization, the Terraform graph still needs to be built and evaluated for all resources defined within the module, potentially adding overhead due to module boundaries and variable interpolation. In complex scenarios with many nested modules, the parsing and evaluation phase can even slightly increase execution time rather than decrease it.

Reduction in state file size.

Why it fails: Terraform modules do not reduce the size of the state file; in fact, they often contribute to larger state files. Each resource managed by Terraform, regardless of whether it's defined directly or within a module, has its configuration and attributes recorded in the state file. A module typically aggregates multiple resources, meaning its use will result in a state file containing all those encapsulated resources, potentially increasing its overall size compared to a minimal configuration.

Enhanced security by automatically encrypting state files.

Why it fails: Terraform modules themselves do not provide automatic encryption of state files. State file encryption is a function of the chosen backend (e.g., S3, Azure Blob Storage, Terraform Cloud/Enterprise) and its inherent security features, or external mechanisms. Modules are primarily concerned with resource definition and organization, not the secure storage or transport of the state file, which remains a separate operational concern.

Managing network ACLs

Why it fails: Managing network Access Control Lists (ACLs) is a task inherently suited for Infrastructure as Code (IaC) tools like Terraform. Network ACLs define stateless packet filtering rules at the subnet level, which are declarative infrastructure components. Terraform's providers interact directly with cloud APIs to create, update, and delete these resources, ensuring the network security posture is consistently applied and version-controlled alongside other network infrastructure.

Provisioning a VPC

Why it fails: Provisioning a Virtual Private Cloud (VPC) is a fundamental task for which Terraform is exceptionally well-suited. A VPC represents a logically isolated section of a cloud, defining its IP address range, subnets, and routing tables. Terraform's declarative approach allows users to define the entire network topology as code, enabling the creation, modification, and destruction of this foundational cloud infrastructure in a repeatable and auditable manner.

Creating IAM roles

Why it fails: Creating Identity and Access Management (IAM) roles is a critical infrastructure task that Terraform handles efficiently. IAM roles are cloud-native resources that define permissions for entities to interact with other cloud services. Terraform's cloud provider integrations allow for the declarative definition and management of these security-sensitive resources, ensuring that access policies are consistently applied and version-controlled as part of the overall infrastructure deployment.

Use a remote backend with encryption

Why it fails: While using a remote backend with encryption, such as an S3 bucket with SSE-KMS, is essential for securing the Terraform state file at rest, it does not influence the visibility of sensitive data in the CLI output. The encryption protects the stored state file from unauthorized access but does not prevent variable values from being displayed in plaintext during terraform plan or terraform apply operations. This measure addresses data at rest, not data in transit or display during execution.

Use a data source to fetch secrets at runtime instead of hardcoding

Why it fails: Employing a data source to fetch secrets at runtime, for instance from AWS Secrets Manager, is a robust security practice for avoiding hardcoded credentials. However, fetching a secret via a data source does not automatically mark its value as sensitive for display purposes in the terraform plan output. Unless the specific attribute containing the fetched secret is then passed to a sensitive variable or output, or the resource argument itself is implicitly sensitive, the secret's value may still appear in the plan.

Store variable values in terraform.tfvars file

Why it fails: Storing variable values in a terraform.tfvars file is merely a method for supplying input values to Terraform configurations, offering no inherent security or obfuscation properties. Regardless of whether a variable's value originates from a .tfvars file, environment variables, or the command line, Terraform will display it in the plan output by default. This file type serves as a convenient input mechanism, not a security control for output redaction.

HTTP URL to a zip archive

Why it fails: An HTTP URL directly specifies a static .zip file to download. Terraform simply fetches the archive located at the exact provided URL without any mechanism to interpret or apply semantic versioning. There is no inherent system for version constraint evaluation, as the source points to a fixed, immutable resource rather than a versioned repository. This method offers no flexibility for automatic version selection.

Local file path

Why it fails: A local file path, like `../modules/my-module`, directly references a specific directory on the local filesystem. Terraform loads the module code precisely from that designated path without any versioning interpretation. There is no inherent mechanism to apply semantic version constraints or automatically select different versions, as it's a direct, static reference to a local directory.

Git URL with a branch reference

Why it fails: While Git repositories support version tags, specifying a Git URL with a branch reference (e.g., `git::https://example.com/repo.git?ref=main`) instructs Terraform to clone the *latest commit* on that particular branch. Terraform does not interpret semantic version constraints (like `~> 1.0`) when a branch is explicitly referenced; it simply fetches the head of the specified branch, which is a moving target, not a versioned release.

terraform fmt

Why it fails: terraform fmt is a utility command used to rewrite Terraform configuration files to a canonical format and style. While highly recommended for maintaining consistency and readability across a team's codebase, it does not directly interact with the infrastructure state or define the lifecycle of resources. Therefore, terraform fmt is considered a development aid rather than an integral step in the core workflow of provisioning or managing infrastructure.

terraform validate

Why it fails: terraform validate performs checks on the configuration files to ensure they are syntactically valid and internally consistent, verifying correct attribute names, types, and module usage. While essential for catching errors early in the development cycle, it does not interact with the remote state or propose infrastructure changes. Consequently, terraform validate is considered a preparatory command, distinct from the core workflow steps that involve interacting with the actual infrastructure.

terraform destroy

Why it fails: terraform destroy is a command used to tear down all resources managed by a given Terraform configuration, effectively reversing the provisioning process. While it interacts with infrastructure, it represents a distinct and often irreversible workflow for decommissioning resources, rather than being part of the routine creation and management cycle. The core workflow focuses on bringing infrastructure to a desired state, whereas destroy explicitly removes that infrastructure.

`module.vpc.output`

Why it fails: This reference is syntactically incorrect for accessing a module output. While `module.vpc` correctly identifies an instantiated module named `vpc`, the subsequent `.output` is not a valid placeholder for an output name. Terraform requires the specific name of the output variable, such as `module.vpc.vpc_id`, to retrieve its value. This syntax would result in a parsing error during plan or apply, as `.output` is not a keyword or a valid attribute name in this context.

`data.aws_ami.ubuntu.id`

Why it fails: Although the syntax `data.<TYPE>.<NAME>.<ATTRIBUTE>` is correctly demonstrated here for referencing an attribute of a data source, this option is invalid because data sources are distinct from resources. Data sources merely fetch information about existing infrastructure or external data, they do not manage or create infrastructure themselves. The question specifically asks for valid ways to reference a *resource* attribute, making this a technically correct reference to a data source attribute, but not a resource attribute.

`var.instance_type`

Why it fails: This expression correctly references an input variable named `instance_type`. However, the question specifically asks for ways to reference a *resource attribute*. Variables are used to parameterize configurations and provide dynamic values, but they do not represent attributes of managed infrastructure resources themselves. Therefore, while `var.instance_type` is a valid Terraform expression for accessing a variable, it does not fulfill the requirement of referencing a resource attribute.

Reduced need for monitoring.

Why it fails: While IaC provides consistent infrastructure, it does not diminish the critical need for robust monitoring. Operational monitoring is still essential to detect runtime issues, performance bottlenecks, security incidents, and resource exhaustion that can occur after infrastructure has been provisioned, regardless of how it was deployed.

Elimination of all security vulnerabilities.

Why it fails: IaC helps enforce security best practices by codifying configurations and reducing human error-induced misconfigurations. However, it cannot eliminate all security vulnerabilities, such as zero-day exploits, application-level flaws, or vulnerabilities introduced by third-party dependencies, which require continuous vigilance and other security measures.

Automatic recovery from any infrastructure failure.

Why it fails: IaC defines the desired state of infrastructure, but it does not inherently provide automatic recovery capabilities for runtime failures. While it can be used to re-provision failed components, actual automatic recovery, such as self-healing, failover, or disaster recovery, requires additional architectural patterns and tools like auto-scaling groups, load balancers, or dedicated DR solutions.

Better performance

Why it fails: Immutable infrastructure does not inherently lead to better performance of the deployed applications or underlying resources. Performance is primarily determined by factors like CPU, memory, network bandwidth, and application-level optimizations, not the deployment strategy. While immutability ensures consistency and reliability, it doesn't directly enhance the speed or efficiency at which workloads execute on the provisioned infrastructure.

Faster provisioning

Why it fails: The provisioning speed of infrastructure resources is largely dependent on the cloud provider's API response times and the time required to instantiate virtual machines, containers, or other services. Immutable infrastructure focuses on the deployment and management of applications onto provisioned resources, often using pre-baked images. It does not accelerate the fundamental process of creating the underlying compute, storage, or networking components themselves.

Lower cost

Why it fails: Immutable infrastructure can potentially increase costs rather than reduce them. This paradigm often involves replacing entire instances or environments for updates, leading to more frequent resource creation and destruction cycles. This increased turnover can incur higher billing for compute hours, storage, and network egress, especially if resources are not efficiently de-provisioned or if the build process itself consumes significant resources.

terraform fmt

Why it fails: The `terraform fmt` command is a utility designed to automatically rewrite Terraform configuration files to a canonical format and style. While highly recommended for maintaining code consistency, readability, and collaboration within a team, it is an auxiliary command that does not directly interact with the Terraform state, communicate with cloud providers, or provision infrastructure. Therefore, it is not considered a fundamental step in the core workflow of deploying or managing resources.

terraform console

Why it fails: The `terraform console` command provides an interactive command-line interface for evaluating expressions and inspecting the current state of Terraform variables, outputs, and resources. It serves as a powerful debugging and exploration tool, allowing users to test logic or understand resource attributes dynamically. However, `terraform console` does not perform any infrastructure provisioning, planning, or destruction, thus placing it outside the core workflow steps that directly manage the infrastructure lifecycle.

terraform get

Why it fails: The `terraform get` command is specifically used to download and update modules referenced in the Terraform configuration. While module management is crucial for complex projects, `terraform get` is largely integrated into or superseded by `terraform init` for most modern workflows. It is not considered a standalone core workflow command because `init` comprehensively handles all necessary module and provider downloads as part of its initial setup process, making `get` redundant in typical usage.

Using manual changes to fix minor issues

Why it fails: Directly making manual changes to infrastructure resources outside of Terraform, even for seemingly minor issues, immediately introduces configuration drift. These changes are not reflected in the Terraform state file or configuration, leading to discrepancies between the desired state and the actual infrastructure. Subsequent `terraform apply` operations might then attempt to revert these manual fixes or fail due to unexpected resource states, undermining consistency and making infrastructure management unpredictable.

Allowing multiple team members to run apply simultaneously

Why it fails: Permitting multiple team members to execute `terraform apply` commands concurrently without proper state locking mechanisms creates a high risk of state file corruption and conflicting infrastructure changes. Without a lock, simultaneous operations could attempt to write to the same state file, leading to an inconsistent or corrupted record of the infrastructure. This can result in resources being incorrectly provisioned, modified, or destroyed, severely compromising consistency and operational stability.

State can be manually edited with a text editor without risk.

Why it fails: Manually editing the Terraform state file with a text editor is extremely risky and strongly discouraged. The state file contains sensitive resource IDs, internal checksums, and a specific JSON structure that can be easily corrupted by manual changes. Such corruption can lead to inconsistencies between the state and real-world infrastructure, causing Terraform to misidentify resources, destroy unintended components, or fail during subsequent operations. Instead, use `terraform state` commands for safe state manipulation.

State must be stored in a file named terraform.tfstate.

Why it fails: While `terraform.tfstate` is the default filename for local state, it is not a mandatory requirement for all Terraform deployments. Users can configure a different local state filename using the `terraform init -state=path/to/my.tfstate` command or by specifying a backend configuration. Furthermore, when using remote backends like S3 or Azure Storage, the state is stored externally and may not even reside in a local file with any specific name after initialization, making the default local filename irrelevant.

Configuration drift is accepted

Why it fails: Configuration drift is explicitly rejected and actively prevented in immutable infrastructure paradigms. Instead of allowing changes to accumulate on running instances, any deviation from the desired state necessitates the replacement of the affected resource with a new, correctly configured instance, thereby eliminating the potential for inconsistencies over time.

In-place updates are preferred

Why it fails: In-place updates are fundamentally antithetical to the immutable infrastructure philosophy. Preferring in-place updates introduces the risk of configuration drift, inconsistent environments, and unpredictable behavior, as each update could leave behind artifacts or introduce subtle differences that make debugging and ensuring reliability significantly more challenging.

Generate a long-lived API token and store it as a secret.

Why it fails: Generating a long-lived API token and storing it as a secret is contrary to the fundamental security benefits of OpenID Connect (OIDC). OIDC's primary purpose is to eliminate the need for static, long-lived credentials by providing short-lived, dynamically issued identity tokens. Relying on a long-lived token reintroduces the very security risks OIDC aims to mitigate, such as credential compromise and the burden of secure secret management.

Configure remote backend with static credentials.

Why it fails: Configuring a remote backend with static credentials directly contradicts the security posture that OIDC aims to achieve. The goal of OIDC integration is to replace all forms of static, long-lived credentials, including those used for backend authentication, with ephemeral, dynamically issued tokens. Using static credentials for the remote backend would bypass the OIDC workflow and reintroduce a persistent attack vector that OIDC is designed to eliminate.

Encryption at rest configuration

Why it fails: While highly recommended for security, explicitly configuring encryption at rest for the state file is typically a feature managed by the chosen backend service itself (e.g., S3 bucket policies, Azure Storage encryption settings) rather than a direct, mandatory configuration within Terraform's `backend` block. Terraform primarily needs to know *where* to store the state, not necessarily *how* that storage is encrypted. Therefore, it is not a *required* configuration element within the Terraform code.

State locking support

Why it fails: State locking is a crucial feature for preventing concurrent operations from corrupting the state file, especially in collaborative environments. However, not all Terraform backends inherently support state locking, or it might be an optional feature that can be disabled. Terraform can still be configured and operate without state locking enabled, though this is strongly discouraged for production use cases involving multiple operators. Thus, it is not a *mandatory* requirement for backend configuration.

Workspace configuration

Why it fails: Workspaces provide a mechanism for managing multiple distinct states for a single Terraform configuration, often used for different environments like `dev`, `staging`, or `prod`. While useful for organizational purposes, configuring specific workspaces is entirely optional and not a prerequisite for setting up a backend. Terraform defaults to the `default` workspace if none are explicitly created or selected, meaning the backend can function without any explicit workspace configuration.

Data sources are only available after applying the configuration.

Why it fails: This statement is incorrect because Terraform data sources are evaluated and their data is fetched during the `terraform plan` phase, not after `apply`. The information retrieved by data sources is crucial for Terraform to construct a complete execution plan, determining what changes need to be made. If they were only available after applying, they couldn't inform the plan or be used in resource arguments that are resolved during planning.

Data sources are used to create new infrastructure.

Why it fails: This statement is incorrect because data sources are explicitly designed for reading existing infrastructure or external data, not for creating new resources. Their role is to fetch attributes of pre-existing components, making that information available within the Terraform configuration. Creating or modifying infrastructure is the exclusive function of `resource` blocks, which manage the lifecycle of infrastructure objects.

Data sources cannot be used inside modules.

Why it fails: This statement is incorrect; data sources are frequently and effectively used inside Terraform modules. Modules serve as reusable containers for infrastructure configurations, and including data sources within them allows the module to dynamically fetch necessary external information. This enables modules to be more flexible and self-contained, as they can retrieve specific details pertinent to their operation without requiring them to be passed in as explicit input variables.

When a resource uses the output of another resource in its arguments.

Why it fails: When a resource uses the output of another resource in its arguments, Terraform's dependency graph automatically infers the correct creation order. For instance, if an aws_instance resource references the id attribute of an aws_vpc resource, Terraform understands that the VPC must be created and its ID available before the instance can be provisioned within it. This implicit dependency mechanism is fundamental to how Terraform manages resource relationships and ensures proper sequencing without manual intervention.

When a resource uses the output of a data source in its arguments.

Why it fails: When a resource uses the output of a data source in its arguments, Terraform automatically establishes an implicit dependency. Data sources are designed to fetch information about existing infrastructure or external services *before* resources are created or updated. Therefore, if a resource configuration references an attribute from a data source, Terraform ensures the data source is successfully read and its outputs are available before attempting to configure the dependent resource, guaranteeing the necessary information is present.

When a resource uses a module output as an input.

Why it fails: Referencing an output from a child module as an input to a resource in a parent or sibling module creates an implicit dependency that Terraform automatically resolves. Modules encapsulate configurations, and their outputs are only available after the module's resources have been successfully provisioned. Terraform ensures that the child module is applied and its outputs computed before any resource in the calling module attempts to use those outputs, maintaining the correct execution order across module boundaries.

Terraform is designed to work exclusively with AWS.

Why it fails: This statement is incorrect because Terraform is designed as a cloud-agnostic and provider-agnostic tool, supporting a vast ecosystem of infrastructure providers beyond just AWS. While AWS is a popular integration, Terraform seamlessly integrates with numerous other platforms, including Azure, Google Cloud Platform, Kubernetes, VMware vSphere, and various SaaS providers. Its extensible provider model allows it to manage resources across diverse environments, demonstrating its versatility far beyond exclusive AWS usage.

Terraform is a configuration management tool used for installing software on existing servers.

Why it fails: This statement is inaccurate as Terraform is fundamentally an infrastructure provisioning tool, focused on creating and managing the underlying infrastructure components like servers, networks, and databases. It is not a configuration management tool, which typically handles the post-provisioning setup, such as installing software, configuring operating systems, or managing services on existing servers. Tools like Ansible, Chef, or Puppet fulfill the configuration management role, often working in conjunction with Terraform for a complete solution.

Terraform is a continuous integration and deployment tool.

Why it fails: This statement is incorrect; Terraform is an Infrastructure as Code (IaC) tool, distinct from a continuous integration and deployment (CI/CD) system. CI/CD tools, such as Jenkins or GitLab CI, automate the software development lifecycle, focusing on building, testing, and deploying application code. While Terraform is frequently integrated into CI/CD pipelines to automate infrastructure provisioning steps, it does not perform the broader functions of application build, test, or deployment automation itself.