IT PATH
My Path

Containers and Infrastructure as Code

Package workloads in containers and manage environments declaratively with version-controlled infrastructure code.

Certification
CompTIA Cloud+
Recommended study time
6h 35m
Status
Not started

Recommended study time

About 6h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 9 sittings.

  • Read the lesson23 min

    About 3,035 words at a careful technical reading pace.

  • Second pass with notes14 min

    Re-read the harder parts and write your own notes.

  • Recall from memory12 min

    2 written recall questions.

  • Practice decision12 min

    One applied decision with feedback.

  • Teach it back20 min

    Write the topic in your own words.

  • Real-world scenario15 min

    Read the situation and justify your decision in writing.

  • Hands-on practice3h 20m

    Labs, commands and configuration until you can do it unaided.

  • Spaced review1h 40m

    4 short review sessions spread over the following weeks.

Learning objectives

  • Explain images, containers, registries, and orchestration responsibilities.
  • Describe declarative infrastructure, state, and drift.
  • Apply basic supply-chain and configuration hygiene to both practices.

Start here

About 8 minutes of reading, in 10 short parts.

Containers package an application with everything it needs to run consistently anywhere, and infrastructure as code applies that same idea of a written, version-controlled definition to entire environments. Together they turn 'it worked on my machine' into a rare event instead of a running joke.

Where you meet it: Someone manually changes a production server's configuration to fix an urgent problem, and the next automated deployment silently reverts the fix, breaking things all over again.

The lesson, part by part

Open one part at a time. Each part stands on its own, so you can stop and come back.

A container is like a fully packed shipping crate for an application: everything the application needs — its code, its exact library versions, its configuration — travels together in one sealed box, so it behaves the same whether it is opened on a developer's laptop, a testing server, or a production cloud environment. Without that crate, applications tend to depend quietly on whatever happens to already be installed on a particular machine, which is exactly why something can work perfectly on one computer and fail mysteriously on another.

Infrastructure as code applies the same idea to the environment itself, not just the application. Instead of an administrator manually clicking through settings to build a server or network, the entire desired setup is written down as a file, the same way a recipe is written down rather than kept only in a chef's memory. Anyone can read that file to understand exactly what exists, recreate it identically elsewhere, and see precisely what changed by comparing an old version of the recipe to a new one.

Key ideas

If you remember nothing else from this topic, remember these.

  • Containers package an application with its dependencies into a single portable unit that runs consistently across different environments, unlike a virtual machine which also virtualizes an entire operating system.
  • A container image is built in layers from a Dockerfile, and each instruction adds a new layer, which is why layer ordering affects build speed and image size.
  • Infrastructure as code defines infrastructure in version-controlled configuration files, such as Terraform, so environments are reproducible, reviewable, and no longer dependent on manual console clicks.
  • Idempotency in infrastructure as code means running the same configuration repeatedly produces the same end state rather than creating duplicate or conflicting resources.
  • Orchestration platforms like Kubernetes manage container scheduling, scaling, and recovery automatically, restarting failed containers and distributing them across available nodes.
  • Treating infrastructure as code enables a documented, auditable change history through version control, replacing tribal knowledge about how an environment was configured.

Migrating a manually configured server to containers and Terraform

A worked example, step by step.

A team relies on a single manually configured server nobody fully documented, and a hardware failure risk pushes them to rebuild it as reproducible, version-controlled infrastructure.

  1. 01Audit the existing serverThe team reviews installed packages, running services, and configuration files on the old server to understand exactly what it does before replacing it.
  2. 02Write a DockerfileA Dockerfile is created starting FROM a minimal base image, copying the application code, installing dependencies, and defining the command that starts the application.
  3. 03Build and test the imagedocker build -t app:1.0 . creates the image, and docker run -p 8080:8080 app:1.0 confirms the application behaves the same as it did on the original server.
  4. 04Define infrastructure as codeA Terraform configuration is written describing the compute instance, network, and container runtime needed to host the image, replacing what used to be manual console steps.
  5. 05Plan before applyingterraform plan shows exactly what resources will be created, letting the team review the change before anything is provisioned.
  6. 06Apply the configurationterraform apply provisions the new infrastructure, and the containerized application is deployed onto it.
  7. 07Verify idempotencyRunning terraform apply again with no changes reports no changes needed, confirming the configuration is idempotent rather than recreating resources.
  8. 08Store everything in version controlThe Dockerfile and Terraform configuration are committed to a git repository, giving the team a reviewable, auditable record of exactly how the environment is built.
  9. 09OutcomeThe previously undocumented manual server is replaced by a reproducible, version-controlled setup that can be rebuilt identically at any time.

Outcome: Containerizing the application and defining its infrastructure as code eliminated the single point of undocumented manual configuration.

Containers and infrastructure as code reference

Worth keeping at hand while you work.

Container
Packages an application with its dependencies, sharing the host kernel rather than virtualizing a full operating system.
Virtual machine
Virtualizes an entire operating system on top of a hypervisor, heavier than a container but more isolated.
Dockerfile
A text file of instructions describing how to build a container image, layer by layer.
docker build
Builds a container image from a Dockerfile.
docker run
Starts a container from an image, optionally mapping ports and volumes.
Image layer caching
Docker reuses unchanged earlier layers on rebuild, so ordering instructions from least to most frequently changed speeds up builds.
Terraform
An infrastructure as code tool that provisions and manages cloud resources from declarative configuration files.
terraform plan
Shows what changes would be made without applying them.
terraform apply
Provisions or updates infrastructure to match the configuration.
Idempotency
Running the same configuration repeatedly produces the same end state rather than duplicating resources.
Kubernetes
An orchestration platform that schedules, scales, and restarts containers automatically across a cluster of nodes.
Version control for infrastructure
Storing configuration files in a system like git for review, history, and rollback of infrastructure changes.

Common misunderstandings

What most beginners get wrong here.

  • Containers and virtual machines provide the same level of isolation.

    Containers share the host kernel and are more lightweight but less isolated than virtual machines, which virtualize an entire separate operating system.

  • Running terraform apply repeatedly will keep creating new copies of the same resources.

    Terraform configurations are meant to be idempotent, so reapplying an unchanged configuration reports no changes rather than duplicating resources.

  • Dockerfile instruction order does not matter as long as the final image works.

    Instruction order affects layer caching and rebuild speed, since Docker reuses unchanged earlier layers, so frequently changing instructions should come last.

  • Infrastructure as code is just documentation of what was clicked in a console.

    It is the authoritative, executable definition of the infrastructure itself, meant to be applied directly rather than describing manual steps after the fact.

  • Kubernetes is only needed for very large scale applications.

    Its automatic scheduling, scaling, and self-healing benefits apply even to modest deployments that want resilience without manual intervention.

Exam traps

How the question writers try to catch you out.

  • A question contrasting containers and virtual machines is testing the shared-kernel versus full-OS-virtualization distinction, not just size differences.
  • Terraform plan versus apply is a commonly tested distinction: plan previews, apply executes.
  • Idempotency questions expect recognition that reapplying the same infrastructure as code configuration should not create duplicate resources.
  • Dockerfile layer caching questions expect understanding that reordering instructions can significantly speed up repeated builds.
  • Kubernetes questions often test recognition of self-healing behavior, such as automatically restarting a failed container, as a defining feature.

Check yourself

Answer in your head first, then reveal. This is not scored.

  • What is the key architectural difference between a container and a virtual machine?

  • What does terraform plan do that terraform apply does not?

  • Why does Dockerfile instruction ordering affect build speed?

  • What does it mean for an infrastructure as code configuration to be idempotent?

  • What is one defining self-healing behavior of Kubernetes?

Quick reference

A condensed summary of the lesson above, for revision.

What It Is

A container image packages an application with its dependencies; a container is a running instance isolated by kernel namespaces and cgroups. Registries distribute images by tag or digest. Orchestrators such as Kubernetes schedule containers, manage health, and handle scaling. Infrastructure as code declares desired resources in files, applies them through a provider, and tracks state so drift can be detected.

Why It Matters

Reproducibility is what makes recovery, scaling, and audit possible. It also concentrates risk: a compromised base image or an over-permissioned pipeline affects every environment it builds.

How It Works

  • Images are built in layers and distributed through registries by tag or digest.
  • The orchestrator reconciles actual pod state with the declared desired state.
  • Infrastructure tooling compares declared configuration to recorded state and applies the difference.

Where You See It

  • CI/CD pipelines, microservice platforms, cloud landing zones, ephemeral test environments, and disaster recovery rebuilds.

Key Terms

Image digest
Immutable content hash identifying an exact image.
Namespace/cgroup
Kernel features providing isolation and resource limits.
Orchestrator
System scheduling and supervising containers across nodes.
Drift
Difference between declared configuration and actual resources.
State file
Record mapping declared resources to real infrastructure.

Examples

  • Pinning an image by digest prevents an unexpected upstream change from reaching production.
  • A plan step shows exactly which resources would be created, changed, or destroyed before applying.

Common Problems

  • Mutable latest tags
  • Secrets baked into images
  • State file conflicts
  • Manual changes causing drift
  • Containers running as root

How It Fails

  • Two engineers applying simultaneously can corrupt or conflict on shared state.
  • A manually edited resource is reverted or duplicated on the next apply.
  • A vulnerable base image propagates to every service built from it.

How to Troubleshoot

  1. Compare declared configuration to actual resources to identify drift.
  2. Inspect image provenance and digest when behaviour changes unexpectedly.
  3. Read container logs and events before restarting; restarts hide crash causes.

Practical Knowledge

  • Store state remotely with locking and restrict who can apply changes.
  • Scan images for vulnerabilities and run as a non-root user by default.

Exam Coverage

  • Containers, images, and orchestration
  • Infrastructure as code concepts
  • Automation and DevOps practices in cloud

Interview Questions

  • What is configuration drift and why does it matter?
  • Why pin container images by digest rather than tag?

Watch and read

Verified official and reputable sources for this topic. Links open in a new tab.

Video training

  • Professor Messer video channel — general CompTIA training (no dedicated CompTIA Cloud+ course)

    Professor Messer

    Video
    Free
    Watch

Lesson notes and bookmark

Notes and bookmarks for this lesson, saved with everything else you have marked.

No notes on this item yet.

Learning progress

0% across six evidence areas. Reading alone does not change progress.

Understanding0%
Recall0%
Application0%
Practical ability0%
Troubleshooting0%
Retention0%

Prerequisites

Next steps

  1. 01Build a small container image and inspect its layers and user.
  2. 02Read an infrastructure plan output and explain each proposed change.