1. Infrastructure as Code Foundations

Introduction and Context

Infrastructure as Code (IaC) is the practice of defining, provisioning, configuring, and managing computing infrastructure through machine-readable files and automated processes. Instead of creating servers, networks, databases, access policies, and application platforms manually through web consoles or command-line instructions, an organization describes the intended infrastructure in code. Tools then interpret that description and create or modify resources in a controlled manner.

IaC has become a foundational practice in DevOps because modern systems are distributed, frequently changed, and often deployed across multiple environments. A development platform may contain virtual machines, containers, managed databases, load balancers, identity policies, monitoring services, and network controls. Managing such systems manually creates inconsistency and makes it difficult to determine who changed what, when the change occurred, and whether the same environment can be recreated elsewhere. IaC addresses these problems by treating infrastructure definitions as versioned, reviewable, testable, and repeatable artifacts.

Terraform and Ansible illustrate two closely related but distinct uses of IaC. Terraform is primarily an infrastructure provisioning and orchestration tool. It is commonly used to create cloud resources, networks, storage, identity objects, and other infrastructure components. Ansible is primarily an automation and configuration-management tool. It is commonly used to install packages, configure operating systems, deploy applications, and enforce system settings. In practice, the tools may be used together, but their operating models and strengths differ.

IaC is not merely a technique for replacing manual work with scripts. It represents a change in the way infrastructure is designed, governed, documented, and operated. It introduces software-engineering ideas such as version control, code review, testing, modularity, dependency management, and continuous integration into infrastructure management.

Learning Objectives

After studying this chapter, students should be able to:

1. Define Infrastructure as Code and explain its role in DevOps.

2. Distinguish provisioning, configuration management, orchestration, and deployment automation.

3. Explain idempotency, immutability, desired state, drift, reproducibility, and declarative automation.

4. Compare manual provisioning, scripts, configuration-management tools, and infrastructure-provisioning tools.

5. Describe the evolution of infrastructure automation and the roles of Terraform and Ansible.

6. Evaluate the benefits, limitations, risks, and governance requirements of IaC.

7. Select an appropriate automation approach for a given organizational situation.

8. Apply IaC principles to a realistic infrastructure-management scenario.

From Hand-Built Servers to Programmable Infrastructure

Infrastructure management has developed through several broad stages. In the earliest stage, administrators installed operating systems, configured networks, and deployed applications manually. Documentation was often informal, and the exact sequence of actions depended on individual experience. This approach could work for a small number of stable servers, but it became unreliable as systems grew.

The next stage involved shell scripts and other procedural automation. A script could install software, create directories, modify configuration files, and start services. Scripts reduced repetitive effort and captured operational knowledge. However, many scripts described a sequence of commands rather than the desired final condition. Re-running a script might duplicate entries, overwrite an intentional change, or fail because an earlier command had already been performed. Error handling and platform portability also became difficult.

Configuration-management tools introduced a more systematic approach. Tools such as Ansible, Puppet, and Chef allow administrators to express configuration requirements and apply them across multiple systems. Their central concern is usually the state of an existing machine: which packages are installed, which services are running, which users exist, and which configuration values are present.

Cloud computing created a further need. Infrastructure could now be created through APIs in seconds, but the number and variety of resources increased dramatically. Organizations needed to create complete environments consisting of networks, subnets, routing rules, security groups, compute instances, databases, and monitoring components. Infrastructure-provisioning tools such as Terraform address this requirement by managing resource lifecycles through code and dependency graphs.

The current stage combines IaC with version control, automated testing, policy enforcement, continuous integration and continuous delivery, observability, and self-service platforms. Infrastructure is increasingly treated as a product: it has owners, users, interfaces, quality standards, security requirements, and a lifecycle.

A Vocabulary for Infrastructure as Code

Several terms must be distinguished carefully.

Infrastructure provisioning is the creation, modification, and deletion of infrastructure resources such as virtual networks, virtual machines, databases, storage volumes, and cloud services.

Configuration management is the process of ensuring that a system has the required software, settings, users, permissions, files, and services.

Orchestration coordinates multiple operations or systems in a defined order. For example, an orchestration process may create a network, provision a database, deploy application servers, and then configure a load balancer.

Deployment is the release of an application, service, or configuration into a target environment. Infrastructure provisioning may be necessary before deployment, but the two activities are not identical.

Desired state is the condition an organization intends a system or resource to have. Examples include “three application instances must exist,” “the database must not be publicly accessible,” or “the Nginx service must be running.”

Actual state is the condition currently observed in the environment. The difference between desired and actual state is often called drift.

Idempotency means that applying an operation repeatedly produces the same intended result as applying it once. An idempotent automation task checks the current condition and changes it only when necessary.

Immutability is the practice of replacing an infrastructure artifact or instance rather than modifying it in place. An immutable server is built from a known image or definition and replaced when a change is required.

Reproducibility is the ability to recreate an equivalent environment from the same source definitions, inputs, and dependencies.

Declarative automation specifies what the desired result should be. The tool determines the actions needed to reach that result.

Imperative automation specifies how to perform a sequence of actions. The author controls the steps and their order.

State is information maintained by an automation system about resources it manages. Terraform, for example, uses state to associate configuration with real infrastructure objects and to calculate changes.

Drift detection is the identification of differences between declared configuration and the environment that actually exists.

Declarative and Imperative Ways of Thinking

The distinction between declarative and imperative automation is central to IaC. Consider a requirement that a web server package must be installed and its service must be running. An imperative script may execute commands such as updating package metadata, installing the package, editing a file, and starting the service. The script describes the route to the result.

A declarative configuration instead states that the package must be installed and the service must be enabled and running. The automation engine examines the current system and performs only the actions necessary to satisfy the requirement. This separation between intention and implementation allows the tool to handle different starting conditions more safely.

Declarative automation does not eliminate procedural logic. Conditions, loops, dependencies, handlers, and ordering may still be required. Rather, it changes the primary abstraction from a command sequence to a target state. Terraform is strongly declarative: a configuration describes resources and relationships, while Terraform constructs an execution plan. Ansible supports declarative patterns through modules and desired-state tasks, although playbooks can also contain procedural ordering and conditional behavior.

Neither model is universally superior. Imperative scripts are useful for small, specialized, one-time operations and situations where exact procedural control is necessary. Declarative systems are generally more suitable for repeatable environment management, but they require disciplined state handling and an accurate model of resource behavior.

Core Principles of IaC

Idempotency and Convergence

Idempotency allows an automation process to be safely repeated. If a task declares that a directory should exist, running it once creates the directory and running it again confirms that it already exists. It should not create a second directory or fail unnecessarily. Idempotency is particularly important in CI/CD pipelines, recovery procedures, and large-scale operations where the same automation may be triggered more than once.

A related concept is convergence. A convergent system progressively moves the actual environment toward the desired state. If a configuration has drifted, the next application of automation should correct the drift, subject to the tool’s permissions and resource behavior.

Idempotency is not automatic. A command that appends a line to a file on every execution is not idempotent. A task that creates a database without checking whether it already exists may fail or create unintended resources. Engineers must choose appropriate modules, conditions, resource identifiers, and lifecycle settings.

Desired State and Drift Management

A declared configuration is a model of intent, not necessarily a complete description of every property in the environment. Teams must decide which attributes are controlled by IaC and which are managed elsewhere. If a cloud resource is changed manually, the environment may drift from the declared model. Drift can produce security weaknesses, unexpected costs, failed deployments, or misleading documentation.

Drift management involves detecting differences, determining whether they are accidental or intentional, and deciding how to reconcile them. The correct response may be to apply the code, update the code, or formally preserve an externally managed exception. Automatic correction is not always safe; an apparently unwanted change may represent an urgent operational fix.

Immutability and Replaceable Infrastructure

Mutable infrastructure is changed in place. This can be efficient for minor adjustments, but over time the server may acquire undocumented packages, temporary files, and manual fixes. Such accumulated variation is sometimes described as configuration drift or server snowflake behavior.

An immutable approach builds a new image or instance from a known definition and replaces the old one. This improves consistency and rollback when combined with versioned artifacts and health checks. It may, however, increase deployment complexity and require careful handling of stateful systems. Databases, persistent storage, and long-lived connections cannot always be replaced as easily as stateless application servers.

Reproducibility and Determinism

Reproducibility requires more than storing a configuration file. Provider versions, operating-system images, package repositories, modules, secrets, environment variables, and external APIs may all affect the result. Dependencies should therefore be versioned or constrained where practical, and configurations should avoid uncontrolled sources of variation.

A reproducible environment is not necessarily bit-for-bit identical. Cloud platforms may assign different IP addresses or hardware, and timestamps or generated identifiers may differ. The important requirement is that the environment conforms to the relevant functional, security, and operational specifications.

Versioning and Reviewability

IaC files should normally be stored in a version-control system. A change can then be reviewed, attributed, compared with earlier versions, and reverted when necessary. Pull requests and peer review provide an opportunity to examine security groups, identity permissions, network exposure, cost implications, and destructive operations before execution.

Treating infrastructure code like application code does not mean using identical testing methods. Infrastructure changes require additional attention to provider APIs, dependency graphs, state transitions, failure recovery, and environmental differences.

Terraform and Ansible in the IaC Landscape

Terraform uses provider plugins to communicate with infrastructure platforms. A Terraform configuration describes resources, data sources, variables, outputs, and relationships. Terraform typically compares the configuration and its state information with the remote environment, creates a plan, and applies the required changes. Its resource graph helps establish dependencies and determine an execution order.

Terraform is well suited to creating and managing relatively durable infrastructure resources. Examples include virtual private networks, subnets, security groups, compute instances, managed databases, DNS records, and cloud storage. Its state is operationally important and must be protected, backed up, and shared appropriately in team environments. Remote state storage, locking, access control, and state separation are common practices.

Ansible generally connects to target hosts or services and executes modules through playbooks. A playbook can install packages, manage files, create users, configure services, apply templates, and perform application deployment tasks. Ansible is agentless in its common system-management model, using remote communication such as SSH or WinRM. It is particularly useful when machines already exist and must be configured consistently.

A common division of responsibility is to use Terraform to provision the underlying platform and Ansible to configure operating systems and applications. This is not a universal rule. Terraform can invoke other systems, and Ansible can interact with cloud APIs, but combining tools requires clear ownership boundaries. Otherwise, two tools may attempt to manage the same property and produce conflicts.

Comparing Automation Approaches

Manual provisioning offers flexibility and immediate human judgment. It is useful for experimentation, emergency intervention, and unfamiliar environments. Its weaknesses include slow execution, inconsistent results, weak auditability, dependence on individual knowledge, and difficulty reproducing a previous environment.

Ad hoc scripts are inexpensive to create and powerful for narrowly defined operations. They become risky when they lack error handling, input validation, idempotency, logging, testing, or documentation. A script may be an appropriate component of an automation system, but a collection of ungoverned scripts is not automatically IaC.

Configuration-management tools are designed to maintain the state of systems that already exist. They excel at operating-system and application configuration, package management, file templating, service control, and repeated enforcement. Their challenge is that they may be less suitable for modelling complex infrastructure dependencies and resource lifecycles.

Infrastructure-provisioning tools model infrastructure resources and their relationships. They provide a consistent interface to platforms and can create complete environments from code. Their challenges include state management, provider differences, asynchronous APIs, destructive changes, and the possibility that a declarative model may not capture every operational nuance.

The choice should be based on the problem rather than tool popularity. Important questions include: Is the target a host or a platform? Is the operation repeatable? Must the environment be recreated? Who owns the resource? Is there persistent data? How will changes be reviewed? What is the failure and rollback strategy?

Practical Workflow for IaC Adoption

A mature IaC workflow commonly begins with inventory and ownership. Teams identify resources, dependencies, service owners, compliance requirements, and existing manual procedures. They then select a source-of-truth model and define which resources will be managed by which tool.

The next stage is modelling. Resources are divided into coherent modules or roles with clear inputs and outputs. Naming, tagging, identity, network boundaries, backup policies, and logging requirements should be designed rather than added as afterthoughts.

Changes are then developed in version control and validated through formatting checks, static analysis, unit or module tests, policy checks, and safe planning. A review process examines not only syntax but also blast radius, cost, security, data retention, and recoverability.

Execution should use controlled credentials, protected state, environment-specific variables, and appropriate approvals. After deployment, monitoring and drift detection provide feedback. Failed changes require a recovery process, which may include reverting code, restoring state, rolling back an image, or applying a corrective configuration.

Applied Case: Rebuilding a Multi-Environment Web Platform

Background

The following is an illustrative case. A growing financial-services organization operates a customer web platform in development, testing, and production environments. Development infrastructure is created by engineers through a cloud console. Test servers are built from scripts maintained by different teams, while production changes require a small operations group to perform manual procedures.

Situation and Problem

The environments differ in operating-system packages, network rules, and monitoring configuration. A defect appears in production but cannot be reproduced in testing. A former employee’s undocumented console changes also make it difficult to determine why a database is publicly reachable. Provisioning a new test environment takes several days, and the organization cannot reliably estimate the cost of temporary environments.

Analysis

The problem is not simply slow provisioning. The organization lacks a common model of desired state, consistent ownership, and an auditable change process. Manual actions and scripts have created drift. Application servers are mutable, and the existing scripts are not reliably idempotent. In addition, database resources contain persistent data and therefore require a different lifecycle from stateless web servers.

Approach and Strategy

The organization first inventories resources and separates responsibilities. Terraform is selected to model networks, subnets, firewall rules, load balancers, managed databases, and compute resources. Ansible is selected for operating-system hardening, package installation, service configuration, and deployment preparation.

The team stores code in a version-control repository and creates reusable modules for network and application-platform components. Environment-specific values are supplied through controlled variables rather than copied configuration files. State is stored remotely with access controls and locking. Production changes require peer review and an approval step.

Application servers are rebuilt from a versioned image or consistent provisioning process rather than modified indefinitely in place. Database deletion is restricted, backups are required, and replacement policies are used cautiously. Automated checks verify that production databases cannot receive unrestricted public traffic and that required logging is enabled.

Before adopting the new workflow for production, the team imports or recreates existing resources carefully, compares actual settings with the intended model, and resolves ownership conflicts. Ansible tasks are written to be idempotent: packages are declared by state, configuration files are rendered from templates, and services are enabled and started only when required.

Outcome

New environments can be created from reviewed definitions, and differences between environments become visible in code. The organization gains a reliable audit trail and can identify whether a change was intentional. Engineers can reproduce many production conditions in testing, although data-handling controls prevent copying sensitive customer data directly. The team also discovers that IaC does not remove the need for architecture, operations expertise, backups, or incident response.

Learning Points

The case demonstrates that IaC is an organizational control system as much as a technical mechanism. Tool selection must follow resource ownership and lifecycle. Stateless infrastructure can often be replaced, while stateful resources require preservation and explicit safeguards. Finally, consistency depends on governance, review, security, and monitoring in addition to code.

Risks, Limitations, and Common Mistakes

IaC can amplify mistakes. A defective network rule or deletion instruction may affect an entire environment. Automation makes changes faster, but speed without review can increase blast radius. Destructive operations should therefore be visible in plans and protected through approvals, lifecycle rules, backups, and separation of duties.

Secrets should not be embedded in repositories, plain-text variables, logs, or state files without appropriate protection. State may contain identifiers, connection details, or sensitive attributes even when configuration files do not. Access to repositories, execution systems, cloud accounts, and state storage must be controlled and audited.

Another common error is managing the same resource from multiple sources. For example, a security-group rule may be declared in Terraform, changed by a console user, and partially overwritten by a separate script. Ownership boundaries should be explicit.

Teams also underestimate import and migration work. Existing infrastructure cannot always be adopted safely by writing code and immediately applying it. The declared model must first be compared with the actual resource, and unexpected differences must be understood.

Over-modularization is another problem. Excessive abstraction can hide important relationships and make troubleshooting difficult. Modules and roles should represent stable, meaningful boundaries rather than every small resource.

IaC does not guarantee reliability. Provider bugs, API outages, quota limits, race conditions, incorrect dependencies, invalid assumptions, and human approval errors remain possible. Testing should include failure scenarios, not only successful creation.

Governance, Ethics, and Professional Responsibility

Infrastructure decisions affect confidentiality, integrity, availability, cost, and sometimes human safety. IaC code can create excessive privileges, expose personal data, disable encryption, or remove audit controls. Therefore, infrastructure engineers have professional responsibilities beyond making deployments succeed.

Governance should address identity and access management, separation of duties, approval requirements, retention and deletion, logging, regulatory obligations, data residency, backup, and emergency change procedures. Policy-as-code can automatically test selected controls, but automated policy checks must themselves be maintained and validated.

Organizations should also consider the environmental and financial effects of infrastructure. Unused development environments, overprovisioned instances, and unnecessary data replication consume resources and increase cost. IaC enables tagging, budgets, schedules, and standardized sizing, but these controls require organizational ownership.

Current Developments and Emerging Directions

IaC is increasingly integrated with platform engineering. Internal developer platforms expose approved infrastructure capabilities through templates and service catalogs, allowing developers to obtain environments without learning every provider-specific detail. This creates productivity benefits but also makes platform governance and interface design important.

Policy-as-code systems evaluate infrastructure definitions before deployment. Security scanning, cost estimation, compliance validation, and dependency analysis are becoming routine parts of infrastructure pipelines. Drift detection and continuous reconciliation are also expanding, particularly in cloud-native and Kubernetes environments.

Artificial intelligence is being used to suggest configurations, explain plans, detect anomalies, and assist with troubleshooting. Such tools can accelerate work, but generated infrastructure must be reviewed for security, cost, correctness, licensing, and hidden assumptions. AI assistance does not replace accountable human approval.

The boundary between provisioning, configuration, and application delivery is also becoming less distinct. Containers, Kubernetes operators, GitOps controllers, and managed cloud services introduce additional declarative layers. The fundamental principles remain the same: define ownership, understand state, control change, make outcomes reproducible, and design safe recovery.

Best Practices for Professional IaC

1. Store infrastructure definitions in version control and review significant changes.

2. Define clear ownership for every resource and avoid overlapping management tools.

3. Prefer idempotent modules, tasks, and resource definitions.

4. Pin or constrain important tool, provider, module, image, and dependency versions.

5. Protect state files, credentials, and execution identities.

6. Use plans, validation, policy checks, testing, and approvals before high-impact changes.

7. Separate environments and use consistent naming, tagging, and access controls.

8. Design backups and recovery before automating destructive operations.

9. Treat persistent data differently from replaceable compute resources.

10. Monitor for drift, failed runs, unexpected cost, and security violations.

11. Keep modules understandable and document assumptions, inputs, outputs, and ownership.

12. Test not only creation but also updates, failure, rollback, and partial execution.

Chapter Summary

Infrastructure as Code expresses infrastructure through machine-readable, versioned, and automatable definitions. It evolved from manual administration and ad hoc scripts into a practice incorporating desired state, repeatability, review, testing, and governance. Declarative automation describes the intended result, whereas imperative automation describes the steps used to obtain it. Idempotency supports safe repetition; immutability reduces accumulated variation; reproducibility enables consistent environments; and drift management keeps actual infrastructure aligned with declared intent.

Terraform is primarily suited to provisioning and managing infrastructure resources and their relationships, while Ansible is primarily suited to configuring systems and applications. They may be combined when ownership boundaries are clear. IaC improves speed, consistency, auditability, recovery, and collaboration, but it introduces risks involving state, secrets, destructive changes, provider behavior, drift, and excessive automation. Effective IaC therefore requires technical design, version control, testing, security, governance, and professional judgment.

Key Terms

Infrastructure as Code: Managing infrastructure through machine-readable definitions and automated processes.

Provisioning: Creating, modifying, or deleting infrastructure resources.

Configuration management: Maintaining required software, settings, and services on systems.

Orchestration: Coordinating multiple dependent automation activities.

Desired state: The intended condition of an infrastructure resource or system.

Actual state: The condition that currently exists in the environment.

Drift: A difference between declared desired state and actual state.

Idempotency: The property that repeated application produces the same intended result.

Immutability: Replacing an artifact or instance instead of modifying it in place.

Reproducibility: The ability to recreate an equivalent environment from controlled definitions and dependencies.

Declarative automation: Automation that specifies the desired result rather than every action.

Imperative automation: Automation that specifies the procedural steps to execute.

State: Information used by an automation tool to track managed resources and prior conditions.

Terraform: A declarative infrastructure-provisioning and resource-management tool.

Ansible: An automation and configuration-management tool commonly using playbooks and modules.

Module: A reusable unit of infrastructure or configuration logic.

Provider: An integration that enables a tool to communicate with a platform or service API.

Policy-as-code: Expressing governance, security, or compliance rules in machine-evaluable form.

Configuration drift: Unplanned divergence caused by manual or external changes.

GitOps: An operating approach in which version-controlled declarations drive automated environment changes.

Review Questions

Short Answer Questions

1. Define Infrastructure as Code and state two characteristics that distinguish it from manual provisioning.

2. What is the difference between desired state and actual state?

3. Explain idempotency using an example of a configuration task.

4. Distinguish infrastructure provisioning from configuration management.

5. Why must Terraform state be protected in a team environment?

Long Answer Questions

1. Explain the evolution from manual provisioning to modern IaC, identifying the weaknesses addressed at each stage.

2. Compare declarative and imperative automation, including situations in which each may be appropriate.

3. Discuss how immutability and reproducibility improve infrastructure reliability, and identify their limitations.

4. Compare Terraform and Ansible in terms of purpose, operating model, and typical professional use.

5. Analyze the governance, security, and operational controls required for a mature IaC workflow.

Analytical / Application Questions

1. An organization uses Terraform to create virtual networks and Ansible to configure servers, but a shell script also changes firewall rules. Analyze the risks and propose an ownership model.

2. A development environment is manually changed to solve an urgent problem and now differs from its Terraform configuration. Explain the possible responses and recommend a safe reconciliation process.

3. A company wants to replace database servers automatically whenever configuration changes. Evaluate this proposal using the principles of immutability, persistent state, backup, and recoverability.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes Infrastructure as Code?

A. Using only shell scripts to start application processes

B. Managing infrastructure through versioned, machine-readable definitions and automation

C. Allowing administrators to configure servers manually through a console

D. Replacing all infrastructure with containers

Correct Answer: B. Managing infrastructure through versioned, machine-readable definitions and automation

Question 2

An Ansible task checks whether a package is installed and changes the system only when it is absent. Which principle does this illustrate?

A. Immutability

B. Drift

C. Idempotency

D. Manual provisioning

Correct Answer: C. Idempotency

Question 3

Which activity is most directly associated with Terraform’s primary role?

A. Creating a virtual network and managed database

B. Editing a developer’s local text editor settings

C. Writing application business logic

D. Monitoring user satisfaction surveys

Correct Answer: A. Creating a virtual network and managed database

Question 4

What is infrastructure drift?

A. A planned replacement of a server image

B. A difference between declared configuration and actual infrastructure

C. A dependency graph created before deployment

D. A method of encrypting state files

Correct Answer: B. A difference between declared configuration and actual infrastructure

Question 5

Which statement correctly contrasts declarative and imperative automation?

A. Declarative automation specifies the desired result, while imperative automation specifies steps

B. Declarative automation cannot use conditions, while imperative automation always uses them

C. Imperative automation is always idempotent, while declarative automation is not

D. There is no practical distinction between the two approaches

Correct Answer: A. Declarative automation specifies the desired result, while imperative automation specifies steps

Question 6

A team uses Terraform to provision cloud servers and Ansible to install packages and configure services on them. Why is this division generally sensible?

A. Terraform cannot communicate with cloud APIs

B. Ansible is designed only for database backups

C. Terraform commonly manages infrastructure resources, while Ansible commonly configures existing systems

D. The two tools must always manage every resource simultaneously

Correct Answer: C. Terraform commonly manages infrastructure resources, while Ansible commonly configures existing systems

Question 7

Which situation most strongly supports an immutable infrastructure approach?

A. A stateless application tier can be rebuilt from a versioned image

B. A database contains unreplicated production data

C. An administrator needs to inspect a running process once

D. A temporary command must be executed on one host

Correct Answer: A. A stateless application tier can be rebuilt from a versioned image

Question 8

Why should infrastructure changes undergo code review?

A. To ensure that every cloud provider uses identical syntax

B. To identify security, cost, dependency, and destructive-change implications before execution

C. To eliminate the need for testing and monitoring

D. To prevent all emergency operational changes

Correct Answer: B. To identify security, cost, dependency, and destructive-change implications before execution

Question 9

A resource is managed by Terraform, a console user, and an independent script. What is the principal risk?

A. The resource will necessarily become immutable

B. The tools may conflict and produce unpredictable or recurrent drift

C. Terraform will automatically remove all external systems

D. Ansible will become the only authorized manager

Correct Answer: B. The tools may conflict and produce unpredictable or recurrent drift

Question 10

Which practice best supports reproducibility?

A. Relying on undocumented manual changes after deployment

B. Allowing every run to use unrecorded dependency versions

C. Versioning or constraining important providers, images, modules, and inputs

D. Deleting all environment-specific information

Correct Answer: C. Versioning or constraining important providers, images, modules, and inputs