How to Build IaC Automation Pipelines for Modern

Infrastructure
11 July 2025 - ID G00826040 - 41 min read
By: Lucas Albuquerque
Initiatives:IT Operations and Cloud Management for Technical Professionals; Software
Architecture and Integration for Technical Professionals

Modern infrastructure automation requires practitioners to

embrace new approaches in order to ensure consistency and
governance. This research will help infrastructure platform
engineers to implement effective automation pipelines for
infrastructure as code automation.

Overview
Key Findings
■ Multicloud and hybrid infrastructures are now the standard, necessitating intricate
automation pipelines that integrate diverse, complex toolkits.

■ Practitioners must combine various infrastructure automation and orchestration

techniques to build a comprehensive strategy for security, compliance, observability
and self-service.

■ Though infrastructure as code (IaC) is not a novel practice, its use at scale to
support complex environments is challenging. Practitioners often struggle to find the
optimal balance between autonomy and governance.

■ Proficiency in declarative IaC and scalable automation is a prerequisite for adopting

modern DevOps and platform engineering practices. The general lack of such skills
hinders initiatives such as internal developer portals and platforms.

Gartner, Inc. | G00826040 Page 1 of 33

Recommendations
■ Design your IaC automation as software-defined workflows that oversee the
complete component life cycle, from artifact management and provisioning to
ongoing operation.

■ Ensure all infrastructure is declared in code and managed using software

development principles and practices. Infrastructure-related artifacts must be
designed as reusable components following a product-oriented mindset.

■ Enforce security and compliance as an integral part of the workflows, ensuring an

optimal balance of autonomy and control. Integrate guardrails, testing and drift
detection to prevent impromptu deployments, shift left quality assurance (QA) and
catch inconsistencies during infrastructure continuous deployment.

■ Invest in hands-on training and workshops focusing on declarative and reusable IaC
tools to empower teams with the skills needed for efficient and automated
infrastructure management. Embrace infrastructure platform engineering (IPE) to
gain scale and standardize practices.

Problem Statement
IaC represents elements of infrastructure with software constructs, such that these
elements can be managed using the same techniques and life cycle as software.

Practitioners provision and manage computing infrastructure in code by defining

resources using human-readable definition files or general-purpose programming
languages. Once the resources are described in code, practitioners manage the
infrastructure components by following software development practices, leveraging
source code management (SCM) to store and control changes and utilizing automation
for deployment.

Due to these attributes, organizations of all sizes have adopted IaC with the promise that
it will accelerate cloud adoption, consolidate and scale management practices and
implement better governance.

Gartner, Inc. | G00826040 Page 2 of 33

 IaC is an overloaded term that encompasses many practices.
Simply saying, “We do IaC” does not guarantee better practices
being implemented. Hence, enabling IaC alone does not guarantee
maximum benefit. Adopting IaC at scale requires modular, version-
controlled, well-documented and automated practices, combined
with rigorous testing, parameterization and standardization.

While the desire to prescriptively manage infrastructure is common, practitioners often

still struggle to adopt IaC efficiently at scale. The typical challenges faced include:

■ The use of imperative practices: The imperative approach uses procedural

techniques that describe the steps required to reach a desired end state. It is
commonly implemented using scripting (for example, Shell, Python and Ruby) or
specialized tooling. It opposes declarative methods that specify what the desired
end state should be, but not how to get there. Although effective for troubleshooting
and testing scenarios, the imperative approach may lack the consistency and
predictability offered by declarative methods, thereby hindering adoption at scale.

■ Inadequate execution: Though practitioners can opt for provisioning resources from
their local execution environments using command line interface (CLI) tooling (for
example, AWS Command Line Interface [AWS CLI], Microsoft Azure command-line
interface [Azure CLI], Google Cloud CLI [gcloud CLI] and Broadcom’s ESXCLI), this
approach is not scalable. Managing infrastructure resources using code requires
conformable workflows encompassing both predeployment and postdeployment
actions and, in some cases, also offering state management. 1 Using automation
pipelines — a set of automated workflows that streamline and standardize
processes by executing a series of predefined steps without manual intervention — is
crucial for IaC execution on a large scale.

■ Subpar composability: Even when executed using automated approaches, most

workflows are designed as a rigid sequence of steps defined in a monolithic manner.
This design pattern hinders the adoption of reusability practices, resulting in
fragmented governance and QA practices. The use of abstraction, modularity and
product design enables faster and more efficient IaC execution.

Gartner, Inc. | G00826040 Page 3 of 33

■ Managing automation complexities: Designing conformant IaC automation
workflows is a complex process, as it may require practitioners to combine varied
tooling — such as one tool for the provisioning, another for configuration
management and another for policy-as-code. Though infrastructure orchestration
and collaboration have emerged as an alternative to offloading IaC automation
complexities from practitioners, they do not serve all use cases (for example,
whenever highly customizable and specialized workflows are required).

■ Balancing autonomy and control: Though standardization favors governance, one-

size-fits-all approaches rarely address teams’ expectations of self-governance.
Finding the optimal balance between autonomy and control has been challenging
for many IaC automation initiatives aiming to empower platform consumers while
ensuring security and governance.

Mastering IaC automation is a foundational step for any

organization considering scaling advanced practices, such as
DevOps, site reliability engineering (SRE) or IPE, as they all have
automation as a core attribute. Hence, teams still in the early
stages of IaC enablement and automation are likely not yet mature
enough to consider any of these advanced practices.

Quick Answer
How can I reliably automate my IaC deployments?

Implementing adequate IaC automation requires using software engineering practices

for code management, in addition to modular workflows used in combination with
reliable execution practices capable of guaranteeing predictable and conformant
deployment workflows.

The Gartner Approach

IaC is a generic term commonly used to describe any initiative leveraging prescriptive
methods (such as code) for describing infrastructure components for further deployment.
As it may take different forms and shapes, IaC is therefore not uniform. This can lead
vendors and practitioners to propose distinct, sometimes conflicting, practices for
streamlining resource deployment and operations.

Gartner, Inc. | G00826040 Page 4 of 33

In terms of infrastructure automation and orchestration capabilities, the tools supporting
IaC automation usually fall into three distinct categories (see Market Guide for
Infrastructure Automation and Orchestration Tools for more information):

■ Provisioning automation: Enables DevOps and infrastructure and operations (I&O)

teams to deliver automated infrastructure services across on-premises and cloud
environments.

■ Configuration automation: Ensures target resources are configured according to

predetermined blueprints and automatically reconciles inconsistencies, achieved
through specialized configuration management tooling.

■ Infrastructure orchestration: Enables platform and I&O teams to design, deliver,

operate and assure orchestrated services across hybrid deployment topologies.

Modern infrastructure management requires practitioners to apply software engineering

fundamentals to support scalable and reliable automation. In addition to considering the
desired capabilities and design patterns, practitioners must also acknowledge that
automating IaC in a scalable and reliable manner is the result of a thoughtful process that
minimally comprises the following aspects:

■ Automation design: Also an umbrella term, automation implies the execution of

predefined tasks through automated control without (or with minimal) human
intervention. Applied to the context of IaC, automation can be implemented using
different techniques that can vary significantly depending on the introduced
abstractions, governance requirements, actors involved and where the execution will
occur.

■ Continuous integration (CI): CI, which is commonly associated with the software
development life cycle (SDLC), can benefit IaC practitioners. CI principles can help
guarantee the consistent adoption of standards and routines for infrastructure.
Because infrastructure resources should ideally be declared and managed in code,
practitioners must leverage CI practices to implement QA and governance.

■ Continuous deployment (CD): CD into an IaC workflow is the last mile of a release
process and comprises all the necessary activities to apply the required changes to a
destination infrastructure in an automated and reliable manner.

Gartner, Inc. | G00826040 Page 5 of 33

Gartner recommends I&O practitioners seeking to streamline their IaC practices follow the
proposed framework outlined in this research. The framework presents, in a
comprehensive manner, the stages and steps expected for a state-of-the-art IaC
automation workflow. We encourage you to follow the given order, though doing so is not
mandatory.

When designing IaC workflows, the challenge is less about tooling

syntax and more about product thinking. For example, integrating
IaC into modern SDLCs, building secure and scalable patterns,
orchestrating resources across multiple environments and
effectively supporting product teams and business outcomes.

The Guidance Framework

Gartner has seen growing demand from I&O practitioners seeking guidance on efficiently
using IaC to provision and operate their infrastructure resources, whether in the cloud or
on-premises. A significant portion of those practitioners reference frustrating experiences
with IaC when they were not able to benefit from its adoption. They want to understand
how other organizations across industries have applied IaC to operate their infrastructures
and how they overcame the associated hurdles.

Clients looking to upscale their IaC automation practices ask about the best practices for:

■ Designing reliable and efficient workflows for IaC automation.

■ Codifying guardrails and compliance policy.

■ Configuring monitoring and auditing.

■ Ensuring secure execution environments for reliable provisioning, updating and

reconciliation of infrastructure resources.

To assist these practitioners, Gartner proposes a vendor-agnostic and actionable guidance

framework comprising four stages (see Figure 1, and use the links below to jump to the
related sections) and respective practices:

■ Designing automation

Gartner, Inc. | G00826040 Page 6 of 33

■ Continuous integration

■ Continuous deployment

Figure 1: Guidance Framework for Building IaC Automation Pipelines

Using this framework, practitioners can familiarize themselves with the stages comprising
a state-of-the-art automation design for IaC deployments. Each stage depicts relevant
practices, and each practice lists the measures commonly adopted by practitioners at
different maturity stages.

In addition to validating the IaC definitions, the CI practices must include automated
testing for the applications impacted by a configuration change, which must be validated
as a result of the change.

Designing Automation
Reliable and efficient workflows for IaC automation are a result of a cohesive integration
of practices and patterns:

Gartner, Inc. | G00826040 Page 7 of 33

■ In addition to being consistent and repeatable, modern infrastructure automation
also requires workflows to be reusable. Such reusability aims to help organizations
standardize workflows and promote an off-the-shelf experience following IPE
practices.

■ To gain scale, IaC combines DevOps methodology and software engineering

practices to develop and maintain reusable workflows designed as consumable
artifacts.

■ Finally, practitioners must understand that designing modern automation workflows

for infrastructure is a collaborative effort requiring clearly defined responsibility
models that encompass a range of scopes and stakeholder obligations.

Figure 2 illustrates a typical automation workflow for IaC deployments divided into three
distinct stages: inner-loop, continuous integration and continuous deployment.

Figure 2: A Model IaC Automation Workflow for Modern Infrastructure

The Three-Day Model

As a modern practice, IaC automation must rely on composable and programmable
infrastructures leveraging software engineering practices to implement a product-centric
approach to infrastructure management.

Gartner, Inc. | G00826040 Page 8 of 33

To adopt this mindset, practitioners must embrace IPE practices and implement a three-
day model — as a ramification of platform engineering practices — to help users develop
a product-oriented approach for infrastructure matters.

IPE is a discipline branched from platform engineering (PE), involving building internal
software products that present IT infrastructure to end users or other platforms in an
easily consumable way. Infrastructure platform products are self-service tools that allow
nonexpert users to deploy and manage infrastructure themselves, while I&O provides
governance, security and compliance.

The three-day model applied to IPE is rooted in the belief that modern infrastructure
management can be divided into three distinct moments (referenced as days) to facilitate
comprehension. The scope of these three days is as follows:

■ Day 0 (ideation and planning): This day represents the ideation, planning and
development of reusable artifacts that will be consumed in the following days. It
uses a demand-centric mindset, meaning consumers’ demand drives platform
capabilities, rather than assumptions made by I&O practitioners. Every consumable
code, tool or offered service responds to the IPE team’s needs obtained from end
consumers.

■ Day 1 (provisioning): On this day, practitioners leverage the reusable components

developed on Day 0 (for example, modules, templates, classes and images) to
provision infrastructure resources in a self-service manner. These distributable
artifacts are obtained from reusability layers maintained by the IPE teams (for
example, source code repositories, registries and artifact managers) that are
accessible by consumers (such as product teams, other I&O practitioners or external
consumers).

■ Day 2 (operation): Day 2 represents the actions taken to operate the infrastructure
resources provisioned on the previous day. Like Day 1, practitioners can harness
reusable components to manage the deployed resources, including release
management, upgrades, drift detection, monitoring and scaling. In an ideal scenario,
the same artifacts used to support Day 1 should also be applied to support Day 2
concerns. For instance, the same OpenTofu (Linux Foundation) module used to
provision a resource must also be utilized to manage it, thereby ensuring operational
consistency.

Gartner, Inc. | G00826040 Page 9 of 33

 For scalable and reliable IaC automation, practitioners must
embrace the three-day model to give their initiatives a temporal
perspective. This will help teams understand that complex
initiatives, such as IaC deployment workflows, comprise a set of
loose but interdependent stages.

The proposed three-day model can help I&O practitioners structure their automation
practices. On Day 0, IPE teams can develop reusable CI/CD templates, IaC artifacts and
other components that can be reused across different workflows and offered through self-
service interfaces. On Days 1 and 2, practitioners will compose their automation
workflows by combining the reusable components either directly or bundled into
blueprints, paved roads or landing zones (see Figure 3).

Figure 3: Designing IaC Automation: Reusability

Gartner, Inc. | G00826040 Page 10 of 33

Using modular pipeline components natively offered by consolidated automation
platforms (for example, GitHub Actions workflow templates, GitLab CI/CD Catalog and
Jenkins Shared Libraries) can help practitioners introduce new capabilities and
experiment with new features gradually. IPE teams can develop reusable, single-purpose
pluggable templates (such as linting, SAST, container build, Terraform execution and drift
detection) that can be stacked to form use-case-oriented infrastructure workflows.

However, practitioners must consider that IPE is not suitable for all organizations and may
be excessive in some scenarios (see the Risks and Pitfalls section of this research for
more information). Empowering technical teams with self-service capabilities through
platform engineering principles requires IT to be willing and able to apply software
engineering practices to I&O and also internalize a DevOps culture.

In cases when IPE adds unnecessary complexity, a platform automation approach

becomes a potential alternative. Figure 4 depicts the IPE journey from traditional I&O to
IPE adoption, positioning platform automation as a step in between (see How to Structure
Your Infrastructure Platform Engineering Journey for more information).

Figure 4: The Infrastructure Platform Engineering Journey

Orchestration Techniques
Practitioners looking to streamline infrastructure provisioning and operations must assess
and select an orchestration approach that best aligns with their automation strategy and
target deployments.

Gartner, Inc. | G00826040 Page 11 of 33

Infrastructure orchestration initiatives comprise services, platforms and tools capable of
coordinating the life cycle of all infrastructure components, including provisioning,
operations, scaling and decommissioning. I&O practitioners evaluating orchestration
approaches for infrastructure must consider the following alternatives:

■ Infrastructure automation pipelines: Leverage general-purpose DevOps platforms to

choreograph and orchestrate the execution of predefined tasks against predefined
target environments. As adaptable components, these CI/CD pipelines can be
customized to support different use cases, including infrastructure automation.
Practitioners can design and execute pipelines containing tasks to provision
resources on top of a target infrastructure. Once resources are declared in code
following IaC principles, practitioners can leverage DevOps platforms (for example,
Jenkins, GitHub Actions, GitLab CI/CD, Harness CI, Tekton and Woodpecker CI) to
streamline infrastructure provisioning. As automation platforms are merely
orchestrators, they commonly leverage CI/CD runners for task execution, making
provisioning possible for cloud or on-premises infrastructure.

■ IaC-specialized automation platforms: IaC-specialized automation platforms aim to

solve problems associated with operating IaC at scale. These platforms aim to
abstract some automation complexities associated with general-purpose
automation platforms. Though offerings such as Terraform Cloud and Terraform
Enterprise from HashiCorp only support Terraform, practitioners can opt for neutral
initiatives that extend the coverage to other IaC tooling, such as OpenTofu, Amazon
Web Services (AWS) CloudFormation, Pulumi and Ansible. These initiatives include
Spacelift, Harness, Firefly, Quali Torque, Scalr, env0 and Terrakube. These offerings
generally offer a runtime environment, specialized runners, state management,
secret injection, role-based access control (RBAC) and separation of concerns.

■ Control loop automation: The control loop pattern lies in specialized controllers
implementing a desired state approach capable of provisioning and reconciling
infrastructure. Initiatives implementing such a pattern constantly “watch” a resource,
guarantee adherence to a predefined desired state and reconcile the system back to
its declared state, if drift is detected. Initiatives such as Upbound Crossplane and
Kratix are multiplatform tools that implement the universal API pattern through
custom and extended Kubernetes (K8s) constructs to manage inner and outer cluster
resources. Practitioners declare their desired cluster configuration using YAML Ain’t
Markup Language (YAML) manifests and leverage GitOps to ensure consistency.
Initiatives such as AWS Controllers for Kubernetes (ACK), Microsoft Azure Service
Operator (ASO) and Google Cloud Config Connector implement a vendor-driven
pattern implementation.

Gartner, Inc. | G00826040 Page 12 of 33

While pipelines are the most adopted infrastructure automation approach due to their
versatility and track record, specialized IaC automation platforms are gaining traction due
to their potential to abstract IaC complexities and facilitate operation at scale. As an
emerging process, the control loop approach is still restricted to trailblazer practitioners,
although it perfectly adheres to platform engineering requisites (see Reference
Architecture Brief: Infrastructure Automation and Orchestration for more information).

Actors and Collaboration

Unlike traditional automation, modern infrastructure delivery is collaborative across
different practices. As autonomy is paramount for product teams leveraging modern
methodologies and practices (such as Agile and DevOps), I&O practitioners must equip
product teams with the means to promote self-sufficiency.

However, I&O teams commonly struggle to find the ideal balance between autonomy and
control. Limited autonomy leads to dependency that impacts efficiency. Such a lack of
clarity on enabling controlled autonomy for platform tenants is a common source of
conflict between I&O practitioners and product teams.

If poorly scoped, autonomy leads to the fragmentation of practices, with teams acting in
isolation with little to no collaboration, thereby ultimately promoting inefficiency:

■ IPE team: To achieve an ideal balance between autonomy and governance, IPE
teams must nurture a demand-centric mindset driven by customer needs — with no
room for assumptions. Every consumable code, tool or service responds to demands
the IPE team obtains from end consumers, such as product teams. The
infrastructure automation workflows developed and maintained by IPE — whether
based on pipelines, specialized platforms or control loops — must be offered as
consumable components after comprehending consumers’ needs and expectations.

■ Platform consumers: Product teams and DevOps practitioners are the two most
common consumers of the reusable components developed and maintained by IPE
teams. These users will leverage the interfaces (such as portals, CLI tools and APIs)
and guidance offered by IPE teams to self-service from the infrastructure
automation components — such as templates, blueprints or boilerplates — that
implement the desired workflows. Considering the level of abstraction significantly
varies from case to case, the automation approach selection must be based on
consumers’ willingness for exposure to automation internals (refer to the
Orchestration Techniques section of this research for more alternatives).

Gartner, Inc. | G00826040 Page 13 of 33

As end-to-end infrastructure provisioning seldom involves the use of a single tool or sole
artifact, IPE teams commonly develop use-case-oriented bundles that package together
all the elements required to streamline deployments. The use of such bundling
techniques is described in Reference Architecture Brief: Infrastructure Automation and
Orchestration’s Infrastructure Reusability section.

Execution Environments
Environments are abstractions representing a collection of resources used to run
applications and services, whether physical or logical. Although most IaC tools offer
command-line interfaces (CLI) allowing practitioners to execute them from their local
workstations, it is recommended they instead use special-purpose execution
environments. In addition to including tools and dependencies, specialized environments
may offer additional capabilities such as always-fresh execution contexts, specific
computing resources, consistent runtime environments, access to short-lived credentials,
statefulness support and workload segregation, among other possibilities.

When selecting an execution environment for running IaC, practitioners must consider the
following:

■ Local versus remote: While local IaC execution is a valid alternative for facilitating
one-off task executions, experimentation and troubleshooting, it is not a reasonable
option for production scenarios. Remote execution allows for IaC execution using
standard environments, ensuring conformity, consistency and predictability for
deployments. A widely adopted approach is leveraging DevOps platforms to
implement automation pipelines that respond to changes applied to IaC definitions
stored on Git repositories, with all execution happening remotely, at the platform side
(see Orchestration Techniques for more information).

■ Shared versus dedicated: Managed automation platforms commonly offer

practitioners native runners, on top of which execution environments run and are
entirely managed by vendors. To achieve maximum resource utilization, most
vendors adopt a multitenant approach that enables execution environments from
different clients to share the underlying resources. Although vendors implement
isolation measures, some practitioners might require using dedicated runners
operated by them, whether on-premises or in the cloud. In dedicated scenarios,
practitioners must integrate runners into the automation platforms’ management
plane to allow self-managed runners to execute IaC-associated jobs.

Gartner, Inc. | G00826040 Page 14 of 33

■ Long-living versus ephemeral: Whether execution environments are local or remote
and implemented as shared or dedicated resources, practitioners can opt for long-
living or ephemeral approaches. While the long-living execution environments for IaC
can accelerate provisioning by caching dependencies, resources are left idle between
jobs and during off-peak hours, which subsequently raises costs. Also, as different
pipelines reuse environments, there is a risk of leftovers from previous jobs
interfering with future ones. Conversely, using ephemeral environments offers a
more efficient use of resources. It ensures always-fresh environments, at the
detriment of slower instantiation time, which might be relieved through container-
based approaches.

■ Container-based environments: As self-contained, lightweight and portable artifacts,

containers can ensure consistency across environments and simplify deployments.
Hence, practitioners can leverage containers to create specialized toolkits for IaC
execution (see How to Select Container-Based Development Environment
Approaches for more information). These off-shelf container images can instantiate
ephemeral execution environments for IaC deployments, which is an approach
supported by all mainstream DevOps platforms (for example, GitHub Actions, GitLab
CI/CD and Jenkins).

■ Sandboxing: Though most multitenant execution environments offer workload

segregation capabilities, there may be cases when organizations may require
additional isolation. Sandboxing techniques enhance multitenant environment
security by concealing task execution in a highly restricted environment. Thus, they
prevent workload cross-interference and reduce the risks of compromising the host
system (see Reference Architecture Brief: Cloud-Native Infrastructures Using
Containers for more information).

Continuous Integration
Though commonly associated with SDLC, CI can be equally applied to help infrastructure
practitioners to automate QA, enforce governance and promote standards. Through CI
pipelines, practitioners can minimally:

■ Shift left testing for IaC: Moving IaC testing activities to find and prevent defects
earlier in the development process improves software quality, ensures better test
coverage and enables continuous feedback. This helps identify syntax errors,
configuration issues or other problems early in the development and further
deployment process, thereby reducing the risk of deploying faulty infrastructure.

Gartner, Inc. | G00826040 Page 15 of 33

■ Prevent IaC drifts and inconsistencies: This ensures the infrastructure codebase
remains consistent and reliable, and also helps detect and eventually fix
configuration drift. In addition, it assists with tracking changes and maintaining a
clear history of modifications. CI pipelines can further enhance this by automatically
integrating and testing these changes.

■ Enforce IaC governance: Pipelines can include security rules, criteria and conditions
to ensure IaC conformance. This ensures all changes are evaluated against security
policies and predefined standards, which subsequently identifies bad practices,
configuration errors and vulnerabilities in the declared resources.

Ensuring quality, enforcing governance and promoting standards for IaC at scale is not a
trivial task. CI for infrastructure must combine specialized tooling and reusability
techniques to integrate security benchmarking, cost control, policy enforcement and
dependency tracking.

Inner-Loop
As a general definition, inner-loop development refers to the iterative, rapid cycle of coding,
building and testing that developers conduct from their isolated development contexts,
using their preferred environments and tools (see Adopt Platform Engineering to Improve
the Developer Experience for more information).

Transporting the concept to an IaC context, IPE teams leverage inner-loop environments
for developing reusable components (such as modules, packages and templates).
Likewise, infrastructure consumers can use their isolated development environments to
declare the to-be-provisioned resources.

Since most development uses Git local branches, practitioners are encouraged to push
some CI task execution to the inner loop before pushing the IaC definitions to remote
repositories (outer loop).

For effective CI tasks in inner loops, practitioners must consider the following approaches:

Gartner, Inc. | G00826040 Page 16 of 33

■ IDE extensions: Software components that add specific capabilities or features to an
integrated development environment (IDE), thereby introducing additional
functionalities or integrations. In IaC scenarios, practitioners can extend IDE support
by enabling tooling-specific syntax highlighting and linting, which enforces coding
standards and automatically formats code. Table 1 contains popular IDEs, their
respective marketplace and some extensions for IaC.

■ Precommit hooks: Scripts or programs that run automatically before a commit is

made in a version control system, such as Git. They allow practitioners to automate
IaC tasks and enforce policies within their version control workflows, such as code
QA and governance. Hooks can execute linting, formatting and static analysis tools,
run tests, detect sensitive information (for example, passwords or API keys) and
much more. After installing precommit, practitioners can instrument their local
development environments by adding IaC-oriented hooks, such as: 2

■ antonbabenko/pre-commit-terraform: Runs checks locally when you try

committing your Terraform code

■ bridgecrewio/checkov: Automatically runs Checkov whenever files in your Git

repository change

■ gitleaks/gitleaks: Precommit hooks to automatically detect and prevent

sensitive information

■ trufflesecurity/truffleHog: Precommit for Truffle Security (TruffleHog)

credentials scanner

■ aws-cloudformation/cfn-lint: Precommit validation of AWS CloudFormation

templates

■ stackrox/kube-linter: Static analysis tool that checks Kubernetes YAML files

and Helm charts

■ ansible-community/ansible-lint: Ansible linting precommit

■ rhysd/actionlint: Lints your GitHub Actions workflow files

■ google/yamlfmt: A formatter for YAML files

Gartner, Inc. | G00826040 Page 17 of 33

Table 1: IDE extensions for IaC

IDE Where to find Popular IaC extensions

Visual Studio Code Extensions for Visual Terraform, OpenTofu,

(Microsoft) Studio Code (Microsoft Gruntwork (Terragrunt),
Visual Studio Code) Aqua Security (tfsec)Tfsec,
Palo Alto Networks (Prisma
Cloud [Checkov]), Ansible,
Azure Bicep and
Kubernetes.

IntelliJ IDEA (JetBrains) JetBrains Marketplace Terraform and HCL, Ttfsec

Findings Explorer, Ansible,
AWS CloudFormation and
Kubernetes.

Eclipse IDE (Eclipse Eclipse Marketplace Terra Architect, Snyk

Foundation) Security and Kubernetes
Manifest Editor.

Source: Gartner (July 2025)

Though using IDE extensions and precommit hooks is considered best practice, the lack
of control over development environments to install these tools hinders implementation.
Alternatively, practitioners are encouraged to integrate the above-described tools into pull
request pipelines (see the Static Application Security Testing and Linting section of this
research for more information).

Static Application Security Testing and Linting

While linting offers syntax error, formatting problem and bug detection capabilities, static
application security testing (SAST) uses static analysis techniques to identify security
risks, including threats from unsecured coding practices. Static analysis tools examine the
code without executing it and provide code quality measures, structural assessment and
security vulnerability detection (see Use Code Analysis Tools to Reduce Technical Debt
and Improve Quality for more information).

IaC-specialized code analysis tools can detect and report on particular aspects of the
code, such as identifying security vulnerabilities, misconfigurations and compliance
issues (see Reference Architecture Brief: DevSecOps Platform for more information).

Gartner, Inc. | G00826040 Page 18 of 33

Practitioners must integrate security testing tooling for IaC into their CI workflows,
preferably on pull requests. IaC definitions are analyzed and approved using pull request
pipelines before the code is merged, reducing the need for rollbacks and preserving the
code stored in protected branches.

Table 2 lists tools that can help practitioners analyze their IaC definitions:

Table 2: Representative IaC Linting and SAST Initiatives

IaC linting IaC SAST

■ actionlint for GitHub Actions ■ Checkov

■ ansible-lint ■ cfn_nag

■ Bicep linter ■ cdk-nag

■ cfn-lint ■ Cycode

■ Dockerfile Linter ■ GitLab IaC Scanning

■ helm lint ■ Checkmarx (Keeping Infrastructure as

Code Secure [KICS])
■ KubeLinter
■ Kubescape
■ terraform validate
■ Orca Security
■ TFLint
■ Semgrep

■ Snyk IaC

■ Sysdig

■ Tenable

■ Tenable (Terrascan)

■ TFLint

■ tfsec

■ Aqua Security (Trivy)

Source: Gartner (July 2025)

Policy as Code

Gartner, Inc. | G00826040 Page 19 of 33

As adoption of IaC practices increases, organizations feel pressured to enforce standards
in the infrastructure release cycle. Introducing guardrails based on security policies,
continuous compliance and conformance assurance becomes essential to the IaC
governance strategy.

Infrastructure practitioners can use compliance as code (CaC) to ensure IaC definitions
adhere to enterprise policies and regulations. Practitioners can also introduce guardrails
for infrastructure provisioning and ensure compliance by enforcing organization-specific
guidelines that prevent policy violations and the misuse of enterprise resources.

Policy as code (PaC) leverages declarative methods and specialized engines to dictate
resource rules and constraints, ensuring compliance with regulatory standards, security
guidelines and other external demands. Practitioners can apply policies against IaC
definitions in two ways:

■ Pipeline enforcement: Policy engines are integrated into CI pipelines to detect and
notify practitioners when violating rules and constraints. CI pipelines execute
command-line policy engines or invoke external services that can validate IaC as a
workflow stage.

■ Platform enforcement: Policies are declared in code and pushed to a target

platform, which will assess whether the requests are admissible. This approach
mainly relies on platform-native services as part of the CD workflow.

Practitioners can combine pipeline or platform enforcement approaches with their IaC
workflows. However, implementing PaC simultaneously at the CI and CD stages may
increase complexity and hinder troubleshooting.

Table 3 contains a selection of representative policy enforcement initiatives that can be

integrated into existing pipelines or enforced at the platform level.

Gartner, Inc. | G00826040 Page 20 of 33

Table 3: Representative Policy Enforcement Initiatives

Pipeline enforcement Platform enforcement

■ HashiCorp Sentinel ■ Azure Policy

■ Regula ■ AWS Control Tower and AWS

Organizations
■ Kyverno CLI
■ Kyverno
■ AWS CloudFormation Guard
■ OPA Gatekeeper
■ Open Policy Agent (OPA) Conftest

■ terraform-compliance

■ Pulumi CrossGuard

■ Dockerfile-audit

■ Tenable Terrascan

Source: Gartner (July 2025)

Mocking and Testing

Since IaC allows infrastructure to be defined and managed using code, it can be tested
using methodologies and tools similar to application code. Ideally, those tests must be
executed on top of dynamic and isolated environments that mock production scenarios.

Infrastructure mocking uses software abstraction techniques to simulate the behavior of

infrastructure components (for example, servers, databases, networks and other external
services). Infrastructure practitioners can rely on mocking tools to create proxy
environments for testing their IaC definitions in complete isolation.

Though the use of mocking and testing techniques is a consolidated practice among
software development teams, their adoption among infrastructure practitioners is still
timid. This is mainly due to the lack of software engineering skills presented by typical
infrastructure practitioners, who struggle to deal with the abstractions required to
incorporate these practices into their IaC workflows.

Infrastructure teams can apply the same testing practices adopted by software
engineering to test their IaC definitions, such as:

Gartner, Inc. | G00826040 Page 21 of 33

■ Unit testing: Tests individual infrastructure code components or modules to ensure
they behave as expected (see Shift Quality Further Left With Behavior-Driven
Development and Shift Left With Test-Driven Development for more information).

■ Integration testing: Validates that different components of the infrastructure work

together as intended. It often involves deploying the infrastructure in a test
environment to verify service interactions.

■ End-to-end (E2E) testing: This involves testing the entire infrastructure setup to
ensure it meets the desired requirements and functions correctly in a real-world
scenario. It may include deploying the whole stack and running application-level
tests to validate infrastructure behavior.

■ Security testing: Identifies security vulnerabilities and misconfigurations in the

infrastructure code (see the Static Application Security Testing and Linting section of
this research and Improve Application Security With Posture Management Tooling
for more information).

■ Compliance testing: Ensures the infrastructure adheres to organizational policies

and regulatory requirements (see the Policy as Code section of this research for
more information).

■ Performance testing: Evaluates the infrastructure’s performance characteristics,

such as scalability and reliability. It may involve stress testing and load testing in a
controlled (mocked) environment (see Embed Continuous Performance Testing in
Software Development for more information).

Some representative initiatives for IaC testing (such as unit, integration and E2E) that can
integrate into automation workflows are:

■ Terraform: Terraform tests, Gruntwork (Terratest), Kitchen-Transform, Clarity,

Terraform Test Framework

■ AWS CloudFormation: TaskCat

■ Ansible: ansible-test

■ Kubernetes: KUDO Test Harness, Testkube, KUbernetes Test TooL (KUTTL), Kyverno
Chainsaw

■ Helm: helm test, Chart Testing, helm unittest

Gartner, Inc. | G00826040 Page 22 of 33

■ Pulumi and AWS CDK: These initiatives use general-purpose programming
languages to provision resources. Hence, they can take advantage of native testing
frameworks and perform automated tests for infrastructure.

Infrastructure mocking is often used with other testing strategies — such as unit testing,
integration testing and CI/CD pipelines — to ensure IaC validation. Initiatives include:

■ LocalStack: An emulator that runs in a single container in CI environments. It

currently supports emulating AWS, Snowflake and Azure (Alpha) services.

■ Azurite: An Azure storage emulator that simulates Azure Storage services such as
blobs, queues and tables locally.

■ Terraform Mock Provider: A Terraform feature that introduces mock providers,

resources and data sources for IaC tests. It allows for the execution of Terraform
tests without creating infrastructure or requiring credentials.

■ LoftLabs (vCluster): Creates fully functional virtual Kubernetes clusters. Each cluster
runs inside the namespace of the underlying K8s cluster.

■ Microcks: An open-source, cloud-native tool for API Mocking and Testing.

Refer to Reference Architecture Brief: Continuous Integration for more information on

continuous delivery best practices.

Continuous Deployment
CD represents the final stage of the release cycle, encompassing all essential tasks
needed to automatically and securely deploy a new software version to a target platform.
Since the process is entirely automated, it eliminates the need for human involvement.
Unlike CI, CD is a platform-oriented process, meaning release automation is designed
based on the target infrastructure.

When planning a continuous deployment workflow for IaC, one must consider where
resources must be provisioned. Hence, the selected tooling or engine delivering the
infrastructure must be able to provision, update or decommission resources with the least
possible impact.

Since CD for infrastructure is a platform-oriented approach, practitioners must assess

compatible tooling. In general, IaC tooling alternatives fall into two groups:

Gartner, Inc. | G00826040 Page 23 of 33

■ Vendor-neutral: IaC tools that practitioners can use to manage infrastructure
resources across different platforms. Such flexibility is achieved due to the
extensible nature of these tools, which rely on plug-ins to enable them to interact
with other providers and managed endpoints. Tools such as Terraform, OpenTofu,
Ansible, Pulumi, Crossplane and Perforce (Puppet) can be considered vendor-
agnostic tools.

■ Vendor-bounded: Tools designed to manage resources on top of a single

infrastructure. These tools tightly integrate with supported providers and cannot be
extended. Platform-specific initiatives include AWS CloudFormation, AWS Cloud
Development Kit (AWS CDK), AWS Serverless Application Model (AWS SAM), Azure
Resource Manager (ARM), Azure Bicep, Google Cloud Deployment Manager and
Helm.

Figure 5 depicts the most representative IaC tooling alternatives, including vendor-neutral
and vendor-bounded alternatives.

Figure 5: IaC Landscape: Vendor Agnostic Versus Bounded Tooling

Gartner, Inc. | G00826040 Page 24 of 33

The CD workflow may vary significantly according to the selected IaC tooling. Tool
selection will also influence the Orchestration Techniques decision-making process, as
they are intrinsically related. For instance, while automating infrastructure using stateful
tools such as Terraform requires attention to state management, they significantly
accelerate resource management compared to stateless alternatives such as Ansible.

Though reasonable, comparing the existing IaC tooling landscape based solely on vendor
neutrality is an oversimplified perspective. Since these IaC initiatives significantly differ in
capabilities and use cases, analyzing them would require dedicated research. Hence, the
comparison of IaC tooling is outside the scope of this research.

Deployment Flow
A common dilemma among IaC practitioners relates to how to implement a reliable
deployment flow. All code changes must be submitted as pull requests (PRs), or merge
requests (MRs), before the code is merged to protected branches such as main. Using
PRs, the submitted code can be tested and validated using CI pipelines before approval
and then merged.

Though practitioners can leverage webhook-based approaches triggered by Terraform PR

events, they can alternatively adopt specialized tooling that implements GitOps.

The following are initiatives practitioners should consider to implement and optimize
flows for IaC deployments:

■ Atlantis: An open-source tool designed to facilitate collaboration and automation in

Terraform workflows. It is particularly useful for teams using Git as their version
control system. Atlantis integrates with version control systems (such asGitHub,
GitLab and Bitbucket) to automate Terraform workflows directly from PRs. When a
PR is opened or updated, Atlantis can automatically run a terraform plan to show the
proposed changes, and it can apply those changes when approved.

■ Terrateam: A tool designed to enhance collaboration and automation in Terraform

workflows, particularly for teams using GitHub. It integrates with GitHub to automate
Terraform workflows directly from PRs. It enables teams to manage Terraform plans
and apply them through comments and reviews within the GitHub interface.

Gartner, Inc. | G00826040 Page 25 of 33

■ IaC-specialized automation platforms: Also known as Terraform Automation and
Collaboration Software (TACOS), these automation platforms aim to solve problems
associated with operating IaC at scale. Although the term explicitly refers to
Terraform, some existing initiatives have expanded to other IaC tooling, such as
OpenTofu, Terraform, CloudFormation, Pulumi and Ansible. TACOS solutions
integrate with Git to detect changes to “watched” repositories, triggering deployment
workflows detached from CI pipelines.

■ GitOps: A pattern for operating cloud-native resources using Git repositories as a

single source of truth. It creates a closed automation and state reconciliation loop
relying on specialized controllers to watch the resources’ state, which ensures they
are consistent with the desired state declared in the code. Initiatives such as
Crossplane, Kratix, AWS Controllers for Kubernetes (ACK), Azure Service Operator
(ASO) and Google Cloud Config Connector can be used for declaring infrastructure
and are fully adherent to GitOps (see Use GitOps With Kubernetes to Streamline
Deployment and Platform Automation).

Initiatives such as HCP Terraform Operator for Kubernetes, Pulumi Kubernetes Operator,
Tofu Controller for Flux and Upbound Official Providers enable the control loop to
automate IaC deployments. Using such operators, practitioners can declare resources
using the IaC tools of their choice (for example, Terraform, OpenTofu and Ansible) and get
resources provisioned by K8s controllers.

Secret Management
Managing sensitive information is critical to preserving the security and integrity of
infrastructure implementations. Inattentive password, key and token management can
lead to unauthorized access, data breaches and compromised infrastructure. For effective
CD for IaC, practitioners must ensure the implementation of best practices for generating,
storing, transmitting and securely consuming secrets by automation workflows.

Practitioners must ensure secrets (for example, passwords, API keys, tokens, Secure Shell
[SSH] private keys, cloud provider credentials and certificates) are injected into Execution
Environments, so IaC tools can access target platforms.

Gartner, Inc. | G00826040 Page 26 of 33

For IaC tools requiring remote access to managed endpoints via SSH (such as Ansible,
Broadcom (VMware [SaltStack]) and Puppet Bolt), practitioners must consider using
certificate-based authentication or proxy services rather than key pairs (public and
private). The certificate-based method facilitates key management and offers additional
guardrails (for example, certificate expiration, RBAC and SSH restrictions [PTY allocation
and port forwarding]).

As a golden rule for IaC automation, secrets must never be hard-coded or stored alongside
the IaC code on Git. The only exception is when secrets are stored in encrypted form using
tools such as SOPS, Sealed Secrets or similar initiatives. Though these tools can
automate secrets’ decoding and injection into execution environments, managing
decryption keys at scale is not achievable.

The following methods are commonly used in IaC workflows:

■ Secret stores: Automation platforms commonly offer secret storage features that
allow users to persist sensitive data that can be exposed as environment variables to
workflows during pipeline execution. Though effective, managing secrets’ life cycle
becomes a challenge, especially at scale. Some practitioners manage to rotate these
secrets by integrating automation platforms with secrets management solutions
that will periodically update stored secrets using platform-provided APIs.

■ Secret managers: This method allows secrets to be pulled directly from secret
management platforms (for example, HashiCorp Vault, AWS Secrets Manager and
Azure Key Vault) and injected as environment variables or environment files into
execution environments. Such an approach benefits from the life cycle management
capabilities offered by these platforms, thereby facilitating management at scale.
Practitioners can instrument pipelines to pull external secrets using guidelines
maintained by vendors or plugins.

■ Code pulling: Though not currently a widespread practice, some IaC tools can pull
secrets directly from back-end secret repositories. This capability allows
practitioners to detach secrets from the execution environments. For instance,
Terraform Data Sources, Pulumi ESC (Dynamic Secrets), CloudFormation dynamic
references and K8s External Secrets Operator can dynamically fetch data from
secrets management solutions. However, practitioners must consider that some
tools will incorporate the secrets into their state files, which represents a risk.
Terraform users can prevent that by leveraging ephemeral blocks and write-only
arguments on their IaC definitions. 3 , 4

Gartner, Inc. | G00826040 Page 27 of 33

■ Machine-to-machine (M2M) authentication: Securely authenticates systems or
services to interact with each other without human intervention. Practitioners can
use this method to implement a context- or environment-based approach to generate
short-lived, one-off credentials for dynamic IaC provisioning. OAuth 2.0, OIDC,
SPIFFE/SPIRE and instance metadata are standard methods for M2M
authentication in IaC pipelines. In addition to all major automation platforms (for
example, GitHub Actions, GitLab CI/CD and Azure Pipelines) that natively support
M2M authentication, it can also be implemented through specialized agents.

Though most automation platforms offer persistent secret storage features that allow in-
flight injection of sensitive information into execution environments, practitioners must
favor approaches based on short-lived and ephemeral credentials. IaC workflows relying
on M2M authentication must be prioritized.

Cost Control
Cost estimation for IaC involves assessing the financial expenditure associated with
deploying and managing infrastructure using IaC tools and practices. It aims to estimate
costs that will be incurred when provisioning and running infrastructure resources outlined
in IaC definitions. Though anticipating the cost for services billed per provisioned resource
is more straightforward, estimating the cost for services charged per use (for example,
object storage and egress traffic) is more challenging and usually requires a speculative
approach.

Practitioners are encouraged to integrate specialized tools into their IaC workflows and
integrate PaC to catch deployments that might generate financial penalties. For instance,
if the estimated cost per month for a specific deployment is above a certain threshold,
the pipeline is automatically aborted.

Some cost estimation initiatives for IaC are:

■ OpenCost: A vendor-neutral open source project for measuring and allocating cloud
infrastructure and container costs in real time.

■ Infracost: An open-source tool specifically designed to provide cost estimates for

Terraform projects. It can be integrated into CI/CD pipelines to automatically
generate cost reports as part of the deployment process.

Gartner, Inc. | G00826040 Page 28 of 33

■ Cycloid (TerraCost): Uses your Terraform plan to automatically output the cost of
resources and to show how that cost evolves from one deployment to the next.

■ HashiCorp HCP Terraform Cost Estimation: A feature provided by HashiCorp to help

users estimate the costs associated with their Terraform-managed infrastructure.

Drift Detection
Drift detection refers to mechanisms that identify and manage discrepancies between the
infrastructure defined in IaC configurations and the actual state of the deployed
infrastructure. Drift can occur when changes are made directly to the infrastructure
outside of the typical IaC workflow, leading to inconsistencies. Drift detection is crucial for
ensuring the integrity and reliability of infrastructure managed through IaC.

While tools such as Terraform, AWS CloudFormation and Pulumi can detect drift using
specific commands (such as terraform plan, AWS CloudFormation detect-stack-drift and
pulumi refresh [which is currently preview-only]), IaC tools based on control loop
orchestration instead implement permanent drift detection and reconciliation capabilities
(see the Orchestration Techniques section of this research for more information).
However, consider that automatic remediation can be a risky operation in some cases, as
it may lead to rogue redeployments.

Though some IaC tools implement mechanisms to catch divergences between the actual
system state and the desired state, they are mostly event-oriented. Modern initiatives
implement recurring drift detection and pruning mechanisms to reconcile resources and
ensure consistency.

Practitioners can evaluate the following initiatives to identify inconsistencies between IaC
definitions and deployed resources:

■ driftctl (Snyk): An open-source tool designed to detect, track and alert on

infrastructure drift managed using Terraform. The tool is not only able to warn about
drift, but is also capable of detecting unmanaged resources (such as resources
implemented outside the IaC flow).

■ driftive: A tool for detecting drift in Terragrunt, Terraform and OpenTofu projects.
driftive can concurrently analyze multiple projects, create GitHub issues for detected
drifts and send notifications about drifts using Slack.

Gartner, Inc. | G00826040 Page 29 of 33

■ dragondrop.cloud (cloud-concierge): Ensures the actual state of cloud infrastructure
aligns with the desired state as defined in IaC configurations. Continuously monitors
resources to detect any changes or discrepancies from the Terraform state and
provides recommendations on how to resolve detected drifts.

■ Digger: A platform that focuses on automating IaC workflows (particularly

Terraform) that also offer drift detection features. Digger may also provide guidance
or automation to help teams remediate infrastructure to its intended state.

■ IaC-specialized platforms (TACOS): Some TACOS platforms may offer drift

detection and management capabilities for infrastructure. While not all of these
tools are specifically designed for drift detection, they collectively support
maintaining infrastructure consistency. These platforms include Terraform
Enterprise (TFE), Terraform Cloud (TFC), Spacelift, Firefly, Burrito and env0.

Follow-Up
As infrastructure automation is a complex initiative that goes beyond the simple definition
of workflows, practitioners must consider aspects such as how to manage IaC code best,
how to select the most suitable automation approach and how to best scale practices.
Considering this, Gartner recommends the following actions:

■ Build versus buy: Although most IaC automation workflows involve pipelines
developed and maintained in-house (build), specialized platforms have gained
popularity. By adopting (buy) IaC-specialized automation solutions (such as TACOS),
practitioners are no longer required to implement end-to-end workflows that address
all the requirements imposed by the IaC tools of their choosing. Since
comprehensive infrastructure automation requires integrating different tooling, these
specialized platforms can generally simplify and improve the user experience, as
well as provide self-service options. On the other hand, the use of specialized
platforms can limit versatility and teams’ autonomy. Practitioners must evaluate
these trade-offs before deciding between building versus buying (see Designing a
Platform-Oriented I&O Operating Model for more information).

Gartner, Inc. | G00826040 Page 30 of 33

■ Platform engineering: In The Three-Day Model section of this research, IPE is
described as a branch of PE promoting reusability and self-service both among and
across I&O teams. While PE focuses on improving the developer experience (DevEx),
IPE instead focuses on creating scalable, reliable and efficient solutions that enable
teams to streamline infrastructure provisioning and operations. Though IPE
adoption is sufficient for most use cases, there are scenarios where product teams
are the end consumers. Hence, the attention to DevEx is extremely encouraged (see
Adopt Platform Engineering to Improve the Developer Experience for more
information).

Risks and Pitfalls

Back to top

Over-engineered workflows: “Over-engineering” describes designing a product or system

with more complexity, features or capabilities than are necessary for its intended purpose.
Though this research explored different methods for optimizing and securing
infrastructure deployments, practitioners must avoid over-instrumenting pipelines.
Workflow tools must be carefully selected, considering the most pressing needs, and
should evolve over time. Pipelines are encouraged to initiate simple workflows containing
only the foundational CI/CD steps, before enriching the workflows following a demand-
oriented approach.

Misaligned orchestration: Though this research focuses on automation workflows based

on pipelines, the document also describes alternative orchestration approaches (see the
Orchestration Techniques section of this research for more information). As infrastructure
pipelines are highly versatile, practitioners must also consider engineering efforts at scale.
Though IaC automation platforms (such as TACOS) and control loops offer better
attributes to address scalability, they also impose trade-offs (for example, vendor lock-in
and a steep learning curve). Considering there is no one-size-fits-all orchestration
selection, practitioners must evaluate combining different approaches to make the most
out of their individual attributes.

Evidence
1
AWS re:Invent: Stateful vs. Stateless Workloads With IaC: Together or Not?, Amazon
Web Services (AWS).

2
pre-commit

Gartner, Inc. | G00826040 Page 31 of 33

 3
Ephemerality in Resources, IBM (HashiCorp).

4
Use Write-Only Arguments, HashiCorp.

Recommended by the Author

Some documents may not be available as part of your current Gartner subscription.

Market Guide for Infrastructure Automation and Orchestration Tools

Streamline Kubernetes Automation With Infrastructure Platform Engineering

Drive Business Agility With Infrastructure Platform Engineering

How to Structure Your Infrastructure Platform Engineering Journey

Reference Architecture Brief: Infrastructure Automation and Orchestration

How to Select Container-Based Development Environment Approaches

Use GitOps With Kubernetes to Streamline Deployment and Platform Automation

Designing a Platform-Oriented I&O Operating Model

Adopt Platform Engineering to Improve the Developer Experience

Reference Architecture Brief: DevSecOps Platform

Reference Architecture Brief: Continuous Integration

Gartner, Inc. | G00826040 Page 32 of 33

© 2025 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of
Gartner, Inc. and its affiliates. This publication may not be reproduced or distributed in any form
without Gartner's prior written permission. It consists of the opinions of Gartner's research
organization, which should not be construed as statements of fact. While the information contained in
this publication has been obtained from sources believed to be reliable, Gartner disclaims all warranties
as to the accuracy, completeness or adequacy of such information. Although Gartner research may
address legal and financial issues, Gartner does not provide legal or investment advice and its research
should not be construed or used as such. Your access and use of this publication are governed by
Gartner's Usage Policy. Gartner prides itself on its reputation for independence and objectivity. Its
research is produced independently by its research organization without input or influence from any
third party. For further information, see "Guiding Principles on Independence and Objectivity." Gartner
research may not be used as input into or for the training or development of generative artificial
intelligence, machine learning, algorithms, software, or related technologies.

Gartner, Inc. | G00826040 Page 33 of 33

Table 1: IDE extensions for IaC

IDE Where to find Popular IaC extensions

Visual Studio Code (Microsoft) Extensions for Visual Studio Code (Microsoft Terraform, OpenTofu, Gruntwork (Terragrunt),
Visual Studio Code) Aqua Security (tfsec)Tfsec, Palo Alto Networks
(Prisma Cloud [Checkov]), Ansible, Azure Bicep and
Kubernetes.

IntelliJ IDEA (JetBrains) JetBrains Marketplace Terraform and HCL, Ttfsec Findings Explorer,
Ansible, AWS CloudFormation and Kubernetes.

Eclipse IDE (Eclipse Foundation) Eclipse Marketplace Terra Architect, Snyk Security and Kubernetes
Manifest Editor.

Source: Gartner (July 2025)

Gartner, Inc. | G00826040 Page 1A of 3A

Table 2: Representative IaC Linting and SAST Initiatives

IaC linting IaC SAST

■ actionlint for GitHub Actions ■ Checkov

■ ansible-lint ■ cfn_nag

■ Bicep linter ■ cdk-nag

■ cfn-lint ■ Cycode

■ Dockerfile Linter ■ GitLab IaC Scanning

■ helm lint ■ Checkmarx (Keeping Infrastructure as Code Secure [KICS])

■ KubeLinter ■ Kubescape

■ terraform validate ■ Orca Security

■ TFLint ■ Semgrep

■ Snyk IaC
■ Sysdig

■ Tenable

■ Tenable (Terrascan)

■ TFLint

■ tfsec

■ Aqua Security (Trivy)

Gartner, Inc. | G00826040 Page 2A of 3A

Source: Gartner (July 2025)

Table 3: Representative Policy Enforcement Initiatives

Pipeline enforcement Platform enforcement

■ HashiCorp Sentinel ■ Azure Policy

■ Regula ■ AWS Control Tower and AWS Organizations

■ Kyverno CLI ■ Kyverno

■ AWS CloudFormation Guard ■ OPA Gatekeeper

■ Open Policy Agent (OPA) Conftest

■ terraform-compliance

■ Pulumi CrossGuard

■ Dockerfile-audit

■ Tenable Terrascan

Source: Gartner (July 2025)

Gartner, Inc. | G00826040 Page 3A of 3A