7. Infrastructure as Code and Cloud Automation

Introduction and Context

Infrastructure is no longer created only by administrators working manually through servers, consoles, tickets, and undocumented procedures. Modern DevOps organizations treat infrastructure as a versioned, testable, reviewable, and automatable product. Networks, virtual machines, containers, identity policies, databases, observability services, and cloud resources can be described in machine-readable files and provisioned through repeatable workflows. This practice is known as Infrastructure as Code (IaC).

IaC is important because application delivery is only as reliable as the environment in which an application runs. A carefully tested application may still fail when environments differ, permissions are inconsistent, capacity is miscalculated, or a production change cannot be reproduced. IaC addresses these problems by expressing the desired state of infrastructure explicitly and allowing tools to calculate and apply the changes required to reach that state.

Cloud automation extends this idea across the infrastructure lifecycle. It includes provisioning, configuration, scaling, patching, policy enforcement, backup, monitoring, cost control, and retirement. The objective is not merely speed. Effective automation improves consistency, auditability, recovery, security, and organizational learning while reducing avoidable human effort.

This chapter examines declarative IaC, configuration management, immutable infrastructure, policy as code, secrets management, state control, environment standardization, and FinOps. It also considers professional trade-offs: when to automate, how to control risk, how to organize repositories and pipelines, and how to ensure that cloud efficiency does not compromise reliability or compliance.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the purpose, principles, and lifecycle of Infrastructure as Code.

2. Distinguish declarative provisioning from imperative automation and configuration management.

3. Design reusable and standardized infrastructure for multiple environments.

4. Apply state management, code review, testing, and controlled promotion practices.

5. Explain immutable infrastructure, policy as code, and secrets-management strategies.

6. Evaluate security, governance, reliability, and cost implications of cloud automation.

7. Apply FinOps principles to infrastructure design and operational decision-making.

8. Analyze an organizational case involving infrastructure drift, uncontrolled cost, and environment inconsistency.

Infrastructure as Code as an Engineering Discipline

Infrastructure as Code is the management of infrastructure through human-readable definitions maintained in a version-control system and executed by automation tools. The definition may describe a virtual network, a Kubernetes cluster, an object-storage bucket, a database, access policies, or a complete application platform.

The central distinction is between desired state and current state. Desired state is the condition specified by engineers or platform teams. Current state is the infrastructure that actually exists. An IaC engine compares the two and produces a plan showing additions, modifications, and deletions. The plan is then reviewed and applied through a controlled process.

This model changes infrastructure work from an individual operational activity into a software-engineering process. Infrastructure changes can have authors, reviewers, automated tests, release records, and rollback procedures. A version history also provides an explanation of why a resource exists and when its configuration changed.

IaC does not mean that every operational action must be encoded immediately. Emergency intervention may sometimes be necessary. However, an emergency change should subsequently be reconciled with the code; otherwise, a difference known as configuration drift is created. Drift occurs when the real environment no longer corresponds to its declared definition. Persistent drift weakens reproducibility and makes future changes unpredictable.

Important terminology

A resource is an infrastructure object managed by an IaC system. A provider is an integration that allows the system to communicate with a platform such as a public cloud, a virtualization system, or a SaaS service. A module or reusable component groups related definitions behind a consistent interface. Parameters or variables permit controlled variation without copying entire configurations. Outputs expose values, such as an endpoint or network identifier, for use by other components.

Idempotence means that applying the same definition repeatedly produces the same intended result rather than creating unwanted duplicates. Drift is divergence between declared and actual infrastructure. Provisioning creates or changes infrastructure resources, whereas configuration management installs software, modifies operating-system settings, and maintains host configuration. Orchestration coordinates dependencies and sequences across several resources or systems.

Declarative and Imperative Approaches

Declarative IaC describes what the infrastructure should look like. The tool determines how to create or update it. For example, a declaration may state that three application instances must exist in private subnets, that a database must use encrypted storage, and that only a particular service identity may connect to it. The tool calculates the operations needed to achieve that state.

Imperative automation specifies the sequence of actions to perform: create a network, then create a subnet, then launch a server, then install a package, and finally edit a configuration file. Imperative scripts are useful for tasks with complex procedural logic, migrations, and operational remediation. However, they can become difficult to repeat safely because their result depends on execution history and assumptions about the starting state.

The approaches are complementary. Declarative tools are generally well suited to resource lifecycle management; imperative scripts remain valuable for specialized actions. Mature platforms avoid hiding imperative steps inside apparently declarative modules, because opaque side effects make planning and review difficult.

A practical lifecycle consists of the following stages:

• Model: define architecture, dependencies, ownership, security requirements, and service-level expectations.
• Author: express the design in code, using variables, modules, and naming conventions.
• Validate: check syntax, formatting, types, security rules, policy compliance, and dependency logic.
• Plan: calculate the proposed difference between desired and current state.
• Review: examine the plan, risks, costs, and approvals through version control.
• Apply: execute the approved change using controlled credentials and logging.
• Observe: verify health, security, performance, and cost after deployment.
• Reconcile or retire: correct drift, document exceptions, and remove resources that are no longer needed.

This lifecycle connects IaC with continuous delivery. A pull request can trigger validation and a plan; approval can authorize deployment; post-deployment checks can confirm that the platform behaves as intended.

Architecture of a Reusable IaC System

A sound IaC repository normally separates reusable platform components from environment-specific composition. A module might define a managed database, while an environment configuration supplies its size, network, backup policy, and tags. This separation prevents repeated copy-and-paste definitions while allowing legitimate differences between development, staging, and production.

The design should establish naming standards, mandatory metadata, tagging, ownership, data classification, and lifecycle rules. Tags are especially important for cost attribution, incident response, and automated cleanup. A resource without an owner or environment tag is difficult to govern.

Modules should expose a small, well-documented interface. Excessively flexible modules may simply move complexity into a new location. Excessively rigid modules may encourage teams to bypass them. Versioned modules allow consumers to upgrade deliberately rather than receiving unexpected changes.

Dependencies should be explicit. For example, an application service may depend on a network and an identity, while a monitoring component may depend on the service endpoint. Implicit dependencies based on timing or manually created resources create race conditions. A platform should also define which resources are centrally managed and which are owned by individual teams.

Environment standardization

Environment standardization does not require every environment to have identical capacity. It means that environments use common architectural patterns, security controls, naming conventions, deployment mechanisms, observability, and operational assumptions. Development may use smaller instances or reduced replicas, but it should resemble production sufficiently to reveal integration and configuration defects.

A useful model is a common platform baseline with controlled overlays. The baseline specifies mandatory network segmentation, identity integration, encryption, logging, backup, and policy. Overlays provide environment-specific values such as scale, domain names, permitted test data, and availability requirements. This approach reduces accidental divergence while retaining economic and functional flexibility.

Configuration Management and Immutable Infrastructure

Provisioning creates infrastructure; configuration management prepares it for use. Configuration management may install operating-system packages, create users, deploy agents, manage files, configure services, and apply security settings. It is particularly valuable for existing hosts, legacy systems, and situations in which state must be corrected in place.

A common operational model combines IaC for cloud resources with configuration management for software inside machines. Yet this combination must be carefully governed. If both a cloud-init script and a configuration-management tool modify the same file, ownership becomes unclear. Each setting should have a clear source of truth.

Immutable infrastructure takes a different approach. Instead of modifying a running server repeatedly, a new machine image or container image is built, tested, and deployed. The old instance is replaced rather than repaired in place. This reduces configuration drift and makes rollback easier, provided that data and external state are handled separately.

Immutability is not absolute. Databases, persistent volumes, identity records, and queues cannot simply be discarded with every release. The principle is most useful for stateless application components and platform images. Stateful services require migration plans, backups, replication, and carefully tested recovery procedures.

Image pipelines should use approved base images, vulnerability scanning, software provenance, patch processes, and reproducible build inputs. A newly built image should be promoted through environments rather than rebuilt differently for each one. This reduces the risk that production receives an artifact unlike the one tested in staging.

State Control and Safe Change Management

Many IaC tools maintain a state representation that maps declared resources to real infrastructure objects. State enables the tool to identify existing resources, calculate changes, and track dependencies. Because state may contain resource identifiers and sensitive attributes, it must be protected as carefully as source code and credentials.

In team environments, state should normally be stored in a secure remote backend with encryption, access control, versioning, and locking. Locking prevents two concurrent operations from modifying the same state simultaneously. Backups and recovery procedures are essential because corrupted or deleted state can interrupt management even when the infrastructure continues to run.

State should be divided according to ownership and blast radius. A single state file for an entire organization creates slow operations and increases the consequences of an error. Conversely, excessive fragmentation makes dependencies and governance difficult. Boundaries may be organized by product, environment, lifecycle, or security domain.

Importing manually created resources into management, renaming resources, and moving them between modules require care. A logical code change can otherwise be interpreted as destroy-and-recreate. For critical resources, teams should use explicit migration operations, review the plan closely, and protect against accidental destruction. Lifecycle controls such as deletion protection can provide an additional safeguard, but they are not substitutes for design and review.

Policy as Code, Security, and Secrets

Policy as code expresses organizational, security, regulatory, and operational rules in a machine-evaluable form. Examples include: storage must be encrypted; public access is prohibited for sensitive data; production resources must have an owner; workloads must use approved regions; and privileged identities must not be embedded in application configuration.

Policies may be evaluated before deployment, during deployment, or continuously against running resources. Pre-deployment enforcement prevents non-compliant resources from being created. Continuous evaluation detects drift and changes made outside the normal pipeline. A mature governance model distinguishes blocking rules from advisory rules. A temporary exception should have an owner, justification, expiry date, and compensating control.

Security begins with the pipeline itself. IaC repositories require branch protection, peer review, dependency control, audit logs, and least-privilege execution identities. Pipeline credentials should be short-lived where possible, scoped to the target environment, and separated between planning and applying. Pull-request validation should not expose production secrets in logs.

Secrets include passwords, API tokens, private keys, certificates, and encryption material. They should not be committed to source control, embedded in images, placed in plain-text variables, or printed by automation. A secrets-management service should provide encrypted storage, controlled retrieval, rotation, access auditing, and—where appropriate—dynamic credentials with short lifetimes.

Secret management is a lifecycle rather than a single storage decision. Teams must identify secret owners, define rotation frequency, handle failed rotation, revoke compromised credentials, and test application behavior when a secret changes. Encryption at rest does not solve excessive access, accidental disclosure, or weak application design.

Testing and Promotion of Infrastructure

Infrastructure code needs tests at several levels. Static checks validate formatting, syntax, types, and common insecure patterns. Unit tests can test module logic and variable validation. Policy tests evaluate compliance rules. Integration tests provision resources in an isolated account or project and verify real behavior. End-to-end tests assess whether applications can connect, scale, recover, and emit required telemetry.

Testing must also address failure. A deployment that succeeds under normal conditions but leaves orphaned resources after interruption is not operationally mature. Teams should test retries, partial application, state locking, rollback boundaries, backup restoration, and loss of dependencies.

Promotion should normally move the same reviewed definition and artifact through development, staging, and production, with environment-specific values supplied through controlled configuration. Production approvals should be based on risk, not merely ceremony. A small change to a development resource may need no manual gate; a change to a production network or database may require architecture, security, and service-owner approval.

Rollback is more complicated for infrastructure than for application binaries. Some changes are reversible, while schema migrations, data deletion, network changes, and provider-level modifications may not be. Teams should plan forward recovery as well as rollback. Backups, snapshots, blue-green environments, canary changes, and temporary parallel resources may reduce risk.

FinOps and the Economics of Automation

FinOps is an operating discipline that brings engineering, finance, and business stakeholders together to create shared accountability for technology cost. It does not mean reducing expenditure indiscriminately. The aim is to maximize business value from cloud spending while preserving reliability, security, and performance.

IaC is a powerful FinOps mechanism because cost-related controls can be encoded. Standard modules can select approved instance families, apply schedules to non-production environments, attach budgets and tags, and reject unbounded resources. Plans can display estimated cost changes before approval. Dashboards can allocate expenditure to products, teams, environments, and business capabilities.

FinOps decisions involve trade-offs. A larger instance may cost more but reduce latency and improve customer experience. Multi-zone redundancy increases cost but may be necessary for availability. Reserved capacity or committed-use discounts may reduce unit cost but create obligations that are unsuitable for uncertain workloads. Automation should therefore expose cost and assumptions rather than optimize a single metric.

The FinOps lifecycle is often described through informed visibility, optimization, and continuous operation. Visibility requires reliable allocation and forecasting. Optimization examines rightsizing, scheduling, storage lifecycle, autoscaling, architectural choices, and purchasing models. Continuous operation embeds cost into design reviews, deployment pipelines, service-level objectives, and post-incident analysis.

A useful unit-economics measure might be cost per transaction, customer, build, or environment. Such measures are more meaningful than a total monthly bill because they relate spending to value and growth. Cost anomalies should trigger investigation, but automated shutdown must be designed cautiously: an apparently idle resource may support disaster recovery, compliance, or a scheduled workload.

Applied Case: Standardizing a Multi-Environment Cloud Platform

Background

The following is an illustrative case. Northstar Analytics, a growing data-services company, operates a customer-facing API and a batch-processing platform in a public cloud. Development and production were created by different engineers at different times. Production was partly documented in a wiki, while development depended on manually configured virtual machines.

Situation and problem

Deployments frequently failed because environment variables, network rules, and operating-system packages differed. A production security review found several resources without owners and one storage service with an overly broad access policy. Monthly cloud costs varied significantly because temporary test environments were not consistently removed. During an incident, the team could not confidently reconstruct which infrastructure changes had been made during the previous quarter.

Analysis

The organization’s primary problem was not the absence of a particular cloud product. It was the absence of a controlled infrastructure lifecycle. Manual provisioning produced drift; shared credentials weakened accountability; state was not centrally managed; and cost information could not be connected to products. The team also treated infrastructure recovery as an operational hope rather than a tested capability.

Approach and solution

Northstar first defined a platform baseline: network segmentation, identity roles, encryption, centralized logging, backup requirements, tagging, and approved regions. The baseline was implemented as versioned reusable modules. Product repositories then composed the modules for development, staging, and production.

A remote, encrypted state backend with locking and version history was introduced. Separate state boundaries were established for shared networking, application infrastructure, and data services. Existing resources were imported after reconciliation, and all resource ownership was recorded through mandatory tags.

The team adopted image-based deployment for API workers. A build pipeline created a versioned image from an approved base, scanned dependencies, ran tests, and promoted the same image across environments. Persistent data remained in managed services with backup and restoration tests.

Policy checks blocked unencrypted storage, public database access, missing ownership tags, and use of unapproved regions. Exceptions required a documented expiry. Secrets moved from repository variables into a managed secrets service, and deployment identities were limited to the resources they needed.

For FinOps, development environments received automatic schedules, cost allocation tags, budget alerts, and plan-time cost review. Engineers were not penalized for necessary spending; instead, service owners reviewed cost per customer transaction alongside reliability and performance indicators.

Outcome

The new model made environment differences explicit and reviewable. Deployments became more predictable, recovery procedures became testable, and security findings could be detected before resources were created. The organization also gained a basis for discussing cost as a design attribute rather than as a finance-only concern.

The solution did not eliminate operational judgment. Some changes still required manual approval, and stateful migrations remained carefully planned. The principal improvement was that exceptions became visible, owned, and temporary rather than hidden in undocumented infrastructure.

Learning points

The case demonstrates that IaC is an organizational control system as much as a technical tool. Reusable modules, secure state, policy enforcement, image-based delivery, secrets management, and FinOps are mutually reinforcing. Automation creates value only when ownership, review, observability, and recovery are designed with it.

Challenges, Limitations, and Professional Risks

IaC can reproduce a poor architecture very efficiently. Automation does not correct excessive privileges, weak network design, inadequate backups, or unclear ownership. Teams should therefore review architecture and operational requirements before translating them into code.

Abstraction introduces another risk. A module may conceal important provider behavior, making engineers believe that a simple change is harmless. Documentation, examples, versioning, and visible plans are necessary. Overly complex repositories can also discourage contributions and encourage manual workarounds.

Provider APIs change, resources reach end of life, and tool versions introduce incompatibilities. Pinning versions, maintaining upgrade policies, testing upgrades, and monitoring provider advisories reduce these risks. Teams should avoid depending on undocumented behavior.

Automation can amplify mistakes. A faulty policy or module may affect hundreds of resources. Blast-radius limits, staged rollouts, approvals for destructive operations, and emergency stop procedures are therefore essential. A successful plan does not prove that the resulting service is functionally correct.

Governance must also avoid becoming a barrier to delivery. Central platform teams should provide safe defaults and self-service interfaces rather than requiring every product team to understand every cloud detail. At the same time, self-service must operate within non-negotiable security, compliance, and cost boundaries.

Ethically and professionally, engineers are responsible for protecting customer data, preserving availability, maintaining accurate records, and making automation understandable to those who operate it. Infrastructure definitions should not become a means of concealing surveillance, bypassing accountability, or transferring risk to users without disclosure. Regulatory requirements concerning data location, retention, access, and auditability must be translated into enforceable controls where feasible.

Emerging Directions

Platform engineering is increasingly packaging IaC, policy, observability, identity, and deployment workflows as internal products. Developers consume approved capabilities through templates or service catalogs while platform teams maintain the underlying standards.

GitOps extends declarative management by treating a version-control repository as the authoritative source for desired system state. Controllers continuously reconcile running environments with that state. This model improves auditability but requires careful handling of secrets, emergency changes, and reconciliation loops.

Cloud development increasingly uses ephemeral environments created for branches or pull requests. These environments accelerate integration testing but make cleanup, data protection, quota management, and cost control particularly important.

Artificial intelligence can assist with generating infrastructure suggestions, explaining plans, detecting anomalies, and identifying policy violations. However, generated code may contain insecure permissions, hidden costs, or incorrect assumptions. Human review, automated testing, provenance, and least privilege remain necessary. AI should support engineering judgment rather than replace accountability.

Best-Practice Checklist

A professional IaC and cloud-automation capability should normally include:

• version-controlled definitions and peer-reviewed changes;
• reusable, versioned modules with clear ownership;
• remote, encrypted, locked, and recoverable state;
• explicit separation of environments and appropriate blast-radius boundaries;
• automated validation, security scanning, policy checks, and plan review;
• least-privilege, auditable pipeline identities;
• managed secrets with rotation and access monitoring;
• immutable images for suitable stateless workloads;
• tested backups, restoration, migration, and disaster-recovery procedures;
• mandatory tagging for ownership, environment, data classification, and cost;
• cost estimates, budgets, anomaly detection, and unit-economics measures;
• documented exceptions with expiry and compensating controls; and
• continuous reconciliation of actual infrastructure with declared intent.

Chapter Summary

Infrastructure as Code expresses infrastructure as versioned, reviewable, and executable definitions. Declarative IaC focuses on desired state and idempotent reconciliation, while imperative automation remains useful for specialized procedures. Provisioning, configuration management, and immutable infrastructure solve different parts of the infrastructure lifecycle and should be combined deliberately.

Reliable IaC depends on reusable modules, standardized environments, secure state management, controlled promotion, testing, and explicit ownership. Policy as code turns security and governance requirements into enforceable controls, while secrets management protects credentials throughout their lifecycle. FinOps connects infrastructure decisions with business value through allocation, forecasting, optimization, and continuous cost awareness. The broader lesson is that automation is not simply a productivity mechanism: it is a means of improving reliability, security, accountability, recoverability, and economic decision-making.

Key Terms

Infrastructure as Code: Managing infrastructure through versioned, machine-readable definitions and automation.

Declarative configuration: A specification of the desired end state rather than a sequence of commands.

Imperative automation: Automation that explicitly defines the actions and order of execution.

Desired state: The condition that infrastructure code declares should exist.

Configuration drift: Divergence between declared infrastructure and actual infrastructure.

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

Provisioning: Creating or modifying infrastructure resources.

Configuration management: Maintaining software and operating-system settings on hosts or platforms.

Immutable infrastructure: Infrastructure replaced from tested images rather than repeatedly modified in place.

Module: A reusable, parameterized group of infrastructure definitions.

State: Information used to associate IaC declarations with real infrastructure resources.

State locking: A mechanism that prevents conflicting concurrent state operations.

Policy as code: Machine-evaluable rules governing security, compliance, architecture, or operations.

Secrets management: Secure storage, controlled use, rotation, and auditing of sensitive credentials.

Environment standardization: Applying common architecture, controls, and processes across environments.

GitOps: A reconciliation model in which version control represents desired operational state.

FinOps: A cross-functional discipline for maximizing business value from technology spending.

Infrastructure drift: Another term for the loss of alignment between code and deployed infrastructure.

Blast radius: The extent of systems affected by a failure or change.

Unit economics: Cost measurement related to a meaningful business unit such as a transaction or customer.

Review Questions

Short Answer Questions

1. What is the difference between desired state and current state in IaC?

2. Define idempotence and explain why it matters in infrastructure automation.

3. Why should IaC state be stored in a protected remote backend?

4. What is the purpose of policy as code?

5. How does immutable infrastructure reduce configuration drift?

Long Answer Questions

1. Explain the complete lifecycle of an IaC change, from modeling through reconciliation.

2. Compare declarative IaC, imperative automation, and configuration management, including suitable uses for each.

3. Discuss how environment standardization can preserve consistency without forcing identical capacity in every environment.

4. Explain the relationship among secrets management, least privilege, pipeline security, and auditability.

5. Describe how FinOps principles can be embedded in IaC repositories and cloud-delivery pipelines.

Analytical / Application Questions

1. A team discovers that production contains resources absent from its repository and that two engineers often apply changes simultaneously. Diagnose the risks and propose a state-recovery and governance plan.

2. Design an IaC promotion strategy for a service with stateless application workers, a managed database, and strict data-residency requirements. Identify which components can be immutable and which require migration controls.

3. A development department wants automatic deletion of all resources that appear idle to reduce cost. Evaluate the proposal and design a safer policy that balances FinOps, disaster recovery, compliance, and operational risk.

22. Multiple Choice Questions with Answers

Question 1

A team changes a cloud resource manually after an IaC deployment. What is the most likely result if the code is not updated?

A. The resource becomes automatically immutable

B. Configuration drift develops between declared and actual state

C. The state backend permanently deletes the resource

D. The provider converts the change into a policy

Correct Answer: B. Configuration drift develops between declared and actual state

Question 2

Which practice best supports safe collaboration when multiple engineers manage the same infrastructure?

A. Keeping state only on each engineer’s laptop

B. Using a shared remote backend with encryption and locking

C. Disabling version control for emergency changes

D. Allowing concurrent applies without coordination

Correct Answer: B. Using a shared remote backend with encryption and locking

Question 3

Which situation is most appropriate for immutable infrastructure?

A. Repeatedly editing a production server by hand

B. Replacing stateless application workers from a tested image

C. Storing database records inside a disposable image

D. Changing secrets directly in a container image

Correct Answer: B. Replacing stateless application workers from a tested image

Question 4

What is the primary purpose of policy as code?

A. To replace all application testing

B. To encode and automatically evaluate governance and security rules

C. To increase the number of manual approvals

D. To hide infrastructure plans from reviewers

Correct Answer: B. To encode and automatically evaluate governance and security rules

Question 5

Which action is most consistent with sound secrets management?

A. Committing credentials to a private repository

B. Printing tokens in deployment logs for troubleshooting

C. Using a managed secrets service with controlled access and rotation

D. Embedding production passwords in a base image

Correct Answer: C. Using a managed secrets service with controlled access and rotation

Question 6

Why are reusable IaC modules valuable?

A. They eliminate the need for environment-specific values

B. They provide consistent, versioned components with controlled interfaces

C. They prevent all infrastructure changes

D. They make state management unnecessary

Correct Answer: B. They provide consistent, versioned components with controlled interfaces

Question 7

A company wants to reduce non-production cloud costs without affecting production availability. Which approach is most appropriate?

A. Delete all resources with no owner immediately

B. Schedule eligible development resources and apply ownership and cost tags

C. Disable backups across every environment

D. Use the largest instances to finish tests faster

Correct Answer: B. Schedule eligible development resources and apply ownership and cost tags

Question 8

Why is rollback sometimes insufficient for infrastructure changes?

A. All infrastructure changes are irreversible

B. Data migrations and destructive changes may not be safely reversible

C. Version control cannot store infrastructure code

D. Declarative tools cannot produce plans

Correct Answer: B. Data migrations and destructive changes may not be safely reversible

Question 9

Which measure best reflects FinOps-oriented unit economics?

A. Total number of source files

B. Number of engineers on the platform team

C. Cloud cost per customer transaction

D. Number of pull requests alone

Correct Answer: C. Cloud cost per customer transaction

Question 10

What is a major risk of a highly automated but poorly governed infrastructure system?

A. It cannot create resources quickly

B. A faulty module or policy can propagate errors across many resources

C. It always prevents configuration drift

D. It makes peer review unnecessary

Correct Answer: B. A faulty module or policy can propagate errors across many resources