Application Deployment Fundamentals: Containers and Docker – one of the most transformative ideas in modern IT. Without containers, getting software to run reliably from a developer's laptop to a production server is an endless nightmare of missing libraries, wrong configurations, and 'it works on my machine' frustrations. For the 200-901 exam, you need to understand why containers exist, how they work, and how Docker makes them practical – because the entire DevNet Associate syllabus assumes you grasp this foundation.
Jump to a section
A simple way to picture Application Deployment Fundamentals: Containers and Docker
Have you ever ordered a flatpack wardrobe from a certain Swedish furniture store, only to discover the instructions are useless and you have to rebuild the entire thing from scratch every time you move house? That is exactly the problem containerisation solves for software.
Think about a new app that needs to run on your friend's laptop. Without containers, you would have to ship them the raw lumber, saw, screws, drill, and paint – in other words, the entire operating system, all its libraries, and every dependency your app needs. Your friend would have to assemble it piece by piece, hoping the screwdriver they own is the right size. If they break a screw, the whole wardrobe collapses. Every time they move to a different operating system (a different flatpack style), they have to start the build process again.
A container is like a flatpack furniture box that is already fully assembled inside its packaging. The box contains the app, all its dependencies, and exactly the right version of the runtime it needs – all perfectly snug. When you want to run the app on a different computer, you just slide the sealed container onto that computer's operating system. The container does not care whether the host computer is a Windows machine, a Mac, or a Linux server. It just runs, because everything it needs is already inside the box.
Docker is simply the factory that builds these pre-assembled boxes. You write a recipe, called a Dockerfile, which tells Docker exactly what to put in the box: the base layers (like the plywood), the app code (the shelves and drawers), and the glue (the dependencies). Docker then snaps the lid shut, producing an 'image' – a portable snapshot of your assembled wardrobe. Any friend's computer that has Docker installed can unpack that image and start using the app in seconds, without a single screwdriver.
Let us start with the pain containers solve. Imagine you have written a simple Python program that sends a tweet every time your home thermostat changes temperature. On your laptop, it works perfectly. Now you want to run it on a server in the cloud. You copy the Python script over, but the server has Python 2.7 installed, not Python 3.10 that your script uses. You install Python 3.10, but then the server lacks the 'tweepy' library. You install that, only to discover the server's Linux distribution does not have the exact version of SSL certificates needed. You spend three hours fiddling. This nightmare is called the 'dependency hell' – software depends on precise versions of other software, and environments differ wildly.
A container is a lightweight, standalone, executable package that includes everything the software needs to run: code, runtime, system tools, libraries, and settings. Crucially, it does not include a full operating system kernel; it shares the host machine's kernel but isolates the application's view of the filesystem, network, and processes. Think of a container as an isolated bubble where your app lives with exactly the environment it needs. Containers are portable – you can build the bubble on your laptop and run it unchanged on a server in Tokyo.
Docker is the most popular platform for working with containers. It provides tools to build, ship, and run containers. The key components of Docker are:
Docker Engine: The core runtime that creates and manages containers on your machine.
Docker Images: Read-only templates that define what goes into a container. An image is like a frozen snapshot – you cannot edit it, only use it to create containers.
Docker Containers: Running instances of an image. When you 'run' an image, Docker creates a writable layer on top of the read-only layers, letting your app modify files inside the container.
Dockerfile: A plain-text recipe that tells Docker how to build an image. It lists base images, copies files, installs dependencies, and sets commands.
Docker Hub: A public registry where you can store and share images, like a library of pre-built containers anyone can use.
How does it all work in practice? First, you write a Dockerfile. For a simple Python app, it might look like this:
FROM python:3.10-slim (start from an official Python image)
WORKDIR /app (set the working directory inside the container)
COPY . . (copy your code from your laptop into the image)
RUN pip install tweepy (install the library)
CMD ["python", "app.py"] (command to run when container starts)
You then run 'docker build -t my-twitter-app .' which reads the Dockerfile, executes each instruction sequentially, and creates an image. You can see your images with 'docker images'. Finally, you run 'docker run my-twitter-app' which creates a container from that image and starts your app. The container runs in isolation – it has its own filesystem, its own network interface (by default a private IP), and its own process space. If the container crashes, it does not crash your laptop. If you run two containers from the same image, they are completely independent; one can have 1000 users while the other has 0.
Why did containers replace virtual machines for many use cases? Virtual machines (VMs) emulate an entire physical computer – CPU, memory, storage, network card – each running its own full operating system. This is heavy: a VM might take 5 GB of disk space and minutes to boot. A container shares the host OS kernel (Linux, Windows, etc.) and only includes the application and its dependencies, so it might take 50 MB and start in seconds. Containers also scale better: a single server can host hundreds of containers, whereas the same server could only host maybe ten VMs before running out of resources. However, containers are less secure than VMs because they share the kernel; a break-out from a container could compromise the host.
For the exam, remember this essential distinction: a container is an instance of an image. An image is a blueprint. A container is the running building. You can have multiple containers from the same image. Docker images are made of layers – each instruction in a Dockerfile creates a new layer. Layers are cached, so if you rebuild an image after changing only the last step, Docker reuses the cached earlier layers, making builds fast.
Container orchestrators like Kubernetes (covered in another chapter) manage many containers across multiple servers, handling scaling, networking, and failure recovery. But for the DevNet Associate, the focus is on the fundamentals: what containers are, what Docker does, and how images relate to containers.
Install Docker Engine
The first practical step is to install Docker Desktop (for Windows/Mac) or Docker Engine (for Linux) on your machine. This installs the Docker daemon, which manages containers, plus the 'docker' CLI tool. Without this, you cannot run any containers.
Write a Dockerfile
Create a text file named 'Dockerfile' (no extension) in your project directory. This file specifies the instructions to build your image. For a simple web app, this includes a base image (FROM python:3.10-slim), setting a working directory, copying code, installing dependencies, exposing a port, and setting the default command.
Build the Docker image
Run 'docker build -t my-app .' in the project directory. Docker reads the Dockerfile line by line, executes each instruction, and caches layers. The '-t' flag tags the image with a name and optionally a version (e.g., my-app:latest). The dot '.' is the build context – the directory where Docker looks for files referenced in COPY instructions.
Run a container from the image
Execute 'docker run -p 8080:80 my-app' to create and start a container. The '-p' flag maps host port 8080 to container port 80, so you can open http://localhost:8080 to access the app. The container runs in the foreground (it prints logs to your terminal) unless you add the '-d' flag for detached mode (background).
Manage running containers
Use 'docker ps' to see running containers. Use 'docker stop container_id' to stop one, and 'docker start container_id' to restart it. To remove a stopped container, run 'docker rm container_id'. To remove its image, first ensure no containers are using it, then 'docker rmi image_name'. This lifecycle management is crucial for understanding how containers are ephemeral.
Push the image to a registry
After testing locally, tag your image with a registry name (e.g., 'docker tag my-app your-username/my-app:v1') and push it with 'docker push your-username/my-app:v1'. This makes the image available on Docker Hub (or your private registry) so other machines can pull and run it – this is how you share containers across environments.
Meet Priya, a DevOps engineer at a mid-sized e-commerce company that sells handmade candles. The company runs a web application (Node.js front-end, Python back-end, PostgreSQL database) across three environments: development on her laptop, testing on a staging server, and production on Amazon Web Services (AWS).
Priya's day starts with a bug report: the shopping cart occasionally shows the wrong total. She fixes the Python code on her laptop. Before containers, she would have had to manually copy the updated Python file to the staging server, activate a virtual environment, ensure the correct Python version was installed, restart the service, and hope nothing broke. Now, she changes the Dockerfile to copy the new code, rebuilds the Docker image with 'docker build -t candle-app:latest .', pushes it to her company's private registry on AWS Elastic Container Registry (ECR), then on the staging server runs 'docker pull candle-app:latest && docker-compose up -d'. The whole process takes 30 seconds.
Later, Priya needs to add a new feature that requires a different version of a Python library. She creates a new branch of her Dockerfile, tests it locally, and asks a colleague to review. Because the entire environment is captured in the Dockerfile, the colleague can exactly reproduce Priya's environment on their own machine with just 'docker build' and 'docker run'. No more 'it works on my machine' arguments.
When the company runs a Black Friday sale, traffic spikes tenfold. Priya works with the operations team to spin up more container instances using AWS ECS (a container-orchestration service). Each new container is an exact copy of the image she built – same code, same dependencies, same environment. She scales back down after the sale. Without containers, scaling would have required provisioning new virtual servers, installing dependencies, and deploying the app from scratch – a process that could take hours.
In an emergency – a critical security vulnerability in the Python image base layer – Priya receives an alert. She updates the Dockerfile to the patched base image, rebuilds, and redeploys all containers. The update is atomic: old containers are stopped and new ones started in seconds, with no downtime because the orchestrator handles rolling updates.
What does Priya actually touch? She writes Dockerfiles, uses 'docker build', 'docker push', 'docker pull', and 'docker run' at the command line. She uses 'docker ps' to see running containers and 'docker logs' to check output when something goes wrong. She composes multi-container apps using docker-compose.yml files that define services, networks, and volumes. She never logs into a server to patch anything – she just builds a new image and replaces the old containers.
The key takeaway for the exam: the real world is about repeatability and speed. Containers give you the same environment every time, everywhere. That is why the industry loves them.
The 200-901 exam tests 'Application Deployment Fundamentals: Containers and Docker' primarily through multiple-choice questions (single answer, multiple answer) and drag-and-drop tasks. Cisco wants you to demonstrate that you can distinguish between core concepts, not that you can write a Dockerfile from memory. However, you should be able to read a simple Dockerfile and know what each instruction does.
Here are the exact concepts the exam loves:
Distinguishing between an image and a container: this is the most common trick. They might say 'An image is a running instance of a container' – that is false. A container is a running instance of an image.
Knowing what Docker Engine does: it is the runtime that builds and runs containers. Not the same as Docker Hub (a registry) or Docker Compose (a multi-container tool).
Understanding layers: each instruction in a Dockerfile creates a new read-only layer. When you run a container, Docker adds a writable layer on top. They might ask: 'What happens to changes made inside a running container when it stops?' – answer: they are lost unless you commit the container as a new image or use a volume.
The difference between a VM and a container: containers share the host OS kernel; VMs have their own kernel. This means containers are lighter, start faster, but are less isolated.
Dockerfiles and key instructions: FROM (specifies the base image), RUN (executes commands during build), COPY (copies files from host to image), CMD (default command when container starts), EXPOSE (documents port, does not publish it). They might give you a Dockerfile and ask what it does.
Port mapping: containers have their own internal network. To reach a container from outside, you map a host port to a container port using -p 8080:80 (host port 8080 maps to container port 80). Exam questions may ask: 'Which Docker command maps host port 3000 to container port 3000?' – answer: docker run -p 3000:3000.
Registries: Docker Hub is the default public registry. You can have private registries (like Amazon ECR). The command to download an image is 'docker pull'; to upload an image is 'docker push'.
The 'docker ps' command: lists running containers. 'docker ps -a' lists all containers, including stopped ones. Expect a question like 'How do you see all containers on your system, including stopped?' – answer: docker ps -a.
Container vs host networking: the default is bridge networking, where containers get private IPs. Host networking shares the host's network stack, so the container directly uses the host's IP. They might test which is more secure (bridge is default and more isolated).
Common traps:
They confuse 'image' with 'container' in the answer options. Always read carefully.
They list 'VIRTUAL MACHINES' as a synonym for 'CONTAINERS' in a list – do not pick it.
They ask about 'docker build' expecting you to know it takes a Dockerfile as input. A distractor might say 'docker run' builds an image.
For the 'docker run' command, they might list arguments that do not exist, like '--image myapp' (the correct flag is the image name directly).
Memorise these key definitions:
Image: a read-only template with instructions to create a container.
Container: a runnable instance of an image.
Dockerfile: a text document with all commands to assemble an image.
Registry: a repository for storing and sharing images.
Layer: a modification in the image, corresponding to a Dockerfile instruction.
Expect one or two scenario questions where a developer says 'I built a container on my machine and it works, but on the server it fails'. The answer is likely 'the environments differ' or 'missing dependencies' – but the correct 200-901 answer is that containers ensure consistency, so if it fails on the server it is probably because the server is running a different Docker version or a different architecture (e.g., ARM vs x86).
Practise reading Dockerfiles and predicting what the final image will contain. Look for the order of instructions: later instructions overwrite earlier ones if they conflict (e.g., two COPY commands for the same path). The exam may ask 'What is the final file content after this Dockerfile?'
A container is a running instance of a Docker image, not the other way round.
Containers share the host OS kernel, making them far more lightweight than virtual machines.
The Dockerfile is a recipe; each instruction (FROM, RUN, COPY) creates a new read-only layer in the final image.
Changes inside a container are lost when the container is deleted unless you use volumes or commit the container as a new image.
Docker Hub is a public registry; you can also use private registries like Amazon ECR or Azure Container Registry.
The 'docker ps' command shows only running containers; 'docker ps -a' includes stopped containers.
Port mapping (-p host_port:container_port) is required to access services inside a container from the host or external network.
Containers provide environment consistency across development, testing, and production environments.
These come up on the exam all the time. Here's how to tell them apart.
Docker Image
Read-only template that defines the filesystem, dependencies, and configuration.
Cannot be executed directly; it is a blueprint.
Created by 'docker build'; stored as layered filesystem.
Docker Container
Running instance of an image with an additional writable layer.
Can be started, stopped, restarted, and deleted.
Created by 'docker run'; has a unique ID and lifecycle.
Virtual Machine (VM)
Each VM includes a full guest operating system kernel.
Typically gigabytes in size and minutes to boot.
Stronger isolation because each VM runs its own kernel.
Container
Shares the host operating system kernel.
Typically megabytes in size and seconds to start.
Less isolated; a kernel exploit can affect all containers on the host.
Docker Compose
Used for defining and running multi-container applications on a single host.
Uses a docker-compose.yml file for configuration.
Best for development and small-scale production.
Kubernetes
Container orchestration platform for managing containers across multiple hosts.
Uses declarative YAML manifests for deployment, scaling, and service discovery.
Best for large-scale, production-grade deployments with high availability.
Mistake
Containers are just lightweight virtual machines.
Correct
Containers share the host operating system kernel; virtual machines each have their own kernel. This makes containers much lighter (megabytes vs gigabytes) and faster to start (seconds vs minutes), but also less isolated because a kernel exploit in the host can affect all containers.
The term 'virtualisation' is often used loosely for both, and the visual of a box inside a box makes people think of VMs. People miss the critical difference: VM level 1 hypervisor, container level 2 sharing the host OS.
Mistake
If I run 'docker run' once, any changes I make inside the container are saved permanently.
Correct
Changes made inside a running container are stored in that container's writable layer, which is ephemeral. When the container is deleted (not just stopped), all changes are lost. To persist data, you must use Docker volumes (to mount host directories) or commit the container to a new image.
New users treat a container like a persistent virtual machine where you install things and they stay. In reality, containers are designed to be stateless and disposable.
Mistake
Docker images are just compressed archives of the app code.
Correct
Docker images are built from layered file systems where each Dockerfile instruction creates a new read-only layer. Layers are cached and shared between images. An image includes not just code but also a base OS (like Ubuntu), runtime (like Python), libraries, and configuration files.
People familiar with ZIP files or tarballs assume a monolithic archive. They do not understand why images are often hundreds of megabytes – because they contain the entire runtime tree.
Mistake
A Dockerfile is only used to create images; after that you never need it again.
Correct
The Dockerfile is the source of truth for how the image is built. You should keep it in version control. When you need to update the image (security patches, new features), you edit the Dockerfile and rebuild. Without the Dockerfile, you have only a binary image that cannot be audited or reproduced easily.
Beginners think of the image as the 'product' and the Dockerfile as a disposable build script. In professional settings, the Dockerfile is the crucial asset.
Mistake
By default, a container's port is only accessible within the container's internal network (bridge network). To make it accessible from outside, you must explicitly map a host port to the container port using the -p flag (e.g., -p 8080:80).
Correct
Running a container with 'docker run' will always expose the app on the same port as the host.
New users assume containers are automatically accessible from the host, like a regular program. They do not understand network namespaces and default isolation.
Mistake
A Docker image can be run directly without Docker Engine if you have the right OS.
Correct
Docker images are specifically built to be run by the Docker Engine. The image format includes manifest files, layer metadata, and configuration that only the Docker runtime understands. You cannot simply extract an image like a ZIP file and run it natively on a server.
Users who think of images as archives with executables assume they can just copy files. They miss the entire container runtime mechanism.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes and no. Docker Desktop for Windows uses a lightweight Linux virtual machine under the hood to run Linux containers. Windows containers are also possible but require a Windows host. For beginners, sticking with Linux containers is standard.
'docker build' creates a Docker image from a Dockerfile. 'docker run' creates a container from an image and starts it. Always build first, then run.
Not by default. Once the container is deleted, changes are lost. You can use Docker volumes to mount a host directory into the container, allowing persistent file storage across restarts.
A registry is a storage for Docker images. Docker Hub is the default public one. You need it to share images between machines; you can skip it if you only run containers on your local machine.
If the main process inside the container finishes (e.g., a script that runs once and exits), the container exits. Use interactive mode ('-it' flag) to keep it alive, or run a long-running service (like a web server) as the main command.
Use 'docker logs container_id' to print the standard output of the container. Use '-f' to follow the logs live, similar to 'tail -f'.
You've finished Application Deployment Fundamentals: Containers and Docker. Continue through the 200-901 study guide to build a complete picture of the exam.
Done with this chapter?