📘 Free TERRAFORM ASSOCIATE-004 Sample Questions
IaC (Infrastructure as Code) can be stored in a version control system along with application code.
A
True
B
False
Correct Answer:
A. True
Explanation:
Answer: A – True
Infrastructure as Code is commonly version-controlled just like application source code. Storing Terraform scripts,
Ansible playbooks, CloudFormation templates, or similar artifacts in a Git repository (or other VCS) enables:
Auditability & traceability of infrastructure changes.
Collaboration among developers, ops, and security teams.
Consistent, repeatable deployments through CI/CD pipelines.
Branching strategies that mirror software release flows (feature branches, pull-request reviews, versioned
releases).
Keeping IaC alongside application code in the same repository promotes a unified source of truth, simplifies
Why the other option is less suitable
References
actions
dependency management, and supports the “treat-infrastructure-as-code” mindset required for modern
DevOps practices.
B. False – This statement contradicts the core principle of IaC. Treating infrastructure as immutable,
versioned artifacts is a best practice; treating it as an after-thought or external artifact undermines
traceability, reproducibility, and the ability to automate provisioning through CI/CD pipelines.
HashiCorp Learn – Terraform on GitHub: https://learn.hashicorp.com/terraform/cloud-get-started/github
Terraform Registry Documentation – Version Control Best Practices:
https://developer.hashicorp.com/terraform/language/v1.5/backends/gitlab (valid at time of writing)
It is best practice to store secret data in the same version control repository as your Terraform configuration.
A
True
B
False
Correct Answer:
B. False
Explanation:
Answer: B – False
Security posture: Storing secrets (e.g., database passwords, API keys) alongside Terraform files risks
accidental exposure in version-control history, pull-requests, or public forks. Secrets should be kept in
dedicated secret-management systems or encrypted stores, not in plain-text source control.
Least-privilege access: By separating secrets from infrastructure code, you can grant Terraform execution
roles only the permissions needed to read the secret at runtime, rather than exposing the entire configuration
to any user who can clone the repo.
Operational hygiene: Version-controlled Terraform configurations should be immutable in terms of
infrastructure definition; injecting secrets makes drift harder to detect and can inadvertently cause drift when
secret values are rotated.
Compliance & auditability: Best-practice frameworks (e.g., SOC2, ISO27001) require separation between
code and secret material to maintain clear audit trails and to support automated secret-scan policies.
Terraform provider behavior: The AWS provider will reject or mask secret values when they are sourced from
variables that are not marked as sensitive and stored in version control, encouraging the use of external secret
providers or encrypted backends.
Why the other option is less suitable
References
Option A (True) would imply that putting secrets in the same repo is the recommended approach. This
contradicts industry security standards, increases the attack surface, and violates principles of secret
isolation that the AWS provider and broader Terraform ecosystem promote.
Terraform AWS Provider Documentation – Secure Credential Management:
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/credential-management
HashiCorp Best Practices for Secrets in Terraform:
https://developer.hashicorp.com/terraform/language/modules/develops/using-modules#using-modules
(section “Storing Secrets”).
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.
Correct Answer:
A. Let’s you version, reuse, and share infrastructure configuration.
Explanation:
Why optionA is the correct advantage of IaC:
IaC treats infrastructure as version-controlled source code, enabling history tracking, branching,
pull-request reviews, and rollbacks of configuration changes.
The same configuration can be reused across environments (dev, staging, prod) and shared across teams
through repositories and registries, fostering collaboration and reducing drift.
This capability is fundamentally a code-centric workflow that GUIs cannot provide; a GUI interacts only with
the current state and offers no native versioning or sharing mechanisms.
Why the other options are less appropriate:
B – Secures your credentials: Security of credentials depends on how secrets are stored and accessed; both
IaC tools and some GUIs can be configured securely. The advantage lies in the automation and consistency of
secret handling, not in the mere existence of a GUI.
C – Provisions the same resources at a lower cost: Cost is determined by the underlying cloud/services and
design decisions, not by the provisioning method (IaC vs. GUI).
D – Prevents manual modifications to your resources: While IaC encourages declarative control and can
enforce changes via CI/CD pipelines, a GUI can also enforce policies or lock resources; however, it does not
offer the same systematic enforcement or auditability that version-controlled IaC provides.
References
Terraform documentation on state management and version control:
https://developer.hashicorp.com/terraform/language
AWS CloudFormation documentation on stacks and versioning: https://docs.aws.amazon.com/cloudformation/
These sources illustrate how IaC’s declarative, versionable nature enables capabilities that pure GUI-based
provisioning lacks.
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
Correct Answer:
D. Less complex infrastructure upgrades
Explanation:
Immutable infrastructure replaces resources rather than modifying them in-place, so an upgrade is
performed by creating a new set of infrastructure and retiring the old one.
This approach produces repeatable, auditable changes that are easier to plan, test, and roll back, reducing
the operational overhead associated with large, complex upgrade tasks.
The declarative state stored in a configuration management system (e.g., Terraform) remains simple-
upgrades are expressed as a new desired state, not as a series of incremental patches-hence they are less
complex to execute.
Option D-"Quicker infrastructure upgrades" is not the primary advantage; the speed gain may be incidental,
whereas the reduction in complexity is consistent and measurable.
Option A - "Automatic infrastructure upgrades" misleads because the upgrade still requires explicit
definitions and orchestration; it is not "automatic" in the sense of zero-effort.
Option B-"In-place infrastructure upgrades" directly contradicts the immutable model, which deliberately
avoids modifying existing resources.
Option C-"Quicker infrastructure upgrades" is not a guaranteed benefit; performance gains depend on
provisioning pipelines and can be offset by new resource creation latency.
Therefore, the correct answer is D - it highlights the central benefit of immutable infrastructure: simpler,
less complex upgrade processes.
References
HashiCorp Learn - Immutable Infrastructure: https://learn.hashicorp.com/terraform/cloud-infra/terraform-
state
Terraform Documentation - Immutable Resources:
https://developer.hashicorp.com/terraform/language/resources#mutable-vs-immutable-resources
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.
Correct Answer:
C. To programmatically create and configure resources.
Explanation:
Primary purpose of IaC
IaC enables the programmatic creation and configuration of infrastructure resources (servers, networks,
storage, etc.) through declarative code rather than manual processes. This makes provisioning repeatable,
version-controlled, and easily replicable across environments.
Why option C is correct
It directly describes IaC’s core capability: programmatically (i.e., via code/write-ups) defining the desired state
of infrastructure and creating and configuring the underlying resources to match that state.
Why the other options are less suitable
Conclusion
References
A. To define a pipeline to test and deliver software – This describes CI/CD pipelines, not IaC. IaC may be
integrated into pipelines, but its primary focus is infrastructure provisioning, not software testing or delivery.
B. To provision infrastructure cheaply – Cost efficiency can be a side effect of IaC, but “cheap” is a business
outcome, not the defining purpose. IaC can be used for costly architectures as well.
D. To define a vendor-agnostic API – IaC tools often support multiple clouds, yet they are not primarily about
exposing an API; they are about declaratively describing infrastructure, often tied to a specific provider or
tooling.
Option C best captures the essence of IaC: using code to programmatically create and configure resources.
HashiCorp Learn – What is Infrastructure as Code?
https://learn.hashicorp.com/tutorials/terraform/install-cli
Terraform Documentation – Introduction to Terraform
https://developer.hashicorp.com/terraform/tutorials/basics
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.
Correct Answer:
A. Deploying new infrastructure into Microsoft Azure.
Explanation:
Why optionA is the challenge
AWS CloudFormation only provisions resources that exist within the AWS ecosystem; it cannot directly
manage Azure services.
Introducing Azure requires a different IaC engine (e.g., Azure Resource Manager templates or Terraform),
adding cross-cloud complexity, extra toolchains, and operational overhead.
The team’s standardized workflow is built around CloudFormation’s native features, so extending it to a
non-AWS platform breaks that standardization.
Why the other options are not challenges
manual effort rather than creating difficulty.
References
B – Automating a manual, web-console process – This is precisely the purpose of CloudFormation; it reduces
C – Building a reusable code base for any AWS region – CloudFormation already supports regional
deployment through parameters, mappings, and stacksets, turning this into a capability, not a hurdle.
D – Managing a new AWS-native application stack – This aligns with the core use case of CloudFormation; it
leverages existing constructs and best practices without introducing new constraints.
AWS CloudFormation User Guide – Regions and Endpoints:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-regions.html
Overview of AWS CloudFormation Stack Sets:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets.html
Which is not a benefit of adopting laC (Infrastructure as Code)?
A
Reusability of code
B
Automation
C
A GUI (Graphical User Interface)
D
Versioning
Correct Answer:
C. A GUI (Graphical User Interface)
Explanation:
Why option C is not a benefit
Graphical User Interface (GUI) is not inherent to IaC – IaC models infrastructure as declarative code, which is
meant to be stored, reviewed, and executed programmatically. While some tools provide GUIs for
convenience, the core benefit of IaC does not depend on a graphical interface; it could be fully managed
through version-controlled scripts alone.
Why the other options are genuine benefits
A. Reusability of code – Modules, templates, and libraries can be shared across projects, enabling consistent
environments and reducing duplication of effort.
B. Automation – IaC eliminates manual provisioning steps; the same code can be applied repeatedly to spin
up, modify, or destroy resources automatically.
D. Versioning – Infrastructure definitions are treated as source code, so they can be tracked, rolled back,
reviewed, and tested in the same way as application code.
approach.
References
get-started/intro
Conclusion
Option C (A GUI) is not a fundamental advantage of Infrastructure as Code; it is merely an optional
convenience layer, whereas reusability, automation, and versioning are intrinsic capabilities of an IaC
HashiCorp Documentation – Terraform Overview: https://developer.hashicorp.com/terraform/tutorials/aws
Kubernetes Hardening Guide – Infrastructure as Code Best Practices:
https://kubernetes.io/docs/concepts/cluster-administration/manage-automation/#tools-for-automation
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.
Correct Answer:
A. Configuration drift is reduced with declarative definitions.
Explanation:
Why options A and C are correct
A – Configuration drift is reduced with declarative definitions –
Infrastructure as Code stores the desired state in version-controlled files (e.g., HCL, JSON, YAML). Terraform
required remediation, preventing unsolicited drift.
treats these files as the single source of truth, constantly reconciling the actual provisioned resources with
that declared state. When the real environment diverges, a terraform plan detects the mismatch and flags the
C – Proposed changes can be reviewed before being applied –
terraform plan generates an execution plan that lists every create, modify, or destroy action that would occur.
This preview lets operators audit the impact, verify dependencies, and confirm that the changes meet security
or compliance policies before they are persisted with terraform apply.
Why the other options are less suitable
B – Updates are deployed with zero downtime –
Terraform itself does not guarantee zero-downtime deployment; achieving that requires additional patterns
(e.g., rolling updates, load-balancer shifting). Terraform’s role is to provision the desired resources, not to
manage runtime availability during the update.
D – Incorrect configurations cannot be deployed –
While a plan can catch syntax errors or dependency issues, Terraform cannot prevent logical or
business-logic mistakes that are not manifest in the configuration language. Incorrect resource properties
may still be applied if they are syntactically valid.
automatically adjust capacity in response to demand.
References
E – Infrastructure is automatically scaled to meet demand –
Autoscaling is a runtime capability of cloud services (e.g., AWS Auto Scaling, Azure Scale Sets). Terraform
can provision scaling resources, but the scaling logic must be defined separately; Terraform does not
Terraform State & Drift Detection – https://developer.hashicorp.com/terraform/language/state/drift
Terraform Plan & Apply Workflow – https://developer.hashicorp.com/terraform/language/works/plans
These documents detail how declarative state management mitigates drift and how Terraform plans enable
pre-apply reviews, directly supporting the rationale above.
Your team often uses API calls to create and manage cloud infrastructure.
In what ways does Terraform differ from conventional infrastructure management approaches?
A
Terraform replaces cloud provider APIs with its own protocols, enabling automated deployments.
B
Terraform describes infrastructure with version-controlled, repeatable configurations that specify the
desired state.
C
Terraform is merely a wrapper for cloud provider APIs, so there is little to no difference in calling the API
directly.
D
Terraform enforces infrastructure through imperative scripts to ensure tasks are completed in the proper
order.
Correct Answer:
B. Terraform describes infrastructure with version-controlled, repeatable configurations that specify the
desired state.
Explanation:
Why optionB is correct
expressed in plain text files.
Terraform uses a declarative configuration language (HCL) where the desired infrastructure state is
These files are version-controlled, enabling reproducible builds, audit trails, and collaborative workflows.
The Terraform engine compares the declared state with the actual provider state and
creates/updates/destroys resources only as needed to achieve convergence, abstracting away the details of
individual provider APIs.
Why the other options are less suitable
OptionA – Terraform does not replace provider APIs; it uses them under the hood. Its power comes from the
declarative model, not from inventing new protocols.
OptionC – While Terraform ultimately calls provider APIs, it adds a layer of abstraction (state management,
plan/apply workflow, dependency graph) that shields users from direct, imperative API calls.
OptionD – Terraform is not imperative; it does not rely on scripts that manually sequence actions. Instead, it
calculates a plan and applies changes in a declarative, idempotent manner, ensuring the correct order only
when required by dependencies.
References
Terraform Documentation – Overview of the Planning and Applying Process
https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli
Terraform Documentation – State Management and Remote State
https://developer.hashicorp.com/terraform/language/state
These links provide the official, up-to-date explanations of Terraform’s declarative approach and its
state-driven behavior, supporting the rationale above.
Which of these workflows is only enabled by the use of Infrastructure as Code?
A
Automatic scaling of resources based on application load.
B
Cost optimization of infrastructure deployment.
C
Role-based access control of cloud resources.
D
Reviewing the proposed changes for potential security issues.
Correct Answer:
D. Reviewing the proposed changes for potential security issues.
Explanation:
Why D is correct - Only Infrastructure asCode makes every change explicit, version-controlled, and
previewable. Terraformplan generates a detailed execution plan that can be reviewed (by humans or
automated policy engines) before any resource is created or modified, allowing security teams to spot unsafe
configurations, privilege escalations, or mis-aligned network rules early. This pre-execution security review is
a direct consequence of laC tooling.
Why A, B, C are not exclusive to laC -
Automatic scaling (A) can be achieved with native services (e.g., Auto Scaling groups, Lambda triggers)
without laC; laC merely provisions the scaling rules.
Cost optimization (B) is a business/ops practice that may leverage laC for repeatability but is not inherent to
laC itself.
RBAC (C) can be applied manually or via IAM policies outside of code; laC only provides a way to express
those policies programmatically.
Why the laC-enabled review is unique - The plan-stage output is deterministic and can be integrated with
policy-as-code (e.g., Sentinel, OPA) to automatically flag violations, something that cannot be done reliably
without a declarative, version-controlled representation of the infrastructure.
References
Terraform Planning and Diff: https://developer.hashicorp.com/terraform/cli/commands/plan
Policy as Code with Sentinel: https://developer.hashicorp.com/terraform/language/policy-sets/sentinel
Questions: 1-10 out of 331
Continue Full Practice..
GET ALL 331 QUESTIONS