Overview
Application Deployment and Security is 15% of the 200-901 exam and has the second-largest objective list, with twelve objectives. Objectives 4.1 to 4.3 cover the benefits of edge computing, the attributes of private, public, hybrid and edge deployment models, and virtual machines, bare metal and containers. Objective 4.4 describes CI/CD pipeline components, and 4.5 asks you to build a Python unit test. Objectives 4.6 and 4.7 cover reading a Dockerfile and using Docker images locally.
The security objectives follow: 4.8 covers secret protection, encryption at rest and in transit, and data handling; 4.9 explains firewalls, DNS, load balancers and reverse proxies in deployments; 4.10 describes top OWASP threats such as XSS, SQL injection and CSRF. Objective 4.11 covers Bash file management, navigation and environment variables, and 4.12 the principles of DevOps.
How it's tested
Expect short scenarios about where to deploy, Dockerfile or Bash snippets to interpret, unittest code to complete, and security cases where you name the threat or control. Many items test whether you can tell similar ideas apart, such as containers and virtual machines or a reverse proxy and a load balancer.
-
Placement decision
Latency, data residency or cost constraints are described, and you choose edge, private, public or hybrid deployment, or a VM, container or bare metal host.
-
Read the file
A Dockerfile, Bash script or unittest class is shown, and you state what it does or what line is missing.
-
Threat and control
An attack or weakness is described, such as a script tag in a form field, and you name the OWASP threat or the protection.
A factory needs video analytics that react within milliseconds and must keep raw footage on site. A public cloud region adds round-trip latency and moves data off premises, while edge computing processes data close to the cameras. Edge deployment satisfies both requirements, and summarised results can still be sent to the cloud.
Objectives 12
Official objectives from the Cisco outline, in outline order.
4.1 Describe the benefits of edge computingProcessing data near where it is produced.
- What it means
- Edge computing places compute and storage close to devices and users, such as in a branch, factory or cell site, instead of sending everything to a central data centre or cloud.
- What to understand
- Benefits include lower latency for real-time decisions, reduced bandwidth because only filtered or summarised data travels upstream, continued operation when the WAN link fails, and keeping sensitive data local for privacy or regulation. Trade-offs include managing many small sites and their physical security.
- How it shows up
- Choose edge computing for a latency, bandwidth or local-data requirement.
- Common confusion
- Assuming edge replaces the cloud; most designs combine both.
4.2 Describe the attributes of different application deployment models (private cloud, public cloud, hybrid cloud, and edge)Who owns the infrastructure and where workloads run.
- What it means
- A private cloud is dedicated to one organisation, on premises or hosted. A public cloud is shared, provider-operated infrastructure billed by use. A hybrid cloud combines private and public with workloads or data moving between them. Edge places workloads at distributed locations near users or devices.
- What to understand
- Private cloud offers control and compliance at higher capital cost. Public cloud offers elasticity, fast provisioning and pay-as-you-go pricing but less control. Hybrid suits organisations with sensitive systems that stay private while bursting or adding services in public cloud. Edge suits latency-sensitive or disconnected sites.
- How it shows up
- Match a set of business and technical constraints to a deployment model.
- Common confusion
- Calling any multi-cloud design hybrid; hybrid specifically mixes private and public.
4.3 Describe the attributes of these application deployment types: a. Virtual machines; b. Bare metal; c. ContainersThree ways to host an application.
- What it means
- Bare metal runs the operating system directly on physical hardware. Virtual machines run full guest operating systems on a hypervisor that shares hardware. Containers package an application with its dependencies and share the host kernel through a container runtime.
- What to understand
- Bare metal gives maximum performance and hardware access but is slow to provision. VMs provide strong isolation and can run different operating systems on one host. Containers start in seconds, are lightweight and portable across environments, but share the host kernel, so a Linux container needs a Linux kernel. Containers suit microservices and CI/CD pipelines.
- How it shows up
- Choose the deployment type for a performance, isolation or portability requirement.
- Common confusion
- Saying each container includes its own full operating system kernel.
4.4 Describe components for a CI/CD pipeline in application deploymentsAutomated build, test and release stages.
- What it means
- Continuous integration merges code changes frequently into a shared repository, triggering automated builds and tests. Continuous delivery keeps the application in a releasable state and deploys to production after approval; continuous deployment releases automatically when tests pass.
- What to understand
- Typical components: a source repository, a pipeline server such as Jenkins, GitLab CI or GitHub Actions, build steps that produce artefacts or container images, automated unit and integration tests, an artefact or image registry, and deployment stages to test, staging and production. Failed stages stop the pipeline and give fast feedback.
- How it shows up
- Order pipeline stages, or identify the difference between delivery and deployment.
- Common confusion
- Treating continuous delivery and continuous deployment as identical.
4.5 Construct a Python unit testWriting tests with unittest or pytest.
- What it means
- A unit test checks a single function or method in isolation. With the unittest module you subclass unittest.TestCase, write methods starting with test_, and use assertions such as assertEqual, assertTrue and assertRaises. pytest uses plain functions and assert statements.
- What to understand
- setUp runs before each test to prepare fixtures and tearDown cleans up afterwards. Tests run with python -m unittest or pytest. External dependencies such as API calls are replaced with mocks so the test stays fast and repeatable. The exam may show a test class with a missing import, base class or assertion.
- How it shows up
- Complete a unittest class or predict which assertion fails.
- Common confusion
- Naming test methods without the test_ prefix, so the runner skips them.
4.6 Interpret contents of a DockerfileReading instructions that build an image.
- What it means
- A Dockerfile is a text file of instructions: FROM sets the base image, RUN executes commands during the build, COPY and ADD bring files in, WORKDIR sets the directory, ENV sets variables, EXPOSE documents a port, and CMD or ENTRYPOINT defines what runs when the container starts.
- What to understand
- Each instruction creates a layer, so ordering affects caching: installing dependencies before copying frequently changed code speeds rebuilds. RUN happens at build time, CMD at run time. EXPOSE does not publish the port; the -p option on docker run does. ENTRYPOINT fixes the executable while CMD provides default arguments that can be overridden.
- How it shows up
- Explain what a given Dockerfile builds, or which instruction runs at container start.
- Common confusion
- Believing EXPOSE makes the port reachable from the host.
4.7 Utilize Docker images in local developer environmentPulling, building, running and inspecting containers.
- What it means
- Core commands include docker pull to fetch an image, docker build -t name . to build one, docker images to list them, docker run to start a container, docker ps to list running containers, docker exec to run a command inside one, docker logs to view output, and docker stop and rm to clean up.
- What to understand
- docker run options matter: -d runs detached, -p host:container publishes a port, -v mounts a volume, -e sets an environment variable, --name names the container and -it gives an interactive terminal. Images are templates; containers are running instances, and many containers can start from one image.
- How it shows up
- Choose the docker run options that publish a port or mount code from the host.
- Common confusion
- Reversing the host and container ports in -p.
4.8 Describe application security issues related to secret protection, encryption (storage and transport), and data handlingKeeping credentials and data safe.
- What it means
- Secrets such as API keys, tokens and passwords must not be hard-coded or committed to Git. Encryption in transit uses TLS; encryption at rest protects stored data and backups. Data handling covers classifying data, minimising what is collected, validating input and controlling access.
- What to understand
- Store secrets in environment variables, a secrets manager or vault, and rotate them. Use HTTPS with certificate validation rather than disabling verification. Hash passwords with a salted algorithm rather than encrypting them reversibly. Avoid logging sensitive data and apply least privilege to the accounts scripts use.
- How it shows up
- Identify the safest way to supply a credential to a script or protect stored data.
- Common confusion
- Treating Base64 or obfuscation as encryption.
4.9 Explain the role of firewalls, DNS, load balancers, and reverse proxy in application deploymentNetwork services in front of and around an application.
- What it means
- Firewalls permit or deny traffic by address, port or application. DNS resolves names to addresses and can steer clients. Load balancers distribute requests across several servers and remove unhealthy ones. A reverse proxy sits in front of servers, receives client requests and forwards them, often terminating TLS and caching.
- What to understand
- Together these services provide availability, scale and security. Many products combine reverse proxy and load balancing. A deployment problem may come from a missing firewall rule, a wrong DNS record or a failed health check rather than the code. Knowing which service does what helps locate the fault.
- How it shows up
- Name the service that matches a role, such as TLS termination or spreading load.
- Common confusion
- Confusing a forward proxy, which acts for clients, with a reverse proxy, which acts for servers.
4.10 Describe top OWASP threats (such as XSS, SQL injections, and CSRF)Common web application attacks and their defences.
- What it means
- The OWASP Top 10 lists the most critical web application risks. Cross-site scripting injects script into pages viewed by other users. SQL injection inserts SQL into input that is built into a database query. Cross-site request forgery tricks a logged-in user's browser into sending an unwanted request.
- What to understand
- Defences: output encoding and input validation for XSS, parameterised queries for SQL injection, anti-CSRF tokens and SameSite cookies for CSRF. Exam stems describe the symptom, such as a comment field that runs JavaScript in other users' browsers, and ask for the threat name or mitigation.
- How it shows up
- Identify the attack from a scenario or choose its mitigation.
- Common confusion
- Mixing up XSS, which targets other users' browsers, with CSRF, which abuses a user's authenticated session.
4.11 Utilize Bash commands (file management, directory navigation, and environmental variables)Everyday shell use in Linux environments.
- What it means
- Bash commands include cd, pwd and ls for navigation; mkdir, cp, mv, rm, touch and cat for files; chmod and chown for permissions; and export, env and echo $VAR for environment variables.
- What to understand
- Relative paths start from the current directory, absolute paths from /, and .. means the parent. rm -r removes directories recursively. export makes a variable available to child processes, which is how scripts often receive API keys. Settings placed in ~/.bashrc persist for new shells.
- How it shows up
- Choose the command for a file or variable task, or predict the result of a command sequence.
- Common confusion
- Setting a variable without export and expecting a child process to see it.
4.12 Describe the principles of DevOps practicesCulture and practices joining development and operations.
- What it means
- DevOps brings development and operations together through shared responsibility, automation, continuous integration and delivery, monitoring and fast feedback, aiming to deliver changes frequently and reliably.
- What to understand
- Common principles include small, frequent changes; automating build, test and deployment; infrastructure as code; measuring and monitoring everything; blameless learning from failures; and collaboration across teams. The CALMS model summarises culture, automation, lean, measurement and sharing.
- How it shows up
- Recognise a DevOps practice from a description of how a team works.
- Common confusion
- Thinking DevOps is only a set of tools rather than a cultural practice.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Containers vs VMs
Containers share the host kernel; VMs run full guest operating systems.
- Remember
- Containers are lighter and faster to start.
- Tested as
- Deployment type questions.
- Trap
- Claiming containers give stronger isolation than VMs.
-
Hybrid cloud
Private and public cloud used together.
- Remember
- Workloads or data move between them.
- Tested as
- Deployment model matching.
- Trap
- Labelling two public clouds as hybrid.
-
Continuous delivery vs deployment
Ready to release with approval versus released automatically.
- Remember
- Deployment removes the manual gate.
- Tested as
- Pipeline questions.
- Trap
- Using the terms interchangeably.
-
unittest.TestCase
Base class for Python unit tests.
- Remember
- Methods must start with test_.
- Tested as
- Test construction items.
- Trap
- Forgetting to subclass TestCase.
-
RUN vs CMD
RUN executes at build time; CMD at container start.
- Remember
- Only the last CMD takes effect.
- Tested as
- Dockerfile interpretation.
- Trap
- Thinking RUN starts the application.
-
docker run -p
Publishes host:container ports.
- Remember
- Host port first.
- Tested as
- Local Docker usage.
- Trap
- Relying on EXPOSE alone.
-
Secret storage
Environment variables or a secrets manager, never source code.
- Remember
- Rotate and limit secrets.
- Tested as
- Security scenario questions.
- Trap
- Committing a .env file to Git.
-
Reverse proxy
Front end that forwards client requests to servers.
- Remember
- Often terminates TLS.
- Tested as
- Network service roles.
- Trap
- Confusing it with a forward proxy.
-
SQL injection
Untrusted input altering a database query.
- Remember
- Fix with parameterised queries.
- Tested as
- OWASP scenario items.
- Trap
- Relying on client-side validation alone.
-
CSRF
Forged request sent with a victim's session.
- Remember
- Anti-CSRF tokens prevent it.
- Tested as
- OWASP scenario items.
- Trap
- Calling it XSS.
-
export
Makes a shell variable an environment variable.
- Remember
- Child processes inherit it.
- Tested as
- Bash usage items.
- Trap
- Expecting unexported variables in scripts.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Deployment types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Bare metal | OS directly on hardware | Best raw performance, slow provisioning | Assuming it is the most portable |
| Virtual machine | Guest OS on a hypervisor | Strong isolation, heavier footprint | Ignoring guest OS overhead |
| Container | App plus dependencies on shared kernel | Fast and portable | Running a Windows container on a Linux kernel |
OWASP threats
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| XSS | Injected script runs in other users' browsers | Targets page output | Fixing it with database changes |
| SQL injection | Input changes a database query | Targets the back-end query | Using string concatenation for queries |
| CSRF | Forged request with the victim's session | Abuses existing authentication | Assuming HTTPS alone prevents it |
Front-end network services
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Load balancer | Spreads requests across servers | Health checks and distribution | Expecting it to resolve names |
| Reverse proxy | Forwards requests on behalf of servers | TLS termination, caching | Calling it a forward proxy |
| DNS | Resolves names to addresses | Name-based steering | Overlooking stale records during outages |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Container isolation
- What candidates pick
- Containers for the strongest isolation between tenants
- Why it looks right
- Containers are modern and widely recommended
- Why it's wrong
- Containers share the host kernel; virtual machines give stronger isolation with separate kernels.
Clue to watch for Words like strict tenant isolation or different operating systems.
-
Dockerfile start command
- What candidates pick
- RUN python app.py
- Why it looks right
- RUN executes commands
- Why it's wrong
- RUN executes only while building the image; the start command belongs in CMD or ENTRYPOINT.
Clue to watch for The stem asks what runs when the container starts.
-
Secret handling
- What candidates pick
- Base64-encode the API key inside the script
- Why it looks right
- Encoded text looks hidden
- Why it's wrong
- Base64 is reversible; secrets should come from environment variables or a vault.
Clue to watch for Mention of storing or sharing scripts.
-
Deployment model
- What candidates pick
- Hybrid cloud for workloads spread across two public providers
- Why it looks right
- More than one cloud sounds hybrid
- Why it's wrong
- Hybrid combines private and public; two public providers is multicloud.
Clue to watch for Check whether a private environment is involved.
-
Pipeline gate
- What candidates pick
- Continuous deployment when a manager approves releases
- Why it looks right
- Deployment sounds like releasing
- Why it's wrong
- A manual approval step makes it continuous delivery.
Clue to watch for Any human approval before production.
Answer framework
Work through these steps for deployment, packaging or security scenarios in this domain.
- Identify the constraint driving the question, such as latency, data location, isolation, portability, speed of release or a security weakness.
- For placement questions, map the constraint to edge, private, public or hybrid deployment and to bare metal, virtual machines or containers.
- For files and commands, separate build-time from run-time actions and host settings from container settings before choosing an answer.
- For pipeline and DevOps items, decide where automation stops and whether a human gate exists, which separates delivery from deployment.
- For security items, name the asset at risk, then pick the specific control that addresses it rather than a general good practice.
Practice question
Want more like this? The CCNA Automation practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Install Docker and spend a session packaging a small Flask or FastAPI app that calls a Cisco sandbox API. Write the Dockerfile yourself, build it, run it with and without -p and -e, and use docker exec and docker logs to look inside. Then add a unittest file for one function, run it locally, and wire both steps into a simple pipeline in GitHub Actions or GitLab CI. Doing this once teaches objectives 4.4 to 4.7 and 4.11 better than reading about them.
Cover the descriptive objectives with a comparison sheet: deployment models, deployment types, and the four network services, each with one line on when to choose it. For security, learn the three named OWASP threats by symptom and fix, and practise spotting hard-coded secrets in code snippets. Bash needs only the common commands and how export works. Keep DevOps to its principles. Because twelve objectives share 15% of the exam, aim for even coverage rather than mastering any single topic deeply.
FAQ
How much is Application Deployment and Security worth on the CCNA Automation exam?
Application Deployment and Security is 15% of the 200-901 exam and has twelve official objectives, more than most other domains despite the modest weight.
Do I need to write a Dockerfile from scratch?
Objective 4.6 asks you to interpret Dockerfile contents and 4.7 to use Docker images locally. Writing one yourself is the fastest way to learn to read them.
Which Python test framework does the exam use?
Objective 4.5 asks you to construct a Python unit test. The standard unittest module is the safest focus, though pytest syntax is worth recognising.
How much OWASP knowledge is required?
Know the OWASP Top 10 exists and be able to describe XSS, SQL injection and CSRF, how each works and how each is prevented.
Is Kubernetes in scope?
Kubernetes is not named in the objectives. Containers are covered through Docker images, Dockerfiles and the container deployment type.
Which Bash topics appear?
File management, directory navigation and environment variables, as stated in objective 4.11, plus reading short Bash scripts in Domain 5.
Other Networking certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
Test your grasp of deployment models, Dockerfiles, unit tests, OWASP threats and Bash with timed questions covering all twelve Domain 4 objectives.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the CCNA Automation AI tutor Get any concept explained your way