50 Free Terraform Certification Practice Questions
Infrastructure as Code has fundamentally transformed how modern engineering teams provision, manage, and scale their technical environments, and Terraform has emerged as the dominant tool in this space. Developed by HashiCorp, Terraform allows practitioners to define infrastructure resources across dozens of cloud providers and services using a declarative configuration language, enabling repeatable, version-controlled, and auditable infrastructure management that manual provisioning processes simply cannot match. The HashiCorp Terraform Associate certification validates foundational competence in Terraform concepts, workflows, and best practices, and it has become a recognized credential that hiring managers in cloud engineering, DevOps, and platform engineering roles actively seek when evaluating candidates.
Preparing for the Terraform Associate examination requires more than casual familiarity with Terraform commands — it demands a structured understanding of how Terraform works conceptually, how its core components interact, and how its workflows apply to real infrastructure management scenarios. The 50 practice topics presented in this guide cover the full breadth of examination domains, from foundational concepts and configuration syntax through state management, modules, workspace operations, and HashiCorp Cloud Platform integration. Each topic is framed as a practice scenario or knowledge area with a thorough explanation that reinforces understanding rather than simply providing a definition. Working through this material carefully and ensuring that the reasoning behind each concept is genuinely clear will build the examination readiness that candidates need to perform confidently on their actual test day.
Terraform Core Concepts Practice
The foundational concepts that underpin all Terraform operations form the first critical knowledge domain for certification candidates. Terraform operates on a declarative model, meaning practitioners describe the desired end state of their infrastructure rather than writing procedural scripts that specify each step required to reach that state. When a candidate encounters an examination scenario asking what distinguishes declarative Infrastructure as Code from imperative approaches, the key distinction is that Terraform determines how to achieve the declared state while the practitioner only specifies what that state should be. This conceptual clarity is foundational to understanding every other aspect of how Terraform behaves.
The Terraform workflow consists of three primary phases that candidates must understand deeply: init, plan, and apply. The init phase initializes a working directory by downloading required provider plugins and setting up the backend configuration. The plan phase compares the current state of infrastructure with the desired configuration and produces an execution plan describing what changes Terraform will make. The apply phase executes those changes against the actual infrastructure. A fourth command, destroy, tears down all infrastructure managed by a given configuration. Examination questions frequently test whether candidates understand which phase performs which function, particularly the distinction between plan generating a preview and apply executing actual changes.
Providers are the plugins that enable Terraform to interact with specific infrastructure platforms, APIs, and services. Each provider is developed and maintained either by HashiCorp, by the platform vendor, or by the community, and providers must be declared in the configuration and downloaded during terraform init before they can be used. The provider block in a Terraform configuration specifies which provider to use and any required configuration such as authentication credentials, region settings, or API endpoints. Candidates should understand that providers are versioned independently of Terraform itself, and that provider version constraints in the configuration ensure reproducible behavior across different environments and team members.
Resources are the fundamental building blocks of Terraform configurations, representing the infrastructure objects that Terraform creates, reads, updates, and deletes. Each resource block declares a resource type — determined by the provider — and a local name used to reference that resource elsewhere in the configuration. The combination of resource type and local name must be unique within a module. Candidates should be familiar with the general structure of a resource block, understanding that the arguments within the block configure the specific properties of the infrastructure object being managed, and that different resource types accept different arguments based on the underlying infrastructure platform’s capabilities.
Data sources allow Terraform configurations to read information from existing infrastructure or external systems without managing that infrastructure as part of the current configuration. A data source block retrieves information — such as the ID of an existing VPC, the latest version of an AMI, or the details of a DNS zone — that the configuration can then reference when creating or configuring managed resources. The distinction between resources and data sources is a frequently tested concept: resources declare infrastructure that Terraform manages and can modify, while data sources declare information that Terraform reads but does not control or modify.
Terraform State Management Topics
State is one of the most conceptually important and examination-tested topics in the entire Terraform certification curriculum. Terraform state is a JSON file that records the current known state of all infrastructure managed by a given configuration, mapping each resource block in the configuration to its corresponding real-world infrastructure object. Without state, Terraform would have no way to determine what infrastructure already exists, what changes need to be made to reach the desired configuration, or what infrastructure to target when performing updates or deletions. Every Terraform operation reads and potentially writes the state file, making its integrity and availability critical to reliable infrastructure management.
The terraform state list command displays all resources currently tracked in the state file, providing a quick inventory of everything Terraform knows about. The terraform state show command displays the detailed attributes of a specific resource in the state, which is useful for inspecting the current recorded values of a resource’s properties. The terraform state mv command moves resources within the state — renaming them or moving them between state files — which is essential when refactoring configurations without destroying and recreating infrastructure. The terraform state rm command removes a resource from state tracking without destroying the actual infrastructure, which is useful when you want Terraform to stop managing a resource without deleting it.
Remote state storage is a critical practice for teams using Terraform collaboratively, and it is heavily tested in the certification examination. When state is stored locally on a developer’s machine, other team members cannot access it, concurrent operations can corrupt it, and it is vulnerable to loss if the machine is unavailable. Remote backends store state in a centralized, shared location such as Terraform Cloud, AWS S3, Azure Blob Storage, or Google Cloud Storage, making it accessible to all team members and enabling features like state locking. State locking prevents concurrent operations from simultaneously modifying the same state, protecting against corruption that would occur if two terraform apply operations ran simultaneously against the same infrastructure.
State file security is an examination topic that candidates must treat with particular seriousness. Terraform state files can contain sensitive values — database passwords, API keys, private keys, and other credentials — that are recorded in plaintext within the JSON structure. This means that wherever state is stored, appropriate access controls must be applied to prevent unauthorized exposure of sensitive data. When using remote backends, encryption at rest and strict IAM policies governing who can read and write the state file are essential security controls. Candidates should understand that even when sensitive values are marked with the sensitive argument in a configuration, those values may still appear in state files, which reinforces the importance of state storage security.
Variables and Outputs Configuration
Input variables make Terraform configurations flexible and reusable by parameterizing values that would otherwise be hardcoded. A variable block declares an input variable with an optional type, description, default value, and validation rules. When a variable has no default value, Terraform requires a value to be provided at runtime through a variable definition file, a command-line flag, or an environment variable. When a default is provided, the configuration can run without explicitly supplying a value for that variable, using the default instead. Candidates should understand the different mechanisms for supplying variable values and their precedence order, as examination questions frequently test which value source takes precedence when multiple sources provide values for the same variable.
Variable types in Terraform include primitive types — string, number, and bool — and complex types including list, map, set, object, and tuple. Type constraints in variable declarations enforce that the values supplied match the expected type, catching configuration errors before they produce unexpected infrastructure changes. The any type disables type checking, accepting values of any type. Candidates should understand the practical differences between collection types: lists maintain order and allow duplicate values, sets do not maintain order and do not allow duplicates, and maps associate string keys with values. These distinctions matter when examination questions present scenarios involving variable types for specific use cases.
Output values expose information from a Terraform configuration — such as the IP address of a newly created server, the ARN of a created resource, or the connection string of a database — making that information available for display after apply operations or for use by other Terraform configurations through remote state data sources. An output block specifies a name, a value expression, an optional description, and an optional sensitive flag. When the sensitive flag is set to true, the output value is redacted in command-line display and in Terraform Cloud logs, preventing accidental exposure of sensitive data in terminal output or CI/CD pipeline logs.
Terraform Modules and Reusability
Modules are collections of Terraform configuration files in a directory that together represent a reusable infrastructure component. Every Terraform configuration is technically a module — the root module consists of the configuration files in the working directory where Terraform commands are executed. Child modules are called from within the root module or other child modules using module blocks that specify the module source and any required input variable values. Modules enable infrastructure patterns to be defined once and reused across multiple environments, projects, or teams, reducing duplication and enforcing consistency in how common infrastructure components are configured.
Module sources tell Terraform where to find the module configuration files. Sources can be local filesystem paths, the Terraform Registry, GitHub repositories, Bitbucket repositories, generic Git or Mercurial repositories, HTTP URLs, S3 buckets, or GCS buckets. The Terraform Registry at registry.terraform.io hosts a large collection of publicly available modules for common infrastructure patterns, maintained by HashiCorp, vendors, and the community. Candidates should understand the different source types and the syntax used for each, as examination questions test the ability to identify correct module source declarations for different scenarios.
Module outputs allow child modules to expose values to the calling configuration, similar to how root module outputs expose values to users. When a child module defines output values, the calling configuration can reference those values using the syntax module.module_name.output_name. This mechanism is how information flows upward from child modules to parent configurations — a networking module might output the IDs of created subnets, which a compute module then references when creating instances that should be placed in those subnets. Candidates should be comfortable tracing the flow of values between modules through input variables and output values.
Terraform Workspaces and Environments
Terraform workspaces allow a single configuration directory to manage multiple distinct state files, enabling the same configuration to be used for different environments — such as development, staging, and production — without duplicating configuration files. Each workspace has its own state file, so resources created in the development workspace are tracked separately from resources in the production workspace. The default workspace exists in every Terraform configuration and is used when no workspace has been explicitly selected. Commands for workspace management include terraform workspace new to create a workspace, terraform workspace select to switch to a workspace, terraform workspace list to display all workspaces, and terraform workspace show to display the currently active workspace.
The current workspace name is accessible within configuration files through the terraform.workspace expression, which returns a string containing the workspace name. This allows configurations to use workspace-aware logic — such as selecting different instance sizes, enabling or disabling certain resources, or constructing environment-specific resource names — based on which workspace is currently active. A common pattern uses the workspace name as a prefix or suffix in resource names to ensure uniqueness across environments sharing the same infrastructure platform. Candidates should understand how terraform.workspace enables dynamic, workspace-aware configurations and should be able to identify the correct syntax for accessing it.
Terraform Cloud and Enterprise Features
Terraform Cloud is HashiCorp’s managed service for collaborative Terraform usage, providing remote state storage, remote execution of Terraform operations, team access controls, policy enforcement, and an audit trail for infrastructure changes. When Terraform is configured to use Terraform Cloud as its backend, plan and apply operations run on Terraform Cloud’s infrastructure rather than on the local machine, which provides consistent execution environments, eliminates the need for practitioners to have direct credentials for managed infrastructure on their local machines, and enables collaborative review workflows where plans can be reviewed and approved before application. Candidates should understand the distinction between local execution with remote state storage and fully remote execution in Terraform Cloud.
Sentinel is HashiCorp’s policy-as-code framework integrated into Terraform Cloud and Terraform Enterprise that allows organizations to define and enforce governance policies on infrastructure changes. Sentinel policies evaluate the planned changes produced by a terraform plan operation and can block, warn about, or require advisory approval for changes that violate organizational standards. Common Sentinel policy use cases include enforcing required resource tags, preventing the creation of resources in unauthorized regions, requiring encryption for storage resources, and enforcing instance type restrictions. Candidates should understand Sentinel’s role in the Terraform workflow and that it runs after plan and before apply, giving policies the opportunity to evaluate the specific changes being proposed before they are executed.
The Terraform Cloud remote backend configuration connects a local Terraform working directory to a Terraform Cloud workspace, directing state storage and optionally plan and apply execution to Terraform Cloud. The backend block in the configuration specifies the organization name and workspace name in Terraform Cloud. Authentication to Terraform Cloud is handled through API tokens that can be configured using the terraform login command, which stores credentials securely in the local credentials file. Candidates should understand the relationship between local configurations and Terraform Cloud workspaces and the authentication mechanism that enables the connection.
Terraform Functions and Expressions
Terraform provides a rich library of built-in functions that can be used within expressions in configuration files to transform, combine, and compute values. Functions are called using the syntax function_name(argument1, argument2) and can be nested within larger expressions. Categories of built-in functions include string functions, numeric functions, collection functions, encoding functions, filesystem functions, date and time functions, hash and crypto functions, IP network functions, and type conversion functions. Candidates should be familiar with commonly used functions and their purposes, even if they cannot memorize every function’s exact syntax.
The count meta-argument allows a single resource block to create multiple instances of the same resource type, with the number of instances determined by the count value. Each instance is identified by its index in the count, accessible within the resource configuration through count.index. To reference a specific instance of a counted resource elsewhere in the configuration, the syntax resource_type.resource_name[index] is used. The for_each meta-argument provides a more flexible alternative that creates one resource instance for each element in a map or set, with each instance identified by its key rather than a numeric index. Examination questions frequently test the distinction between count and for_each and the scenarios in which each is more appropriate.
Terraform CLI Commands Reference
The terraform fmt command formats Terraform configuration files according to HashiCorp’s canonical style conventions, automatically adjusting indentation, spacing, and alignment to match the standard. Running terraform fmt regularly on a codebase ensures consistent formatting across all configuration files regardless of which team member wrote them, reducing style-related differences in version control diffs and making configurations easier to read. The command modifies files in place and displays the names of files that were changed. The -recursive flag extends formatting to all subdirectories, which is useful for formatting an entire repository of Terraform configurations in a single command.
The terraform validate command checks whether a configuration is syntactically valid and internally consistent without accessing any remote services or state. It verifies that configuration files parse correctly, that all required arguments are present, that referenced variables and locals exist, and that expression types are compatible. Validate does not check whether the specified provider configurations are correct, whether referenced resources actually exist in the infrastructure, or whether the planned changes would succeed — those checks require communication with providers and state. Candidates should understand that validate is a fast, offline check appropriate for catching syntax and structural errors in development, while plan provides a more complete assessment that requires provider communication.
The terraform taint command marks a specific resource in the state as tainted, flagging it for destruction and recreation on the next terraform apply operation. Tainting is useful when a resource is known to be in a degraded or inconsistent state that Terraform’s normal change detection would not automatically address — for example, if a server’s operating system has become corrupted and needs to be replaced without changing its infrastructure configuration. In newer versions of Terraform, the terraform apply -replace=resource_address syntax is preferred over terraform taint as it combines the tainting and replacement in a single operation with a clearer intent. Candidates should be familiar with both approaches.
HashiCorp Configuration Language Fundamentals
HashiCorp Configuration Language, commonly known as HCL, is the domain-specific language used to write Terraform configurations. HCL is designed to strike a balance between human readability and machine parseability, with a syntax that reads more naturally than JSON or YAML while remaining structured enough for reliable programmatic processing. Configuration files use the .tf extension for HCL format or the .tf.json extension for JSON format — both are valid and can coexist in the same working directory, though HCL is overwhelmingly preferred for hand-authored configurations due to its readability and support for comments.
Blocks are the fundamental structural elements of HCL, consisting of a block type, zero or more labels, and a body enclosed in curly braces. Resource blocks have two labels — the resource type and the local name. Variable blocks have one label — the variable name. Provider blocks have one label — the provider local name. The terraform settings block has no labels. Understanding the block structure and the number and meaning of labels for each block type helps candidates read and write configurations correctly and interpret examination questions that present configuration snippets for analysis.
References and expressions in HCL allow configuration values to be computed from other values rather than being hardcoded literals. References follow a structured syntax that identifies the type of object being referenced — resources, data sources, variables, locals, modules, path information, and filesystem functions each have distinct reference prefixes. A reference to an attribute of a managed resource uses the format resource_type.resource_name.attribute. A reference to an input variable uses var.variable_name. A reference to a local value uses local.local_name. A reference to a module output uses module.module_name.output_name. Candidates should be comfortable with reference syntax across all these object types.
The depends_on meta-argument explicitly declares dependencies between resources or modules that Terraform cannot automatically infer from expression references. Normally, Terraform detects dependencies automatically when one resource’s configuration references another resource’s attributes — the referencing resource depends on the referenced resource and will be created after it. However, some dependencies are implicit in behavior rather than expressed through attribute references — for example, an application server that depends on a database being fully initialized before the application can start, even though the server configuration does not directly reference any database attribute. In these cases, depends_on explicitly instructs Terraform to honor the dependency in its execution order.
Terraform Security Best Practices
Managing secrets and sensitive values in Terraform configurations requires careful attention to prevent credential exposure in configuration files, state files, logs, and version control systems. Sensitive values — database passwords, API keys, private certificates, and similar credentials — should never be hardcoded in configuration files that are committed to version control. Instead, sensitive values should be supplied through environment variables, encrypted variable definition files, or secrets management integrations. The sensitive argument in variable and output declarations marks values as sensitive, causing Terraform to redact them from CLI output, though this does not prevent them from being stored in state files.
Provider authentication credentials deserve particular security attention because they grant Terraform the permissions required to create, modify, and destroy infrastructure — typically broad permissions that represent a significant security risk if exposed. Best practices for provider authentication vary by provider but generally favor using instance profiles, workload identity, or other credential-free authentication mechanisms in CI/CD environments over static credentials. When static credentials are necessary, they should be provided through environment variables or encrypted secrets management systems rather than hardcoded in provider blocks. Candidates should understand that securing provider credentials is a fundamental operational security responsibility that accompanies Terraform adoption.
Conclusion
The 50 practice topics covered throughout this guide represent the conceptual landscape that Terraform Associate certification candidates must internalize to perform confidently on their examination. Each topic connects to practical Terraform usage in ways that reflect the genuine demands of infrastructure engineering roles, which means that studying for this certification builds skills that are immediately applicable in real work environments rather than purely academic knowledge that serves only examination purposes. Candidates who approach their preparation with this dual goal — examination readiness and genuine skill development — consistently report both better examination performance and more rapid professional growth after earning the credential.
The official HashiCorp study materials, including the Terraform Associate certification study guide and the associated Terraform documentation, should form the backbone of preparation alongside practice with actual Terraform configurations. There is no substitute for running terraform init, plan, apply, and destroy against real infrastructure in a personal AWS, Azure, or GCP account — the tactile experience of working through real Terraform workflows, encountering actual error messages, and debugging genuine configuration problems builds a pattern recognition capability that reading alone cannot replicate. Free tier accounts across all major cloud providers provide sufficient resources for building Terraform practice environments without meaningful cost.
Community resources supplement official materials significantly for Terraform certification preparation. The HashiCorp Learn platform offers structured tutorials that walk through Terraform workflows hands-on, the HashiCorp Forum provides community discussion of complex Terraform topics, and the official Terraform Registry documentation for major providers offers detailed reference material for the resource types most commonly featured in examination scenarios. Candidates who engage actively with multiple resource types — working with AWS, Azure, or GCP provider resources in hands-on exercises rather than simply reading about them — develop the broad familiarity with provider resource patterns that helps them approach unfamiliar examination scenarios with confidence.
Examination day performance is built through consistent preparation over weeks rather than intensive cramming in the final days before the test. The Terraform Associate examination rewards genuine conceptual understanding over memorization of syntax details, which means candidates who have internalized the why behind Terraform’s design decisions — why state exists, why providers are versioned, why remote backends matter for teams, why modules enable reuse — consistently outperform those who have memorized command syntax without understanding the reasoning behind it. That depth of understanding is built through study, practice, reflection on how concepts connect to each other, and the kind of hands-on experimentation that reveals the behavioral nuances that examination questions are designed to probe. Every candidate who commits to this comprehensive preparation approach arrives at their examination with the knowledge, confidence, and practical grounding that the Terraform Associate credential is designed to recognize and validate.
- Category: Others
