HashiCorp Terraform Associate 004

examtopics

IaC (Infrastructure as Code) can be stored in a version control system along with application code.

• A. True

• B. False

Answer: A) True Why This Is Correct

IaC (Infrastructure as Code) is essentially just code — it's written in configuration files (like .tf files in Terraform) that are plain text. Because of this, it can absolutely be stored in a version control system (VCS) like Git (used by platforms like GitHub, GitLab, and Bitbucket), right alongside your application code.

This is actually considered a best practice in modern software development and DevOps. Here's why storing IaC in version control is so valuable:

• History & Auditability — You can see exactly what changed in your infrastructure, when it changed, and who changed it. Every commit is a record.

• Collaboration — Multiple team members can work on infrastructure changes, submit pull requests, and have changes reviewed before they're applied — just like application code.

• Rollback — If an infrastructure change causes problems, you can revert to a previous version of your config files.

• Consistency — The infrastructure definition lives with the app it supports, so they evolve together. A new developer can clone the repo and understand both the app and its infrastructure.

• CI/CD Integration — Storing IaC in a VCS allows pipelines (like GitHub Actions or Jenkins) to automatically plan and apply Terraform changes when code is merged.

This is one of the core value propositions of IaC — treating infrastructure the same way you treat software code, including how it's stored and managed.

---

Why B) False Is Incorrect

There is no technical or practical reason that prevents IaC from being stored in version control. Since Terraform configurations are plain text files, they are fully compatible with any VCS. Saying "False" would suggest some limitation or incompatibility exists — it does not. In fact, storing IaC outside of version control would be considered an anti-pattern and a risk, as you'd lose all the benefits listed above.

It is best practice to store secret data in the same version control repository as your Terraform configuration.

• A. True

• B. False

Answer: B) False Why This Is Correct

Storing secret data (such as passwords, API keys, access tokens, private certificates, or any sensitive credentials) in a version control repository is a serious security risk and is considered a major anti-pattern in the industry. This applies whether or not Terraform is involved.

Here is why this is dangerous:

• Version control is permanent by nature — Even if you delete a secret from a file and commit the deletion, the secret still exists in the commit history. Anyone with access to the repo can go back in time and find it. Scrubbing secrets from Git history is a painful and error-prone process.

• Exposure risk — Repositories, especially on platforms like GitHub, can accidentally be made public. If secrets are in the repo, they are instantly exposed to the entire internet. There are bots that actively scan public repos for secrets the moment they are pushed.

• Blast radius — If a repo is compromised (e.g., a team member's account is hacked), every secret stored in it is compromised too.

• No access control granularity — Everyone with repo access can see the secrets, even if they don't need them for their role. Proper secrets management tools allow fine-grained access control.

What You Should Do Instead

Terraform and the broader DevOps ecosystem offer several safe alternatives for managing secrets:

• Environment Variables — Pass sensitive values into Terraform at runtime via environment variables (e.g., TF_VAR_my_secret), so they never touch the codebase.

• Terraform Cloud / HCP Terraform — Has a built-in mechanism for storing sensitive variables securely, marked as "sensitive" so they are never displayed in logs or the UI.

• Secret Management Tools — Dedicated tools like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager are purpose-built to store, rotate, and audit access to secrets.

• .gitignore — If a file containing secrets must exist locally (e.g., a terraform.tfvars file with sensitive values), it should be listed in .gitignore so Git never tracks it. A terraform.tfvars.example file with placeholder values can be committed instead as a template.

---

Why A) True Is Incorrect

Saying it is best practice to store secrets in version control is incorrect because it directly contradicts the principle of least privilege and basic security hygiene. No reputable security framework, cloud provider, or DevOps methodology recommends this. Terraform's own documentation explicitly warns against committing sensitive values to version control. Doing so creates vulnerabilities that can be very difficult or impossible to fully remediate after the fact, since the history of a repository is not easily erased.

Which is an advantage of using IaC (Infrastructure as Code) that is not possible when provisioning with a GUI (Graphical User Interface)?

• A. Let’s you version, reuse, and share infrastructure configuration.

• B. Secures your credentials.

• C. Provisions the same resources at a lower cost.

• D. Prevents manual modifications to your resources.

Answer: A) Lets you version, reuse, and share infrastructure configuration. Why This Is Correct

This is the most fundamental advantage of IaC over GUI-based provisioning. When your infrastructure is defined in code (like Terraform .tf files), it becomes a text-based artifact that unlocks capabilities that are simply not possible when clicking through a GUI:

• Versioning — Because IaC is plain text, it can be stored in a version control system like Git. This means you have a full history of every change ever made to your infrastructure — who changed it, when, and why. When you provision infrastructure through a GUI, there is no built-in record of what was clicked or configured. It just happens, and it's gone.

• Reuse — IaC allows you to write a configuration once and reuse it many times. In Terraform specifically, this is done through modules — reusable packages of configuration that can be called with different inputs. For example, you could write a module to provision a web server and reuse it across 10 different projects. In a GUI, you would have to manually repeat every click for every environment.

• Sharing — Because IaC is just files, it can be shared with teammates, published to registries (like the Terraform Registry), open-sourced on GitHub, or handed off to another team. A GUI workflow cannot be "shared" — at best you can write a document describing what to click, which is error-prone and quickly becomes outdated.

Together, these three capabilities are what make IaC the foundation of modern DevOps and infrastructure management. They enable consistency, collaboration, and scalability that GUI-based workflows simply cannot match.

---

Why All Other Options Are Incorrect

B) Secures your credentials

IaC does not inherently secure your credentials — in fact, as covered in the previous question, IaC can actually introduce credential security risks if secrets are accidentally committed to version control. Credential security is handled by separate tools like HashiCorp Vault, AWS Secrets Manager, or environment variables. A GUI doesn't secure credentials either, but the point is this is not an advantage of IaC over a GUI. It is a concern that exists regardless of which approach you use.

C) Provisions the same resources at a lower cost

IaC does not provision resources at a lower cost. The cloud resources you create (virtual machines, databases, storage buckets, etc.) cost exactly the same whether you created them by clicking through the AWS Console GUI or by running terraform apply. The underlying infrastructure is identical — only the method of provisioning differs. Cost is determined by resource type, size, and usage time, not by how it was created.

D) Prevents manual modifications to your resources

IaC does not prevent manual modifications. If someone has the necessary cloud permissions, they can absolutely log into the AWS Console (or any other GUI) and manually change or delete resources that were originally created by Terraform. This is actually a well-known problem called configuration drift — where the real state of your infrastructure diverges from what your IaC says it should be. Terraform has mechanisms to detect drift (via terraform plan), but it cannot prevent someone from making manual changes. Preventing unauthorized changes is a matter of IAM policies and access controls, not IaC itself.

What is an advantage of immutable infrastructure?

• A. Automatic infrastructure upgrades

• B. In-place infrastructure upgrades

• C. Quicker infrastructure upgrades

• D. Less complex infrastructure upgrades

Answer: D) Less complex infrastructure upgrades Why This Is Correct

To understand why this is correct, you first need to understand what immutable infrastructure means.

Immutable means "cannot be changed." In an immutable infrastructure model, when you need to update or change something, you never modify the existing infrastructure in place. Instead, you:

1. Build a brand new server/resource with the updated configuration

2. Switch traffic over to the new resource

3. Destroy the old resource

This is in contrast to mutable infrastructure, where you update servers that are already running (e.g., SSH-ing into a server and running apt upgrade, or applying a patch to a live system).

Here is why immutable infrastructure results in less complexity:

• No configuration drift — In mutable infrastructure, servers that have been updated many times over their lifetime can end up in slightly different states from one another, even if they were identical when first created. This is called configuration drift, and debugging it is notoriously complex. With immutable infrastructure, every server is built fresh from the same template every single time, so they are always identical.

• No "works on my machine" problems — Because the entire environment is replaced rather than patched, you eliminate the accumulated complexity of years of in-place changes, partial updates, and failed upgrade scripts.

• Simpler rollback — If something goes wrong, you simply route traffic back to the previous version of your infrastructure, which still exists. There is no need to "undo" a series of changes on a running server.

• Predictability — Because you are always deploying from a known, clean state, the behavior of your infrastructure is much more predictable and easier to reason about.

In Terraform's context, this philosophy is reflected in how it manages resources — rather than trying to patch things in place, Terraform will often destroy and recreate resources when certain properties change, embracing the immutable approach.

---

Why All Other Options Are Incorrect

A) Automatic infrastructure upgrades

Immutable infrastructure does not make upgrades automatic. You still have to deliberately trigger the process of building a new resource and replacing the old one. Nothing about immutability introduces automation on its own — automation is a separate concern handled by CI/CD pipelines and tooling. Immutability defines how upgrades are done (replace rather than patch), not when or whether they happen automatically.

B) In-place infrastructure upgrades

This is actually the opposite of immutable infrastructure — it describes mutable infrastructure. In-place upgrades mean modifying a resource that is already running, such as updating software on a live server. Immutable infrastructure explicitly avoids this pattern. If you are doing in-place upgrades, you are not following the immutable model. This option describes the problem that immutable infrastructure was designed to solve.

C) Quicker infrastructure upgrades

Immutable infrastructure does not necessarily mean faster upgrades. In fact, it can sometimes be slower, because instead of applying a small patch to an existing server, you are provisioning an entirely new one from scratch — which involves building, testing, and deploying a fresh resource. The advantage of immutability is reliability and simplicity, not speed. Speed is a separate concern that depends on your tooling, pipeline, and cloud provider.

What is the primary purpose of IaC (Infrastructure as Code)?

• A. To define a pipeline to test and deliver software.

• B. To provision infrastructure cheaply.

• C. To programmatically create and configure resources.

• D. To define a vendor-agnostic API.

Answer: C) To programmatically create and configure resources. Why This Is Correct

The primary purpose of IaC is exactly what the name suggests — using code to create and configure infrastructure, rather than doing it manually through a GUI or running ad-hoc commands. "Programmatically" is the key word here, meaning the process is driven by code that can be executed, repeated, and automated.

In practical terms, this means:

• Creating resources — IaC allows you to define what infrastructure you need (virtual machines, networks, databases, storage, etc.) in a configuration file, and then have a tool like Terraform automatically provision those resources by making the necessary API calls to your cloud provider.

• Configuring resources — Beyond just creating resources, IaC also defines how those resources are configured — what size a server is, what region it lives in, what security rules apply, how resources are connected to each other, etc.

• Repeatability — Because the instructions are written in code, the exact same infrastructure can be created over and over again with the same result. You could spin up identical environments for development, staging, and production with a single codebase.

• Automation — Since it is code, it can be executed without human intervention, integrated into pipelines, and triggered by events — removing the need for a human to manually click through a console each time.

This is the core value of IaC in a single sentence: replace manual, error-prone, GUI-based human processes with reliable, repeatable, automated code.

---

Why All Other Options Are Incorrect

A) To define a pipeline to test and deliver software

This describes CI/CD (Continuous Integration / Continuous Delivery) pipelines, which are a separate concern from IaC. Tools like Jenkins, GitHub Actions, GitLab CI, and CircleCI are used to define pipelines for testing and delivering software. While IaC can be used within a pipeline (for example, running terraform apply as a step in a deployment pipeline), that is not its primary purpose. IaC is about defining and provisioning infrastructure, not about the software delivery lifecycle itself.

B) To provision infrastructure cheaply

As discussed in a previous question, IaC does not inherently reduce the cost of infrastructure. The resources you provision cost exactly the same whether you created them via code or via a GUI. The cloud provider charges based on what resources exist and how long they run — not how they were created. While IaC can indirectly help with cost management (for example, by making it easy to tear down and recreate environments only when needed), reducing cost is a side effect at best, not the primary purpose.

D) To define a vendor-agnostic API

This does not describe IaC — it describes something closer to what Terraform's provider model or an abstraction layer does at an architectural level. Terraform itself is vendor-agnostic in the sense that it works with many cloud providers, but that is a feature of Terraform as a tool, not the definition of IaC as a concept. IaC is a methodology and practice, not an API specification. Defining vendor-agnostic APIs is the concern of tools and standards like OpenAPI or cloud abstraction frameworks, which are entirely separate from IaC.

Your team adopts an AWS CloudFormation as the standardized method for provisioning public cloud resources.
Which scenario presents a challenge for your team?

• A. Deploying new infrastructure into Microsoft Azure.

• B. Automating a manual, web console-based provisioning process.

• C. Building a reusable code base that can deploy resources into any AWS region.

• D. Managing a new application stack built on AWS-native services.

Answer: A) Deploying new infrastructure into Microsoft Azure. Why This Is Correct

AWS CloudFormation is Amazon's native IaC tool, and it is exclusively designed to work with AWS (Amazon Web Services). It cannot provision or manage resources in any other cloud provider. This is the critical limitation that makes option A the correct challenge.

Here is why this is a problem:

• CloudFormation is AWS-only — CloudFormation works by making API calls to AWS services. It has no knowledge of, or ability to communicate with, Microsoft Azure, Google Cloud Platform, or any other cloud provider. If your team tries to use CloudFormation to deploy resources into Azure, it simply cannot be done — the tool does not support it.

• Vendor lock-in — By standardizing on CloudFormation, your team has tied itself to a single cloud provider's tooling. This is known as vendor lock-in. If your organization ever needs to work in a multi-cloud environment (which is very common in enterprise settings), CloudFormation becomes a blocker rather than an enabler.

• Multi-cloud is increasingly common — Many organizations use multiple cloud providers simultaneously, either by choice (to leverage the best services from each) or by necessity (e.g., after a merger or acquisition). A team standardized on CloudFormation would need to adopt a completely different tool for any non-AWS work.

This is precisely why vendor-agnostic IaC tools like Terraform are so widely adopted — Terraform supports hundreds of providers including AWS, Azure, GCP, and many others, all using the same language and workflow. CloudFormation offers no such flexibility.

---

Why All Other Options Are Incorrect

B) Automating a manual, web console-based provisioning process

This is actually one of the core strengths of CloudFormation, not a challenge. CloudFormation was specifically designed to replace manual, GUI-based provisioning in the AWS Console. By writing CloudFormation templates (in JSON or YAML), teams can fully automate the creation of AWS resources that would otherwise require clicking through the AWS web console. This is a problem CloudFormation solves very well, so it presents no challenge.

C) Building a reusable code base that can deploy resources into any AWS region

This is also something CloudFormation handles very well. CloudFormation templates are designed to be reusable and region-agnostic. You can write a single template and deploy it as a stack into any AWS region by simply specifying the target region at deployment time. CloudFormation also supports parameters, which allow you to customize deployments (including region-specific settings) without changing the underlying template. This is a strength of CloudFormation, not a limitation.

D) Managing a new application stack built on AWS-native services

This is the ideal use case for CloudFormation. Since CloudFormation is an AWS-native tool, it has deep, first-class support for all AWS services — EC2, S3, RDS, Lambda, VPC, IAM, and hundreds more. AWS continuously updates CloudFormation to support new services and features, often on the same day they are launched. Managing an application stack built entirely on AWS services is exactly what CloudFormation was built for, so this presents no challenge whatsoever.

Which is not a benefit of adopting IaC (Infrastructure as Code)?

• A. Reusability of code

• B. Automation

• C. A GUI (Graphical User Interface)

• D. Versioning

Answer: C) A GUI (Graphical User Interface) Why This Is Correct

A GUI is actually the opposite of what IaC represents — it is what IaC was designed to replace. IaC exists specifically to move away from manual, point-and-click, GUI-based infrastructure management and toward code-driven, automated, repeatable processes.

Here is why a GUI is not a benefit of IaC:

• IaC is code-based by definition — The entire premise of Infrastructure as Code is that infrastructure is defined in text files and executed programmatically. There is no GUI involved in this process. You write code, you run commands, and the tool (like Terraform) does the work.

• GUIs introduce the problems IaC solves — GUI-based provisioning is manual, error-prone, hard to repeat consistently, impossible to version, and difficult to audit. These are exactly the pain points that led to the creation of IaC in the first place.

• IaC workflows are terminal and pipeline driven — A typical Terraform workflow involves writing .tf files in a code editor, running commands like terraform init, terraform plan, and terraform apply in a terminal, and integrating those commands into CI/CD pipelines. None of these steps involve a GUI.

It is worth noting that some IaC tools and platforms (like HCP Terraform / Terraform Cloud) do offer a web-based UI for managing runs, viewing state, and controlling access — but this is a management interface layered on top of IaC, not a benefit of IaC itself. The core benefit of IaC is the code-driven approach, not any graphical interface.

---

Why All Other Options Are Incorrect

These options are incorrect in the context of this question because they are genuine benefits of IaC — the question asks which option is not a benefit.

A) Reusability of code

Reusability is absolutely a core benefit of IaC. Once you have written infrastructure configuration, you can reuse it across multiple projects, environments, and teams. In Terraform specifically, this is achieved through modules — self-contained packages of configuration that can be called with different inputs to produce different but consistent results. Writing infrastructure once and reusing it many times saves enormous amounts of time and reduces the risk of inconsistencies between environments.

B) Automation

Automation is one of the most significant benefits of IaC. Because infrastructure is defined in code, it can be executed automatically without human intervention. This means you can integrate Terraform into CI/CD pipelines so that infrastructure is provisioned, updated, or destroyed automatically as part of a software delivery workflow. Automation eliminates the slow, manual process of a human clicking through a GUI every time infrastructure needs to change, and it dramatically reduces the risk of human error.

D) Versioning

Versioning is another fundamental benefit of IaC, as discussed in earlier questions. Because IaC configurations are plain text files, they can be stored in version control systems like Git. This gives your team a complete history of every infrastructure change ever made, the ability to roll back to a previous state, the ability to create branches for experimental changes, and a clear audit trail of who changed what and when. None of this is possible with GUI-based provisioning, making versioning one of the strongest arguments for adopting IaC.

How does the use of Infrastructure as Code (IaC) enhance the reliability of your infrastructure? (Choose two.)

• A. Configuration drift is reduced with declarative definitions.

• B. Updates are deployed with zero downtime.

• C. Proposed changes can be reviewed before being applied.

• D. Incorrect configurations cannot be deployed.

• E. Infrastructure is automatically scaled to meet demand.

Answer: A) Configuration drift is reduced with declarative definitions & C) Proposed changes can be reviewed before being applied. Why These Are Correct

A) Configuration drift is reduced with declarative definitions

To understand this, you need to understand two concepts — configuration drift and declarative definitions.

Configuration drift is what happens over time when the actual state of your infrastructure starts to diverge from its intended state. This happens in mutable, GUI-managed environments because:

• Someone manually tweaks a server setting to fix an urgent problem and forgets to document it

• A team member makes a "quick change" through the AWS Console without telling anyone

• An automated process modifies a resource outside of the IaC workflow

• Different environments (dev, staging, prod) gradually become inconsistent with each other

Over time, these small undocumented changes accumulate, and your infrastructure becomes a mystery — nobody is entirely sure what is running or why. This makes debugging extremely difficult and deployments unpredictable.

A declarative definition means you define what you want the end state to be, rather than how to get there. In Terraform, you write configurations that say "I want three EC2 instances of this size in this region with these settings." Terraform then figures out the steps needed to make reality match that declaration.

This reduces drift because:

• The desired state is always explicitly written in code and stored in version control

• Running terraform plan compares the real state of your infrastructure against the declared state and highlights any differences

• Running terraform apply brings drifted infrastructure back in line with the declared configuration

• The code becomes the single source of truth for what your infrastructure should look like

C) Proposed changes can be reviewed before being applied

This is a major reliability enhancement that GUI-based provisioning simply cannot offer in the same structured way. IaC enables a formal review process before any changes touch real infrastructure:

• terraform plan — Before applying any changes, Terraform produces a detailed execution plan showing exactly what will be created, modified, or destroyed. This allows engineers to verify the impact of changes before anything happens in the real world.

• Pull Request reviews — Because IaC lives in version control, infrastructure changes go through the same code review process as application code. Team members can review proposed changes, ask questions, spot mistakes, and approve or reject changes before they are merged and applied.

• Automated checks — Tools can automatically validate IaC configurations for security issues, compliance violations, or misconfigurations before they are ever applied. Examples include Checkov, tfsec, and Sentinel (used with HCP Terraform).

• Approval workflows — Platforms like HCP Terraform allow you to require manual approvals before a terraform apply is executed, adding a human checkpoint in the process.

This combination of human review and automated validation significantly reduces the likelihood of incorrect or dangerous changes reaching production infrastructure.

---

Why All Other Options Are Incorrect

B) Updates are deployed with zero downtime

IaC does not guarantee zero downtime deployments. Whether a deployment causes downtime depends entirely on the type of resource being changed and how it is architected, not on the use of IaC itself. For example:

• In Terraform, some resource changes require the existing resource to be destroyed and recreated, which would cause downtime if there is no redundancy in place

• Zero downtime deployments require specific architectural patterns like blue/green deployments, rolling updates, or load balancer configurations — these are infrastructure design decisions, not something IaC automatically provides

• IaC is simply the tool used to provision and manage infrastructure. It does not inherently make that infrastructure highly available or update it without interruption

D) Incorrect configurations cannot be deployed

IaC does not prevent incorrect configurations from being deployed. While tools like terraform validate can catch syntax errors and some logical mistakes, and third party tools can scan for known misconfigurations, there is no foolproof mechanism that stops all incorrect configurations from being applied. If a developer writes a Terraform configuration that opens a security group to the entire internet, or provisions an undersized database, Terraform will happily apply it — it has no way of knowing that was not the intended outcome. IaC improves the process around reviewing and applying changes, but it does not make incorrect deployments impossible.

E) Infrastructure is automatically scaled to meet demand

IaC does not provide automatic scaling. Auto-scaling is a feature provided by cloud platforms themselves — for example, AWS Auto Scaling Groups, Azure Scale Sets, or GCP Managed Instance Groups. While you can absolutely use IaC to configure auto-scaling resources, the IaC tool itself is not what performs the scaling. IaC is used at provisioning and change management time, not as a runtime monitoring and scaling engine. Scaling in response to demand is a runtime concern handled by cloud provider services, not by Terraform or any other IaC tool.