Knowing how to start a container is a beginning. Delivering a change with tests, traceability, and a recovery path requires connecting several tools. LPI DevOps Tools Engineer can help structure that learning; this guide covers the correct exam, a study plan, and a lab that creates the files before running the commands.
Reviewed on 12 September 2026. The exercises and study sequence are LinuxPro suggestions, not actual exam questions or a guarantee of passing.
Check the version: study for 701-200
The current version is 2.0, exam 701-200. LPI states that version 1.0, exam 701-100, was available until 30 June 2026. Check the code in the course description and your booking: an older textbook may teach useful tools without covering the current syllabus.
It is an exam with 60 multiple-choice and fill-in-the-blank questions, lasting 90 minutes. The stated validity is 5 years. No previous certification is mandatory; LPI recommends an additional certification in administration, such as LPIC-1, or in development. You therefore do not need to complete LPIC-2 or LPIC-3 first.
At the time of review, the official page lists English for the current version at VUE test centers. Confirm the language, delivery format, and price for your country before paying; do not assume that the exam is available in Portuguese.
What the current syllabus covers
Use the official objectives as a checklist. This map is a summary, not a replacement for the individual objectives:
- 701 — Software engineering: architecture, services, Git, CI/CD, GitOps, licenses, and software composition.
- 702 — Containers: Docker and Podman, networks, volumes, Compose, and building and distributing OCI images.
- 703 — Kubernetes: architecture, resources, operations, Helm, and Kustomize awareness.
- 704 — Security and observability: application and infrastructure protection, Prometheus, logs, and tracing with OpenTelemetry.
Weights indicate relative importance, not a guaranteed exact question count. Basic Kubernetes operations have weight 7; Git and Prometheus monitoring each have weight 6. Ansible, Vagrant, and Packer are not listed as specific objectives in this version: do not organize your current preparation around the old machine deployment and configuration section.
A study plan in 6 stages
Progress by completed tasks, not videos watched. Repeat a stage when you can copy the solution but still cannot explain the outcome. Adjust the pace to your experience; this sequence does not set a universal deadline.
- 1. Fundamentals and Git: navigate the terminal, understand permissions and processes, create a repository, make a change on a branch, and resolve a conflict in a practice copy. Deliverable: readable history and an explanation of what changed.
- 2. Containers: build an image, run without the root user inside the container, and compare a file baked into an image with data in a volume. Deliverable: a service reachable only at the intended address and an explanation of persistence.
- 3. Delivery: turn local validation into a CI job. Intentionally break a test and observe the failure. Deliverable: distinguish testing, building, artifacts, and deployment instead of calling any script a complete pipeline.
- 4. Kubernetes: in a disposable cluster, deploy an application, inspect events, update its image, and observe the replicas. Then install a practice chart and change its values. Deliverable: explain what was declared and what the cluster ran.
- 5. Observability and security: introduce a controlled failure, locate the error, and choose a signal to detect it. Review permissions, secrets, and dependency origins. Deliverable: evidence-based troubleshooting without disabling protections to hide the problem.
- 6. Review: return to the objectives, mark gaps, and repeat tasks without consulting the recipe. Deliverable: a small lab repository with instructions, tests, limitations, and a recovery procedure.
Lab: from Git to a tested containerized service
Use a Linux study machine with Bash, Git, Python 3, an up-to-date curl, an up-to-date Docker Engine (28.0.0 or later), and the Docker Compose plugin installed. Your user must be able to run Docker. Work in a new directory, never inside a real project. The first build downloads an image from the internet.
This service serves only a static page for training. The Python HTTP server is not intended for production; do not use this example to host clients or expose personal files.
1. Create the page and a minimal test
The temporary directory is created under your home directory and the command prints its path. The Git identity below applies only to this practice repository.
LAB_DIR=$(mktemp -d "$HOME/lpi-devops-lab.XXXXXX")
cd "$LAB_DIR"
printf '%s\n' "$LAB_DIR"
git init -b main
git config user.name "LPI Lab"
git config user.email "lab@example.invalid"
mkdir site
printf '%s\n' '<!doctype html><html lang="en"><title>DevOps lab</title><h1>DevOps lab OK</h1></html>' > site/index.html
printf '%s\n' '__pycache__/' > .gitignore
cat > test_site.py <<'EOF'
from pathlib import Path
import unittest
class SiteTest(unittest.TestCase):
def test_homepage(self):
page = Path("site/index.html").read_text()
self.assertIn("<h1>DevOps lab OK</h1>", page)
if __name__ == "__main__":
unittest.main()
EOF
python3 -m unittest -v
The expected result is one passing test. It checks only the file content; it does not yet test networking, the container, or availability.
2. Define the image and its execution
cat > Dockerfile <<'EOF'
FROM python:3.13-slim
WORKDIR /app
COPY site/ /app/site/
RUN chmod 755 /app/site && chmod 644 /app/site/index.html
USER 10001:10001
EXPOSE 8080
CMD ["python", "-m", "http.server", "8080", "--bind", "0.0.0.0", "--directory", "/app/site"]
EOF
cat > .dockerignore <<'EOF'
*
!Dockerfile
!site/
!site/**
EOF
cat > compose.yaml <<'EOF'
services:
web:
build: .
image: lpi-devops-lab:local
ports:
- "127.0.0.1:18080:8080"
read_only: true
cap_drop:
- ALL
security_opt:
- no-new-privileges:true
EOF
docker compose config
git add .gitignore site/index.html test_site.py Dockerfile .dockerignore compose.yaml
git commit -m "Add tested container lab"
The image uses a non-root numeric identity. The application listens on the container interface, but host publication is restricted to loopback. EXPOSE documents the port; it does not publish the service by itself. If the local port is occupied, choose another in Compose and adjust the next check.
The base image tag is mutable: future rebuilds may download different content. For a project requiring exact reproduction, record and pin the verified image digest, with a separate process for security updates.
3. Build, validate, and inspect logs
docker compose up -d --build
docker compose ps
curl --fail --silent --show-error --max-time 5 --retry 10 --retry-all-errors --retry-delay 1 http://127.0.0.1:18080/ | grep -F 'DevOps lab OK'
docker compose exec -T web id
docker compose logs --tail=20 web
Check the expected page, the non-root process, and the request in the logs. A successful HTTP response is a basic check, not proof of security or comprehensive testing. If it fails, read the message and check the state, address, and port before rebuilding everything.
4. Add CI without pretending deployment already exists
If you use GitLab, save this file in the repository. It requires a runner with an executor that supports the declared image, such as Docker or Kubernetes, available to the project. The job runs only the page test: it does not build the image or deploy anything.
stages:
- test
test_site:
stage: test
image: python:3.13-slim
script:
- python -m unittest -v
File name: .gitlab-ci.yml. Commit it and push to your own GitLab repository with the runner configured. Do not put tokens in the file. To progress toward continuous delivery, you still need an artifact policy, protected credentials, a target environment, and post-deployment validation.
5. Practice failure, recovery, and cleanup
Change only the page message and run the test: it should fail. Undo the edit and confirm it passes again. Then make a change in a separate commit and practice reverting it with Git; avoid destructive commands that erase unsaved work. Rebuild the service and repeat the HTTP check.
When finished, run this in the lab directory:
docker compose down
This removes the project containers and network. The working directory, built image, and build cache remain available. Do not run a global Docker cleanup: it could affect other labs or services.
After the lab: Kubernetes, metrics, and tracing
The previous example does not cover the entire certification. For Kubernetes, use the official tutorial in a disposable environment: check the context before modifying resources, create a practice namespace, and practice Deployment, Service, scaling, and updates. Record what you observe, including events when something does not start.
With Helm, compare a chart’s default values with your own configuration. Before installing, read the resources and permissions it creates. The goal is to understand the change, not merely copy a command pointing to an unknown repository.
In Prometheus, follow the official exercise to monitor the server itself and query the up metric. Then stop a test target and observe what changes. A successful scrape does not guarantee that the user’s business operation succeeded; also choose a signal that represents that operation.
Do not treat metrics, logs, and traces as synonyms. Metrics help track measurements over time; logs record events; traces show the path of an operation across components. Use OpenTelemetry to study signals and context propagation without confusing instrumentation with the system that stores and queries the data.
Tips for better study and avoiding bad shortcuts
- Keep an error notebook: symptom, hypothesis, command used, evidence, and fix. Review the problems you actually encountered, not just a list of flags.
- Use active recall: close the documentation, explain the task aloud, and try to reproduce it. Then check the reference to correct syntax details.
- Practice reading technical terms in English. Make flashcards for concepts you confuse, such as image and container, authentication and authorization, delivery and deployment.
- Separate evidence: a passing test, a built image, and a responding service are different outcomes. Record versions and relevant output without storing keys or client data.
- Use legitimate practice tests as diagnostics, not predictions of the exam. Avoid dumps and promises of passing. Before booking, review the provider’s current instructions and required identification.
More LinuxPro reading
Strengthen the fundamentals and connect the lab to real problems. Ansible remains useful at work even though it is not central to this exam’s current syllabus. Historical articles help explain the context but do not replace current tool documentation.
- LPIC-1: Linux administration fundamentals
- Toca do Tux Linux course
- Git made simple: an introduction from the archives
- The history of Docker
- The history of Kubernetes
- Getting Started with Ansible
- OpenObserve: logs, metrics, and traces
The best study outcome is not a repository full of copied commands: it is being able to explain why the service works, detect failures, and recover safely. Use certification to structure that path without confusing the credential with production experience.