Infrastructure, Containers, and Cloud-Native Delivery

Introduction

Continuous integration and continuous delivery (CI/CD) become significantly more powerful when the infrastructure that runs an application is managed with the same discipline as application code. Modern delivery teams therefore treat servers, networks, container platforms, security policies, and cloud resources as versioned, testable, and repeatable technical assets.

This chapter examines the relationship between infrastructure as code (IaC), containers, orchestration, declarative configuration, environment consistency, GitOps, and cloud-based pipeline services. The emphasis is practical: a learner should be able to recognize the role of each technology, understand how the technologies fit together, and design a basic delivery workflow.

A useful distinction is that CI/CD automates the movement of software, whereas cloud-native delivery automates both the software and the platform on which it runs. This reduces configuration drift, shortens recovery time, and makes deployment processes more auditable. However, automation does not remove responsibility. Poorly designed automation can reproduce insecure settings quickly and at large scale.

Learning Objectives

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

• explain the purpose and principles of infrastructure as code;
• distinguish imperative and declarative configuration;
• describe how containers improve packaging and environment consistency;
• explain the roles of container images, registries, and orchestration platforms;
• outline a basic GitOps operating model;
• compare self-managed and cloud-based pipeline services;
• identify security, governance, cost, and operational limitations; and
• design a simple cloud-native delivery workflow.

1. Infrastructure as Code

Infrastructure as code is the practice of defining infrastructure in machine-readable files that can be stored, reviewed, tested, and applied through automation. Infrastructure includes virtual machines, networks, firewalls, databases, identity roles, storage, Kubernetes resources, and managed cloud services.

Without IaC, an administrator may create a server through a web console, install packages manually, change firewall rules, and record the steps informally. The resulting environment may work, but it is difficult to reproduce exactly. A second administrator may make slightly different choices, creating configuration drift.

With IaC, the desired infrastructure is represented in files. A simplified example might look like this:

resource "cloud_network" "application" {
  name = "application-network"
  cidr = "10.20.0.0/16"
}

resource "cloud_service" "web" {
  name     = "web-service"
  image    = "registry.example/web:1.4.2"
  replicas = 3
}

The syntax above is illustrative rather than tied to a particular provider. A typical IaC tool compares the declared configuration with the current environment, creates a plan, and applies the required changes.

Benefits of IaC

The principal benefits are:

1. Repeatability. Development, test, and production environments can be created from controlled definitions.
2. Reviewability. Infrastructure changes can pass through pull requests and peer review.
3. Traceability. A version-control history shows who changed what and when.
4. Automation. Infrastructure provisioning can be integrated into CI/CD pipelines.
5. Recovery. A documented environment can be rebuilt after failure, although stateful data still requires separate backup and recovery planning.
6. Standardization. Reusable modules and policies reduce unnecessary variation.

IaC is not simply a collection of scripts. It is a management approach in which infrastructure changes are treated as software changes. This implies testing, documentation, access control, code review, and controlled release.

IaC workflow

A common workflow is:

1. A developer or platform engineer changes an IaC file.
2. A CI job formats and validates the file.
3. Automated checks examine security, policy, and dependencies.
4. A plan is generated to show the proposed infrastructure changes.
5. Reviewers approve the change.
6. An authorized process applies the plan.
7. The result is verified through health checks and monitoring.

The plan step is important because it gives reviewers an opportunity to detect destructive or unexpected changes before they occur.

State and drift

Many IaC systems maintain state: a record of resources that the tool manages and their relevant identifiers. State must be protected because it may contain sensitive values or enable control over infrastructure. Teams commonly store state in a secured remote backend with encryption, access control, locking, and versioning.

Drift occurs when the actual environment changes outside the IaC process. For example, an operator may manually open a firewall port. A later comparison between the desired definition and the actual environment can reveal this difference. Teams must decide whether to import the manual change, revert it, or formally modify the IaC definition. Uncontrolled exceptions weaken the reliability of the model.

2. Imperative and Declarative Configuration

An imperative approach specifies the steps to take. A shell script might install a package, edit a configuration file, start a service, and open a port. The author describes how to reach the desired condition.

A declarative approach specifies the desired condition. The system determines the operations required to reach that condition. For example, a deployment definition may state that three instances of version 1.4.2 must be running. The orchestration platform creates, replaces, or removes instances as necessary.

Declarative does not mean automatic or risk-free. A mistaken declaration can remove resources or expose services. Moreover, some operations—such as data migration—are inherently procedural and require carefully ordered actions. In practice, platforms often combine declarative resource definitions with imperative migration and release steps.

An operation is idempotent when applying it repeatedly produces the same intended result after the first successful application. For example, “ensure user deploy exists” is more safely repeatable than “append this line to the user file,” which may create duplicates each time it runs.

3. Containers and Images

A container packages an application process with its executable code, libraries, and selected configuration so that it can run consistently across compatible host systems. Containers share the host operating system kernel, unlike traditional virtual machines, which normally include a guest operating system. This makes containers relatively lightweight and fast to start, although they do not provide identical isolation characteristics to virtual machines.

A container image is an immutable, layered package used to create containers. A simplified Dockerfile is:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY src/ .
USER 10001
EXPOSE 8080
CMD ["python", "server.py"]

This example demonstrates several good practices: using a small base image, installing declared dependencies, copying application content, avoiding root execution, and documenting the listening port. EXPOSE is descriptive; it does not by itself publish the port to a network.

A typical container workflow is:

1. Build an image from a version-controlled definition.
2. Run unit and integration tests against the image.
3. Scan the image and its dependencies for known vulnerabilities.
4. Push the image to a registry.
5. Deploy the image by an immutable digest or a controlled tag.
6. Monitor the running workload.

Tags and digests

A tag such as web:1.4.2 is convenient but may be mutable. If the tag is later moved to a different image, the same deployment definition can produce a different result. A digest identifies image content more precisely. Production systems often promote a tested image by digest, while human-readable tags support navigation and release communication.

Container security

Containers should not be treated as automatically secure. Important controls include:

• use trusted and maintained base images;
• rebuild images regularly to receive security fixes;
• minimize packages and privileges;
• run as a non-root user where possible;
• scan source dependencies and image layers;
• avoid embedding passwords, tokens, or private keys in images;
• use read-only filesystems and restricted capabilities when appropriate; and
• apply resource limits and network policies.

A vulnerability scanner reports findings, not necessarily exploitable risk. Teams must consider severity, exposure, reachability, available fixes, and business context. A scanner is therefore an input to risk management rather than a substitute for it.

4. Orchestration and Declarative Reconciliation

Running one container manually is straightforward. Running hundreds of containers across multiple hosts introduces scheduling, service discovery, health checking, scaling, rollout, storage, and networking problems. Container orchestration platforms address these concerns.

A simplified orchestrator model includes:

• Workload definitions: describe applications, replicas, images, and configuration.
• Scheduler: selects suitable hosts or nodes.
• Controller: compares the desired and observed states.
• Service discovery: provides stable names or virtual endpoints.
• Health management: restarts or removes unhealthy instances.
• Rolling deployment: replaces old instances gradually.
• Secrets and configuration management: supplies runtime values separately from the image.

For example, a Kubernetes-style deployment might be represented as:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: registry.example/web@sha256:abc123...
        ports:
        - containerPort: 8080

The controller continuously attempts to make the observed environment match this desired state. If one replica fails, the platform may create a replacement. This is reconciliation: a repeated control process rather than a one-time deployment command.

Orchestration does not eliminate application design responsibilities. Applications should support graceful shutdown, health endpoints, externalized configuration, horizontal scaling where appropriate, and safe handling of duplicate or retried requests.

5. Environment Consistency

An application can pass tests and still fail after deployment because the environments differ. Differences may include operating-system libraries, runtime versions, environment variables, database schemas, network permissions, time zones, or external service behavior.

Containers reduce some differences by packaging the runtime and dependencies. They do not solve all consistency problems. The host kernel, CPU architecture, managed services, secrets, network controls, and data state remain external factors.

A practical consistency model has several layers:

Environment-specific values should be separated from application artifacts. Configuration may be injected through environment variables, mounted files, a configuration service, or a secrets manager. Secrets require stronger protection than ordinary configuration: encryption, least-privilege access, rotation, audit logging, and prevention of accidental log exposure.

A useful principle is “build once, promote many.” The same tested artifact should move from a lower environment to a higher environment, while approved configuration and access controls vary by environment. Rebuilding separately for production undermines confidence that the tested artifact is the deployed artifact.

6. GitOps

GitOps is an operating model in which a version-control repository is the primary source of truth for the desired state of an environment, and an automated agent reconciles the actual environment with that state.

A basic GitOps flow is:

1. A change is proposed through a pull request.
2. CI validates manifests, tests policy, and may build an image.
3. After review and approval, the desired deployment state is merged.
4. A GitOps controller detects the change.
5. The controller applies or reconciles the state in the target cluster.
6. Status, events, and health checks report whether convergence succeeded.

GitOps improves auditability because the desired state is represented in version control. It also supports rollback by reverting a commit, although rollback is not always sufficient for irreversible database changes or external side effects.

There are two common repository patterns. In a single repository, application code and deployment definitions are maintained together. In separate repositories, application teams manage source code while a platform or operations repository manages environment definitions. The first pattern provides close coupling and simple traceability; the second can create clearer separation of duties but requires a reliable artifact-promotion process.

GitOps challenges include secret management, repository access, emergency changes, reconciliation delays, and the risk of allowing the controller excessive privileges. Emergency access should be controlled, logged, and followed by reconciliation with the repository so that the documented desired state remains accurate.

7. Cloud-Based Pipeline Services

Cloud providers offer managed services for source repositories, build execution, artifact storage, deployment, secrets, observability, and container orchestration. Examples include managed pipeline products, hosted runners, container registries, serverless build systems, and managed Kubernetes platforms.

A cloud-based pipeline commonly contains these stages:

Commit → Build → Test → Scan → Package → Publish → Deploy → Verify

The pipeline may use a managed source repository, an ephemeral build worker, an artifact registry, a deployment service, and a managed runtime. Ephemeral workers are created for a job and discarded afterward, reducing contamination between builds. They still require controlled images, network access, identity permissions, and logging.

Managed versus self-managed delivery

Cloud services do not remove architecture decisions. Teams must evaluate identity federation, data residency, regulatory obligations, service limits, network topology, backup, disaster recovery, logging retention, and exit strategies.

Pipeline identity and permissions

A pipeline should receive only the permissions required for its stage. For example, a test job may need read access to dependencies but no production deployment permission. A production deployment job may require narrowly scoped access to a deployment target. Short-lived federated credentials are generally preferable to long-lived static keys stored in pipeline variables.

Approvals should be meaningful rather than ceremonial. A production approval can confirm test evidence, change scope, risk assessment, rollback readiness, and the identity of the artifact being promoted.

8. Practical Delivery Design

Consider a small online bookstore whose service is packaged as a container and deployed to a managed Kubernetes cluster. The team uses Git for source code, an IaC tool for cloud resources, a container registry, and a cloud-hosted pipeline.

Background and problem

The bookstore initially uses manually created virtual machines. Developers test with one runtime version, while production uses another. Deployments are performed from an administrator’s laptop, and an emergency configuration change is not recorded. Releases are slow and difficult to reproduce.

Analysis

The main problems are configuration drift, weak release traceability, mutable deployment procedures, and excessive operational privilege. The team decides that the application artifact, infrastructure definition, and deployment configuration must be versioned and validated.

Approach

The team adopts the following design:

• The application is built into an image using a version-controlled Dockerfile.
• Unit, integration, and API contract tests run in CI.
• The image is scanned and pushed to a private registry.
• An image digest, rather than an unqualified mutable tag, is recorded for promotion.
• Network, cluster, registry, and identity resources are defined with IaC.
• Kubernetes manifests specify replicas, probes, resource requests, and deployment strategy.
• Environment overlays provide approved differences for test and production.
• A GitOps repository stores the desired cluster state.
• A controller reconciles the approved state into the cluster.
• Metrics, logs, traces, and deployment events are sent to a managed observability service.

A simplified promotion sequence is:

Developer commit
      ↓
CI: build, test, scan
      ↓
Registry: immutable image
      ↓
Pull request updates deployment digest
      ↓
Review and approval
      ↓
GitOps reconciliation
      ↓
Health checks and monitoring

Outcome

The team can identify which source revision produced a running image and which change caused a deployment. A failed rollout is stopped by health checks, and a previous desired state can be restored for a compatible application change. Reproducibility improves, although database rollback remains a separate concern.

Learning points

The case demonstrates that cloud-native delivery is a system rather than a single tool. Containers address packaging; IaC addresses infrastructure; orchestration addresses runtime coordination; GitOps addresses controlled desired-state delivery; and cloud services provide managed execution and integration. These components must be designed together.

9. Limitations, Governance, and Responsible Practice

Cloud-native technology can introduce complexity. A small application may not need a cluster, service mesh, multiple deployment repositories, or elaborate platform abstractions. Technology should be proportionate to operational needs and team capability.

Important limitations include:

• Hidden complexity: managed platforms simplify operation but may obscure networking, identity, and failure behavior.
• Cost variability: pay-per-use resources, data transfer, storage, and idle environments can create unexpected expenditure.
• Vendor dependence: provider-specific APIs and services may increase migration cost.
• Stateful workloads: containers and orchestration do not automatically solve database consistency, backups, or disaster recovery.
• Observability burden: distributed systems require correlation identifiers, structured logs, metrics, traces, and clear ownership.
• Failure amplification: an incorrect pipeline or IaC module can affect many environments quickly.

Governance should include policy as code where useful, mandatory review for sensitive changes, separation of duties, protected branches, artifact provenance, vulnerability handling, audit logs, and documented recovery procedures. Compliance requirements may affect where data is processed, how long logs are retained, who can approve releases, and how evidence is collected.

Artificial intelligence can assist with log summarization, configuration suggestions, test generation, and anomaly detection. Nevertheless, generated IaC or deployment configuration must be reviewed and tested. AI systems may produce insecure permissions, invalid assumptions, or code that appears plausible but does not match the organization’s policy. Human accountability remains essential.

10. Best Practices Checklist

A practical baseline for certificate-level work is:

• Keep application, infrastructure, and deployment definitions in version control.
• Use pull requests and protected branches for important environments.
• Validate and format IaC automatically.
• Review an infrastructure plan before applying changes.
• Build immutable, minimal container images.
• Pin important dependencies and prefer image digests for production promotion.
• Run tests and vulnerability scans before deployment.
• Keep secrets out of source code and images.
• Use least-privilege identities and short-lived credentials.
• Define health checks, resource limits, and rollout behavior.
• Monitor both technical health and business outcomes.
• Document rollback, backup, and disaster recovery procedures.
• Prefer simple architectures that the team can operate reliably.

Chapter Summary

Infrastructure as code represents infrastructure in versioned, machine-readable definitions and enables repeatable provisioning, review, and recovery. Declarative configuration describes a desired state, while controllers or IaC tools determine how to achieve it; imperative procedures remain useful for ordered operations such as data migration.

Containers package applications and dependencies into portable images, but they do not remove the need for security, configuration management, or operational discipline. Orchestration platforms schedule workloads, provide service discovery and health management, and continually reconcile actual state with declared state. Environment consistency depends on more than containers: build processes, infrastructure, data, secrets, and observability must also be controlled.

GitOps uses version control as the source of truth for deployment state and uses an automated reconciler to apply approved changes. Cloud-based pipeline services reduce platform maintenance but require careful decisions about identity, cost, governance, data control, and provider dependence. Effective cloud-native delivery is therefore a coordinated practice combining software engineering, infrastructure management, security, and operations.

Key Terms

Infrastructure as code: Managing infrastructure through versioned, machine-readable definitions.

Configuration drift: Difference between the documented desired state and the actual environment.

Declarative configuration: Specification of the required end state rather than a sequence of steps.

Imperative configuration: Instructions that describe the operations to perform.

Idempotence: Property whereby repeated application produces the same intended result.

Container: An isolated process packaged with its application dependencies.

Container image: Immutable, layered package used to create containers.

Container registry: Service that stores and distributes container images.

Image digest: Content-based identifier for a particular image.

Orchestration: Automated coordination of containers or workloads across computing resources.

Reconciliation: Repeated comparison and correction between desired and observed state.

Infrastructure state: Record used by an IaC system to track managed resources.

GitOps: Delivery model using version control as the source of truth for operational state.

Artifact promotion: Moving a tested build artifact through environments without rebuilding it.

Secret: Sensitive value such as a password, token, or private key.

Least privilege: Granting an identity only the permissions required for its task.

Rolling deployment: Gradual replacement of an old application version with a new one.

Policy as code: Machine-readable rules that automatically evaluate technical configurations.

Environment consistency: Degree to which development, test, and production conditions are equivalent.

Cloud-native delivery: CI/CD practice integrating containers, orchestration, automation, and cloud services.

Review Questions

Short Answer Questions

1. What problem does infrastructure as code address?
2. Distinguish declarative configuration from imperative configuration.
3. Why should production deployments preferably use an image digest?
4. What is the purpose of a container registry?
5. Define GitOps in one or two sentences.

Long Answer Questions

1. Explain the complete lifecycle of an IaC change, from editing a file to verifying the applied infrastructure.
2. Describe how containers improve environment consistency and identify at least three problems they do not solve.
3. Explain the main components and responsibilities of a container orchestration platform.
4. Compare managed cloud pipeline services with self-managed CI/CD platforms.
5. Discuss the security and governance controls required for a cloud-native delivery pipeline.

Analytical / Application Questions

1. A team builds a new image separately for test and production. Analyze the risks and recommend a promotion strategy.
2. An operator manually changes a production firewall rule that is not present in the IaC repository. Explain the possible responses and recommend a governance process.
3. Design a basic GitOps workflow for a web application, identifying the repositories, pipeline stages, deployment controls, and monitoring evidence required.

Multiple Choice Questions with Answers

Question 1

Which statement best describes infrastructure as code?

A. Managing infrastructure only through a graphical cloud console

B. Representing infrastructure in versioned, machine-readable definitions

C. Packaging application source code into a container image

D. Monitoring application logs after deployment

Correct Answer: B. Representing infrastructure in versioned, machine-readable definitions

Question 2

What is the main characteristic of declarative configuration?

A. It specifies the desired end state

B. It requires every command to be executed manually

C. It can only be used for operating-system installation

D. It prevents all configuration errors

Correct Answer: A. It specifies the desired end state

Question 3

Why is an image digest useful in production deployment?

A. It automatically encrypts the application

B. It identifies image content more precisely than a mutable tag

C. It eliminates the need for testing

D. It increases the number of image layers

Correct Answer: B. It identifies image content more precisely than a mutable tag

Question 4

Which responsibility is primarily associated with container orchestration?

A. Writing application business logic

B. Scheduling workloads and maintaining desired replicas

C. Replacing all database backups

D. Designing user-interface layouts

Correct Answer: B. Scheduling workloads and maintaining desired replicas

Question 5

What is configuration drift?

A. A container becoming smaller during a build

B. A difference between desired configuration and actual configuration

C. A planned rolling deployment

D. A vulnerability scan with no findings

Correct Answer: B. A difference between desired configuration and actual configuration

Question 6

In a GitOps model, what normally acts as the source of truth for desired deployment state?

A. An administrator’s unrecorded terminal session

B. A version-control repository

C. A temporary container filesystem

D. A developer’s local cache

Correct Answer: B. A version-control repository

Question 7

Which practice best protects pipeline credentials?

A. Store long-lived administrator keys in source code

B. Use least-privilege, short-lived credentials

C. Print credentials in build logs for auditing

D. Give every pipeline stage full production access

Correct Answer: B. Use least-privilege, short-lived credentials

Question 8

What does “build once, promote many” mean?

A. Rebuild the application separately in every environment

B. Use the same tested artifact across environments

C. Deploy without running tests

D. Create multiple mutable tags for production

Correct Answer: B. Use the same tested artifact across environments

Question 9

Which statement about containers is correct?

A. Containers automatically provide complete virtual-machine isolation

B. Containers package processes and dependencies but still require security controls

C. Containers eliminate the need for configuration management

D. Containers cannot run on cloud platforms

Correct Answer: B. Containers package processes and dependencies but still require security controls

Question 10

What is a major advantage of a managed cloud pipeline service?

A. It removes all architectural and governance decisions

B. It reduces the organization’s responsibility for platform maintenance

C. It guarantees that deployments cannot fail

D. It eliminates provider dependence

Correct Answer: B. It reduces the organization’s responsibility for platform maintenance