Infrastructure as Code and Configuration Management

Introduction and Context

Modern software systems are not deployed onto manually prepared servers alone. Applications depend on networks, databases, identity services, storage, monitoring, security controls, containers, and cloud resources. As infrastructure becomes more complex, manual creation and configuration become slow, inconsistent, difficult to audit, and vulnerable to human error.

Infrastructure as Code (IaC) addresses this problem by representing infrastructure in machine-readable files that can be versioned, reviewed, tested, and executed through automation. Configuration management extends the idea to the software and operational settings installed on infrastructure. Together, IaC and configuration management support repeatable environment provisioning, safer releases, disaster recovery, and collaboration between development and operations teams.

This chapter examines immutable infrastructure, declarative and imperative automation, configuration drift, policy as code, state management, and reproducible environments. It also considers practical design choices, limitations, governance, and the relationship between these practices and DevOps delivery.

Learning Objectives

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

1. Explain the purpose and operating principles of Infrastructure as Code.
2. Distinguish declarative from imperative automation.
3. Compare mutable and immutable infrastructure.
4. Describe environment provisioning and configuration management workflows.
5. Identify, measure, and reduce configuration drift.
6. Explain state management and its importance in IaC.
7. Apply policy as code to governance and compliance.
8. Design a reproducible environment strategy and evaluate its limitations.

1. Infrastructure as Code

Infrastructure as Code is the practice of defining infrastructure resources and their relationships in files that automation tools can interpret. A definition may describe virtual networks, subnets, firewalls, virtual machines, containers, databases, DNS records, access policies, and observability services.

An IaC workflow commonly follows these stages:

1. Authoring: An engineer writes infrastructure definitions.
2. Version control: The definitions are stored in a repository with a history of changes.
3. Validation: Syntax, security, policy, and design checks are performed.
4. Planning: The tool compares the desired definition with the current state and produces a proposed change set.
5. Review: Other engineers inspect and approve the proposed change.
6. Application: Approved changes are applied to the target environment.
7. Verification: Tests and monitoring confirm that the resulting environment behaves as intended.

IaC changes infrastructure from an informal operational activity into an engineering artifact. A server is no longer merely a machine that someone configured; it is the result of a documented, repeatable process.

Desired State and Actual State

Most IaC systems distinguish between two conditions:

• Desired state: The resources and properties specified by the code.
• Actual state: The resources and properties currently observed in the environment.

Automation attempts to reduce the difference between these states. This difference is sometimes called a configuration or reconciliation gap. The tool may create missing resources, modify incorrect properties, or remove resources that are no longer declared. The exact behavior depends on the tool and its lifecycle rules.

IaC does not imply that every resource must be destroyed and recreated whenever a property changes. Some changes can occur in place; others require replacement. Engineers must understand these consequences because a seemingly small code change can affect availability, data, cost, or security.

Benefits

Important benefits include:

• Consistency: Environments are built from the same definitions.
• Repeatability: A process can be executed multiple times with predictable intent.
• Traceability: Changes are associated with commits, reviewers, and tickets.
• Speed: Automation is faster than repeated manual configuration.
• Recovery: Infrastructure can be reconstructed after failure.
• Collaboration: Infrastructure definitions can be reviewed like application code.
• Testing: Definitions can be statically analyzed and tested before deployment.

These benefits are not automatic. Poorly designed code can reproduce insecure or incorrect infrastructure very efficiently. IaC improves control over infrastructure, but it does not replace engineering judgment.

2. Declarative and Imperative Automation

The distinction between declarative and imperative approaches is central to DevOps automation.

Declarative Automation

A declarative definition states the desired result without specifying every operational step needed to achieve it. For example, a declaration may state that a web service should have three instances, use a particular network, and expose a defined port. The automation engine determines whether it must create, modify, or replace resources.

Declarative systems are usually easier to review because the file describes the intended end condition. They also support reconciliation: if actual state changes, the tool can compare it with the declared state and attempt to restore alignment.

Examples include infrastructure resource definitions, container orchestration manifests, and many configuration-management playbooks.

Imperative Automation

An imperative script specifies actions in sequence, such as:

1. Create a virtual machine.
2. Install a package.
3. Copy a configuration file.
4. Start a service.
5. Open a firewall port.

Imperative automation is useful when a process is naturally procedural, when an API exposes actions rather than desired states, or when a specialized migration must occur in a controlled order. It can also be effective for one-time operational tasks.

However, imperative scripts may become difficult to maintain. Re-running a script may fail because a resource already exists, produce a different result, or perform an unsafe action. To improve reliability, imperative operations should be designed to be idempotent where possible. An idempotent operation can be applied repeatedly and still produce the same intended result after the first successful application.

Comparison

The approaches are not mutually exclusive. A declarative infrastructure definition may invoke an imperative script for a specialized operation. Such combinations should be limited and documented because they can weaken visibility into the final state.

3. Environment Provisioning

Environment provisioning is the process of creating the infrastructure and supporting services required for an application. Typical environments include development, testing, staging, and production. Provisioning may involve:

• Network address spaces and routing
• Subnets and security groups
• Compute resources or container clusters
• Managed databases and caches
• Object storage
• DNS and certificates
• Identity and access roles
• Logging, metrics, and tracing
• Secrets-management integrations

A robust provisioning design separates reusable structure from environment-specific values. For example, the same network module may be used in testing and production, while parameters such as instance size, domain name, and replica count differ.

Provisioning Workflow

A professional workflow generally includes:

1. Define requirements such as capacity, availability, security, and data residency.
2. Model resources and dependencies.
3. Parameterize legitimate environmental differences.
4. Validate syntax and policy.
5. Generate a plan.
6. Review risk, cost, replacement behavior, and access implications.
7. Apply changes through controlled credentials.
8. Run smoke tests and operational checks.
9. Record outputs such as endpoints and resource identifiers.

Provisioning should be designed for both initial creation and subsequent change. A system that can be created once but cannot be safely updated is not operationally mature.

Modules and Reuse

Reusable modules package related infrastructure into an interface. A module might create a standard application network or a database with approved backups and encryption. Good modules expose only necessary inputs, apply secure defaults, and document outputs and limitations.

Excessive abstraction can be harmful. If a module hides important behavior, engineers may not understand what will be created or replaced. Reuse should therefore improve consistency without eliminating transparency.

4. Configuration Management

Configuration management controls the state of software and operating-system settings after infrastructure is provisioned. Examples include package versions, service settings, users, permissions, scheduled jobs, certificates, and application configuration.

Configuration management may be performed through:

• Agent-based systems: A software agent runs on each host and periodically enforces configuration.
• Agentless systems: A controller connects remotely and applies configuration when requested.
• Image-based approaches: A configured machine image is built before deployment.
• Container-based approaches: Application and runtime dependencies are packaged into immutable images.

Configuration management should distinguish between:

• Code: Versioned, reviewable behavior and definitions.
• Configuration: Values that vary by environment or deployment.
• Secrets: Credentials, tokens, private keys, and other sensitive values.
• Data: Business information that must be preserved independently of infrastructure.

Secrets should not be stored in ordinary source files or exposed in logs. Instead, applications should obtain them from a managed secret store using narrowly scoped identity permissions.

Configuration Baselines

A baseline is an approved configuration against which a system can be compared. It may specify required packages, disabled services, password policies, logging destinations, encryption settings, and patch expectations. Baselines support security and audit activities, but they must be maintained as systems and threats evolve.

5. Mutable and Immutable Infrastructure

Mutable Infrastructure

Mutable infrastructure is changed in place after it has been created. An administrator or automation process may upgrade packages, alter configuration, or install a new application version on an existing server.

This approach can be efficient, especially for legacy systems or stateful services. However, repeated changes can create unique server histories. Two machines created from the same original image may diverge because they received different manual fixes, failed updates, or emergency changes.

Immutable Infrastructure

Immutable infrastructure treats deployed instances as replaceable artifacts. When a change is required, a new image or deployment artifact is built, tested, and deployed. The old instance is then retired rather than modified extensively.

A typical immutable workflow is:

1. Build an image or container from a known base.
2. Install dependencies and application code.
3. Run security and functional tests.
4. Register the artifact with a version identifier.
5. Deploy new instances using that artifact.
6. Shift traffic gradually or all at once.
7. Retain the previous version for rollback where appropriate.

Figure: Mutable infrastructure changes existing instances, whereas immutable infrastructure replaces them with tested versions.

Immutable infrastructure reduces configuration drift and makes rollback conceptually clearer. It does not eliminate all operational problems. Data stores, persistent volumes, network services, and external integrations still require careful migration and compatibility planning. Immutable deployment also requires reliable image construction, artifact storage, health checks, and traffic management.

6. Configuration Drift

Configuration drift is the gradual divergence between the intended configuration and the actual configuration of a system. Drift may result from manual intervention, emergency fixes, unauthorized changes, failed automation, software updates, or differences in deployment timing.

Drift has several forms:

• Infrastructure drift: A resource has a different size, network rule, or tag than declared.
• Software drift: Package versions or installed services differ across hosts.
• Security drift: A permission, encryption setting, or firewall rule becomes weaker than required.
• Environment drift: Development and production differ in ways not represented by explicit design.

Detection techniques include periodic reconciliation, configuration scans, image comparison, vulnerability assessment, and cloud-provider inventory analysis. Detection alone is insufficient. Teams must decide whether to repair automatically, open a review ticket, replace the resource, or accept and document the difference.

A useful operational principle is that emergency changes should be temporary and recorded. If a manual change is necessary, it should later be incorporated into code or deliberately reverted. Otherwise, the next automated deployment may either remove a required fix or unexpectedly overwrite an undocumented change.

7. State Management

IaC tools often maintain state: a record connecting declared resources with real resource identifiers and selected properties. State enables a tool to determine what already exists and calculate changes efficiently.

State may contain sensitive information, including connection details or resource attributes. It should therefore be stored securely, encrypted in transit and at rest, and protected by access controls. In team environments, state is commonly stored in a shared backend that supports locking and version history.

Why State Matters

Without reliable state, an automation tool may:

• Attempt to create resources that already exist.
• Fail to identify which object corresponds to a declaration.
• Propose destructive changes.
• Produce conflicting results when multiple engineers apply changes concurrently.

State is not the same as the infrastructure itself. It is a model or record used to manage infrastructure. If state is lost, the resources may continue operating, but management becomes more difficult. Recovery may require importing existing resources or reconstructing the relationship between code and resources.

State Practices

Important practices include:

• Use a remote, access-controlled backend for shared work.
• Enable locking to prevent concurrent writes.
• Maintain backups and version history.
• Restrict who can read sensitive state.
• Review planned deletions and replacements carefully.
• Separate state by environment or appropriate management boundary.
• Avoid manually editing state unless a documented recovery procedure requires it.

State design also affects organizational boundaries. A single state file may make dependencies visible but increase blast radius. Many small state files can reduce risk but create dependency and coordination complexity.

8. Policy as Code

Policy as code expresses governance rules in machine-readable form and evaluates them automatically. Policies may concern security, cost, architecture, compliance, or operational practice.

Examples include:

• Storage must use encryption.
• Public network access is prohibited for databases.
• Resources must have an owner and cost-center tag.
• Production deployments require approved regions.
• Containers must not run with unnecessary privileges.
• Internet-facing services must use approved TLS settings.

Policy checks can occur at several points:

1. During code review or static analysis.
2. During plan generation before infrastructure changes.
3. At deployment admission.
4. Continuously against running resources.

Preventive policies stop a change before deployment. Detective policies identify violations after deployment. Both are useful: preventive controls reduce exposure, while detective controls identify drift and policy failures in existing systems.

Policies should be specific, explainable, and versioned. An overly broad policy can block legitimate work and encourage bypasses. Exceptions should have owners, reasons, expiry dates, and compensating controls. Governance is strongest when policy is treated as an engineering product rather than an opaque barrier.

9. Reproducible Environments

A reproducible environment can be created repeatedly from documented inputs and produce materially equivalent behavior. Reproducibility does not necessarily mean that every identifier, timestamp, or host-level detail is identical. It means that relevant properties are controlled and predictable.

Reproducibility depends on controlling:

• Base operating-system or container image versions
• Application dependencies and lock files
• Infrastructure definitions
• Configuration inputs
• Provider and tool versions
• Build instructions
• External service assumptions
• Time, locale, and regional settings where relevant

Unpinned dependencies are a major source of non-reproducibility. A build that requests “the latest” package may produce different results on different days. Version pinning, artifact retention, dependency scanning, and controlled upgrade processes reduce this risk.

A useful distinction is between reproducible and reliable. A broken configuration can be reproduced perfectly. Reproducibility is therefore a foundation for reliability, not a guarantee of quality.

Environment Parity

Development, testing, staging, and production do not need identical scale, but they should share important behavioral characteristics. Differences in operating system, database version, networking, authentication, or feature flags can cause failures that appear only after release.

Teams should make differences explicit. For example, production may use three database replicas while development uses one, but both should use compatible database engines and migration procedures. Container images, local development environments, and ephemeral test environments can reduce accidental variation.

10. Worked Application: An Online Learning Platform

The following is an illustrative case.

Background

A university online-learning platform consists of a web application, an API, a relational database, object storage for submitted assignments, and a background job system. The platform has separate development, staging, and production environments.

Problem

The operations team created the original production servers manually. Over time, production contained a different operating-system patch level, package set, and firewall configuration from staging. An emergency change was made directly on one server but not recorded. A later deployment succeeded on two servers and failed on the third. Recovery required several hours of investigation.

Analysis

The main causes were:

• Mutable servers with undocumented histories
• No authoritative infrastructure definition
• Configuration differences between environments
• Shared credentials used for manual access
• No drift detection
• An unstructured deployment process

The team also identified a critical constraint: student submissions are persistent data and must not be lost when application instances are replaced.

Approach and Solution

The team adopted the following design:

1. Network, compute, security groups, storage, and monitoring were defined in version-controlled IaC.
2. Application servers were built as immutable images containing pinned dependencies.
3. Database storage and assignment files were kept outside replaceable application instances.
4. Configuration values were parameterized by environment.
5. Secrets were placed in a managed secret store and accessed through workload identity.
6. A plan was required for every production change, with peer review.
7. Policies required encryption, ownership tags, private database access, and approved regions.
8. A continuous drift scan compared important settings with the intended baseline.
9. Deployment used a rolling strategy with health checks and an explicit rollback version.
10. Database schema changes were designed to be backward-compatible during the transition between application versions.

Outcome

New staging environments could be created consistently, and production deployments no longer depended on the historical state of individual servers. The team reduced configuration differences and improved auditability. Recovery became faster because the application layer could be rebuilt from a tested image.

The solution did not remove all risk. Database migrations, external identity-provider changes, and data recovery remained operational responsibilities. The team therefore maintained backups, tested restoration, and documented ownership for persistent services.

Learning Points

The case demonstrates that IaC is broader than writing resource files. It requires lifecycle design, security controls, state management, artifact discipline, testing, and explicit treatment of data. Immutability is most effective when persistent data and replaceable compute are clearly separated.

11. Professional, Ethical, and Governance Considerations

Infrastructure automation can create large effects quickly. A mistaken network rule may expose thousands of records; an incorrect deletion may interrupt a service or destroy data. Engineers therefore have a professional duty to design safeguards proportional to the potential harm.

Important controls include least-privilege credentials, peer review, protected branches, approval gates for high-risk changes, separation of duties, audit logs, backups, and tested recovery procedures. Automation should fail safely where possible and should make destructive actions conspicuous.

Organizations must also consider privacy and regulation. Environment definitions may specify data locations, retention periods, encryption, access logging, and backup behavior. Infrastructure code can therefore become part of evidence for compliance, but code alone does not prove that a running system remains compliant. Continuous assessment and operational records are still required.

AI-assisted coding can generate IaC templates, explain plans, or identify possible misconfigurations. Such tools can improve productivity, but generated infrastructure must be reviewed. AI may produce insecure defaults, omit provider-specific constraints, expose secrets in examples, or misunderstand the consequences of replacement. Responsibility remains with the engineer and organization deploying the change.

12. Challenges and Limitations

Complexity

Large infrastructure codebases contain dependencies, modules, variables, providers, policies, and state boundaries. Without conventions and documentation, abstraction can become difficult to understand.

Hidden Provider Behavior

Cloud and infrastructure providers may apply defaults, asynchronous operations, or restrictions that are not obvious from the code. Plans should be examined rather than accepted automatically.

Destructive Changes

Changing an identifier, storage configuration, or network relationship may cause resource replacement. Production changes require impact analysis and backups where data is involved.

Secrets and Sensitive State

Encryption and access control reduce exposure but do not eliminate it. Logs, plans, crash reports, and developer workstations can also leak secrets.

Cost and Resource Sprawl

Easy provisioning can lead to unused environments and unexpected spending. Budgets, expiration policies, tagging, and automated cleanup are necessary.

Legacy Systems

Some systems cannot be rebuilt easily because they depend on manual procedures, proprietary software, or stateful architecture. A gradual approach may combine configuration management, documentation, and selective modernization.

False Confidence

Passing an IaC plan or syntax check does not prove application correctness, security, performance, or disaster-recovery readiness. Infrastructure testing must be complemented by integration, security, operational, and recovery tests.

13. Best-Practice Design Principles

1. Treat infrastructure definitions as production code.
2. Store code in version control and require meaningful review.
3. Prefer declarative descriptions for long-lived desired state.
4. Keep imperative scripts small, idempotent, and well documented.
5. Pin important tool, provider, image, and dependency versions.
6. Separate replaceable compute from persistent data.
7. Use remote, locked, encrypted state for collaborative systems.
8. Protect secrets and avoid embedding them in code or logs.
9. Validate syntax, security, cost, and policy before application.
10. Make environment differences explicit rather than accidental.
11. Detect drift and establish a process for remediation.
12. Use immutable artifacts when they improve consistency and rollback.
13. Test restoration, not merely backup creation.
14. Monitor the running environment after deployment.
15. Document ownership, exceptions, dependencies, and recovery procedures.

Contemporary Developments

Infrastructure management increasingly incorporates containers, managed cloud services, platform engineering, and GitOps. In a GitOps model, a version-controlled repository represents the desired state and an automated controller reconciles a running environment with that state. This extends declarative management into continuous operation.

Ephemeral environments are also common in software delivery. A temporary environment can be created for a pull request, used for integration tests, and destroyed afterward. This practice improves isolation but requires cost controls, secure test data, and dependable cleanup.

Software supply-chain security has become closely connected with IaC. Organizations increasingly sign images, record provenance, scan dependencies, restrict untrusted modules, and verify that deployment artifacts originated from approved build processes. These practices recognize that infrastructure definitions and images are part of the system’s attack surface.

Chapter Summary

Infrastructure as Code represents infrastructure in versioned, machine-readable definitions and enables consistent provisioning, review, testing, and recovery. Declarative automation describes the desired result, while imperative automation specifies operational steps; mature systems often use both carefully. Configuration management controls operating-system and application settings, but secrets, data, and ordinary configuration must be treated as distinct concerns.

Mutable infrastructure changes existing instances and can accumulate undocumented history. Immutable infrastructure replaces tested artifacts and can reduce drift, although persistent data and migrations still require special treatment. Configuration drift is divergence between intended and actual state and must be detected, assessed, and remediated. State management provides the relationship between definitions and real resources, requiring secure storage, locking, backups, and careful boundaries.

Policy as code makes security, cost, and compliance rules testable and enforceable. Reproducible environments depend on controlled versions, explicit inputs, reliable artifacts, and transparent environmental differences. Successful IaC is not merely a tool choice: it combines technical design, governance, security, testing, operational ownership, and recovery planning.

Key Terms

Infrastructure as Code: Practice of defining and managing infrastructure through machine-readable files.

Desired state: The configuration that automation is intended to produce.

Actual state: The configuration currently present in an environment.

Declarative automation: Automation that specifies the intended end state.

Imperative automation: Automation that specifies a sequence of actions.

Idempotence: A property whereby repeated application produces the same intended result after success.

Environment provisioning: Creation and preparation of infrastructure and supporting services.

Configuration management: Control of software, operating-system, and service settings.

Mutable infrastructure: Infrastructure changed in place after creation.

Immutable infrastructure: Infrastructure replaced with a new tested artifact rather than extensively modified.

Configuration drift: Divergence between intended and actual configuration.

State: Information linking IaC definitions to real resources and their properties.

State locking: Mechanism preventing conflicting concurrent state updates.

Policy as code: Machine-readable governance rules evaluated automatically.

Baseline: An approved configuration used for comparison and control.

Reproducible environment: An environment that can be recreated from controlled, documented inputs.

Artifact: A versioned build output such as an image or package.

Environment parity: Similarity of important behavior and dependencies across environments.

GitOps: A model in which version-controlled desired state drives automated reconciliation.

Drift detection: The process of identifying differences between declared and running configuration.

Review Questions

Short Answer Questions

1. What is Infrastructure as Code, and why is version control important to it?
2. Distinguish declarative automation from imperative automation.
3. What is configuration drift? Give two possible causes.
4. Why must IaC state be protected and, in collaborative settings, locked?
5. State two advantages and one limitation of immutable infrastructure.

Long Answer Questions

1. Explain a complete IaC workflow from authoring through post-deployment verification.
2. Compare mutable and immutable infrastructure, including their effects on rollback, drift, and persistent data.
3. Explain how configuration management, secrets management, and infrastructure provisioning interact.
4. Discuss policy as code and distinguish preventive from detective controls.
5. Describe the technical and organizational requirements for reproducible environments.

Analytical / Application Questions

1. A production server contains a manual security fix that is absent from the IaC repository. Explain the risks of both leaving the fix undocumented and immediately overwriting it. Propose a safe remediation process.
2. Design an environment strategy for a web application with replaceable application servers and a persistent database. Identify which components should be immutable, how state should be managed, and how rollback should work.
3. An organization wants every development environment to use identical infrastructure definitions, but production requires higher capacity and stricter network controls. Explain how modules, parameters, policy as code, and testing can provide consistency without pretending that the environments are identical.

Multiple Choice Questions with Answers

Question 1

Which statement best describes declarative automation?

A. It specifies the desired end state and lets the tool determine required actions.

B. It requires an administrator to execute each command manually.

C. It always modifies resources in place and never replaces them.

D. It is limited to database schema migrations.

Correct Answer: A. It specifies the desired end state and lets the tool determine required actions.

Question 2

What is the main characteristic of immutable infrastructure?

A. Servers are patched manually throughout their entire lifetime.

B. Changes are deployed by replacing instances with tested artifacts.

C. Configuration is stored only in an administrator’s memory.

D. Persistent data is deleted whenever an application changes.

Correct Answer: B. Changes are deployed by replacing instances with tested artifacts.

Question 3

Which situation is an example of configuration drift?

A. A reviewed change updates the infrastructure definition and is applied successfully.

B. A server’s firewall rule is changed manually and no longer matches the declared configuration.

C. A new version is tested in a temporary environment.

D. A secret is retrieved from an approved secret-management service.

Correct Answer: B. A server’s firewall rule is changed manually and no longer matches the declared configuration.

Question 4

Why is state used by many Infrastructure as Code tools?

A. To store application source code instead of infrastructure definitions.

B. To connect declared resources with real resources and calculate changes.

C. To guarantee that infrastructure can never be deleted.

D. To replace all monitoring and logging systems.

Correct Answer: B. To connect declared resources with real resources and calculate changes.

Question 5

Which is the strongest example of policy as code?

A. An engineer verbally reminds a team to encrypt storage.

B. A machine-readable rule rejects a production database that permits public access.

C. A developer chooses a preferred editor for infrastructure files.

D. A team creates an unversioned spreadsheet of server names.

Correct Answer: B. A machine-readable rule rejects a production database that permits public access.

Question 6

Which practice most directly improves environment reproducibility?

A. Using unpinned dependencies so builds always receive the newest versions.

B. Allowing each engineer to install packages manually.

C. Pinning important image, tool, and dependency versions.

D. Changing configuration directly in production without recording it.

Correct Answer: C. Pinning important image, tool, and dependency versions.

Question 7

What is a major risk of storing IaC state without adequate access control?

A. The infrastructure will automatically become immutable.

B. Sensitive resource attributes may be exposed or altered.

C. Declarative definitions will become imperative scripts.

D. Testing will become mathematically impossible.

Correct Answer: B. Sensitive resource attributes may be exposed or altered.

Question 8

A team needs to run the same operational script repeatedly without changing the result after the first successful run. Which property should the script have?

A. Idempotence

B. Randomization

C. Opacity

D. Irreversibility

Correct Answer: A. Idempotence

Question 9

Which component normally requires special treatment when application servers are replaced under an immutable model?

A. A versioned application image

B. A persistent database containing business data

C. A disposable test container

D. A stateless health-check process

Correct Answer: B. A persistent database containing business data

Question 10

What is the purpose of drift detection?

A. To identify differences between intended configuration and running configuration.

B. To generate application user-interface designs.

C. To eliminate the need for backups.

D. To make all environments use the same resource capacity.

Correct Answer: A. To identify differences between intended configuration and running configuration.