701-100
DevOps Tools Engineer
DevOps Tools Engineer Exam Guide
The LPI DevOps Tools Engineer exam validates practical knowledge across software engineering, application containers, Kubernetes, security, and observability. It is aimed at developers, system administrators, and other professionals who help move software from source code into reliable operation. This guide helps you decide whether the current 701-200 exam matches your background, which objectives deserve the most study time, and how to turn the blueprint into a hands-on preparation plan.
What does the DevOps Tools Engineer exam validate?
The certification validates the ability to use open source tools and collaborative methods across development and operations. LPI describes the target professional as someone who can create, deliver, and operate software while bridging software development and system administration. The exam therefore tests connected workflow knowledge rather than one isolated product or job title.
The current certification page identifies version 2.0 as exam code 701-200. Passing the DevOps Tools Engineer examination is the certification requirement, and LPI states that there are no prerequisites. LPI nevertheless strongly recommends an additional certification in a candidate’s primary specialty, such as LPIC-1 or a developer certification, at a level equivalent to LPIC-1.
The scope is deliberately practical. LPI identifies Docker, Podman, Kubernetes, Helm, Prometheus, and Git as key technologies for candidates. Version 2.0 also covers software design, continuous integration and delivery, software composition and licensing, cloud-native security, log management, and tracing. The useful question is not whether you have used every named tool at work; it is whether you can explain the role, configuration, and operational consequences of the technologies in the objectives.
Who is the exam designed for?
The strongest fit is a software developer or system administrator who already understands one side of the delivery lifecycle and needs to work effectively across the other. The exam also suits DevOps practitioners, platform-oriented engineers, release engineers, and Linux professionals building a broader open source toolset. Treat the certification as a skills bridge, not as a substitute for basic operating-system or programming knowledge.
Developers should pay particular attention to Linux-oriented operations, image construction, networking, storage, Kubernetes resources, and observability. Administrators should give extra time to application architecture, Git workflows, CI/CD concepts, software composition, licensing, and the way applications are designed for containers and cloud services.
There are no formal prerequisites, but a candidate without working knowledge of Linux, source control, application deployment, or basic networking may need foundation study before beginning the exam objectives. LPI’s recommendation to maintain a certification in system administration or software development is a useful signal about the expected baseline, even though it is not an admission requirement.
Which exam version should you prepare for?
Prepare from the version named on your voucher and appointment, then verify the objective page before committing to a study plan. LPI’s certification overview lists version 2.0, exam code 701-200, as the current version and identifies version 1.0 as the previous exam code 701-100. The two versions have materially different scopes, so mixing their objective lists is a costly preparation mistake.
Version 2.0 places greater emphasis on application containers and Kubernetes and organizes the blueprint into Software Engineering, Application Container, Kubernetes, and Security and Observability. The earlier version included different areas such as machine deployment, Ansible, and broader configuration management. A learner using older notes can therefore spend substantial time on topics that do not belong to the version they intend to take.
The LPI exam-objectives page is the safest reference for the current blueprint. The LPI Wiki page for version 2.0 is marked as a draft for version 2.0.0, while the certification overview and current objective page identify the released exam information. Use the current LPI certification page and objective page together, and do not infer current coverage from a legacy practice test.
How is the exam delivered?
LPI states that the exam contains 60 multiple-choice and fill-in-the-blank questions and has an examination duration of 90 minutes. The version 2.0 announcement identifies Pearson VUE Test Centers under exam code 701-200 and OnVUE online proctoring under exam code 701-200v. Confirm appointment rules, equipment requirements, and available locations directly with the scheduling provider before booking.
The certification overview lists English as an available version 2.0 exam language in VUE test centers and states that a Japanese translation is planned for 2026. Language availability can change by delivery channel and location, so check the current booking interface rather than relying on an old preparation page.
LPI lists a DevOps Tools Engineer 701 voucher at USD $200 in one displayed pricing tier, while its pricing page instructs candidates to select their country or territory. Treat USD $200 as the displayed tier only, not as a universal price. Check the country-specific LPI pricing page before budgeting or purchasing a voucher.
LPI states that the certification has a validity period of 5 years and provides options for extending beyond 5 years. This is a certification-policy detail, not a reason to rush preparation. Schedule when your objective coverage and practical readiness are strong, and recheck policy details if your appointment is far in the future.
How is the blueprint organized?
The objective weights show relative importance: higher-weight objectives are covered by more questions. Use the weights to allocate study effort, but do not treat a low-weight objective as optional. A short objective can still expose a terminology gap, while a high-weight objective usually requires both conceptual understanding and repeated command or configuration practice.
Software Engineering contains 701.1 Modern Software Development with weight 6, 701.2 Standard Components and Platforms for Software with weight 3, 701.3 Source Code Management with weight 6, 701.4 Continuous Integration and Continuous Delivery with weight 3, and 701.5 Software Composition, Licensing and Open Source with weight 2.
Application Container contains 702.1 Application Container Management with weight 5, 702.2 Container Orchestration with weight 3, and 702.3 Container Image Building with weight 5. Kubernetes contains 703.1 Kubernetes Architecture and Usage with weight 4, 703.2 Basic Kubernetes Operations with weight 7, and 703.3 Kubernetes Package Management with weight 2.
Security and Observability contains 704.1 Cloud Native Security with weight 4, 704.2 Prometheus Monitoring with weight 6, 704.3 Log Management and Analysis with weight 2, and 704.4 Tracing with weight 2. The weighting makes Basic Kubernetes Operations, Modern Software Development, Source Code Management, Prometheus Monitoring, and the container-management and image-building objectives especially important areas for deliberate practice.
Do not turn the weights into a rigid timetable. First identify your weakest domain, then combine it with the high-weight objectives. For example, a Kubernetes administrator may need less introductory cluster study but still need a structured review of software architecture and Git. A developer comfortable with Git may need a longer container, Kubernetes, and Prometheus lab sequence.
What should you know in Software Engineering?
Software Engineering tests whether you can reason about applications as deployable, collaborative, and maintainable services. Study the relationship between architecture, source control, delivery automation, and software supply choices instead of memorizing disconnected definitions. Your preparation should explain why a design works in a container or cloud environment and what operational trade-offs it creates.
Modern development and platform components
For 701.1 Modern Software Development, work through service-based application design, APIs, persistence, sessions, status, transactions, concurrency, security, performance, availability, scaling, load balancing, messaging, monitoring, and cloud-native properties. Practice classifying a requirement: does it belong in application state, a database, a queue, a platform service, or an observability system? That decision-making perspective is more useful than learning vocabulary in isolation.
For 701.2 Standard Components and Platforms for Software, review the purpose of object storage, relational and NoSQL databases, message brokers and queues, big-data services, application runtimes or PaaS, and content delivery networks. LPI’s objective list names examples including OpenStack Swift, OpenStack Trove, OpenStack Zaqar, CloudFoundry, and OpenShift. Learn the capability each category provides and the type of workload it supports.
Git and delivery pipelines
For 701.3 Source Code Management, use Git in a small repository. Create branches, make commits, inspect history, merge changes, resolve a conflict, and work with a remote repository. Be able to explain the difference between a working tree, staging area, local history, and shared remote history. Also connect source-control actions to review and release decisions.
For 701.4 Continuous Integration and Continuous Delivery, sketch a pipeline from commit through build, test, artifact or image creation, approval where appropriate, and deployment. Identify what should be automated, where a failure should stop progression, and how a repeatable artifact differs from rebuilding software separately in each environment. Do not study CI/CD as a list of server products; focus on controls and flow.
For 701.5 Software Composition, Licensing and Open Source, inventory the dependencies in a small project and record their licenses and versions. Review why dependency choice, license obligations, provenance, updates, and vulnerability handling belong in delivery workflows. A common mistake is treating “open source” as one license category; prepare to distinguish software availability from the specific obligations attached to a license.
How should you build container skills?
Use one small application to practise the entire container path: obtain an image, run it, connect it to another service, persist selected data, describe it with Compose, and build a new image. This sequence ties Docker and Podman concepts to application behavior and exposes mistakes that flashcard-only study often hides.
Application container management
The official 702.1 learning material covers Docker and Podman architecture, OCI-registry images, container operation, networking, storage, and rootless containers. Practise inspecting images and containers, starting and stopping services, viewing logs, entering a running container, publishing or connecting networks, and managing volumes. Then explain what changes when a container is rootless and why host permissions and storage behavior matter.
For networking, create two services that communicate through a user-defined network and test name-based discovery. For storage, separate disposable container state from data that must survive replacement. For image use, record the image source and tag rather than treating an image as an opaque download. The objective is operational understanding, so always inspect the resulting state after each command.
Compose, orchestration, and image building
For 702.2 Container Orchestration, review the purpose of scheduling, service replicas, health, networking, and rolling changes. Contrast running a group of related containers with managing a service across multiple hosts. Avoid assuming that a Compose file and a cluster orchestrator provide identical guarantees; understand the abstraction each tool offers.
For 702.3 Container Image Building, write a Dockerfile, build it, run the result, inspect its layers or metadata, and rebuild after changing application content. Practise choosing a base image, setting the working directory, copying only required files, declaring the intended process, and separating build concerns from runtime concerns. The objective specifically covers Docker version 17.06 or later, so keep your notes aligned with the published scope rather than undocumented features from a different release.
Compose practice should include a version 3 or later Docker Compose file, service definitions, networks, volumes, and commonly used properties. Update a running application to a newer image and verify what is preserved and what is replaced. The objective also names Podman Compose and the docker-compose.yml file, so know the application model and terminology across the listed tools without assuming every command is interchangeable.
What Kubernetes work is essential?
Kubernetes is the area where passive reading most quickly becomes inadequate. Build or use an existing practice cluster and repeatedly retrieve state, create resources, modify them, and remove them. The goal is to understand the relationship between desired configuration, controllers, workloads, services, and storage—not merely to remember isolated kubectl syntax.
Architecture and resource relationships
For 703.1 Kubernetes Architecture and Usage, map the control plane, worker-node responsibilities, API-driven management, and the resources used to describe workloads. Follow a request from a manifest to a running Pod, then identify how a controller maintains the desired number of replicas and how a Service provides stable access. Keep architecture notes tied to observable cluster state.
The objective list includes Pods, ReplicaSets, Deployments, Services, Ingress, PersistentVolumeClaims, ConfigMaps, and Secrets, as well as DaemonSets, StatefulSets, Jobs, and CronJobs. For each resource, write one sentence answering its purpose, lifecycle behavior, and typical use. This prevents a common mistake: treating all workload controllers as interchangeable deployment mechanisms.
Basic operations and Helm
For 703.2 Basic Kubernetes Operations, practise retrieving resources, describing them, reading logs, inspecting events, applying manifests, editing or replacing configuration, scaling a workload, and deleting resources. Deliberately break an image reference, configuration value, or service selector, then diagnose the resulting state. Troubleshooting from symptoms to resource relationships is stronger preparation than copying successful commands.
The objective also expects interaction with an existing Kubernetes platform to retrieve current state and create, modify, and delete resources. Practise both imperative commands and declarative manifests, but make the manifest the source of truth for repeatable work. After every change, verify the actual state and distinguish a scheduling problem, container-start problem, readiness problem, and networking problem.
For 703.3 Kubernetes Package Management, learn how Helm packages and installs software on Kubernetes. Review charts, values, releases, repositories, upgrades, and rollback reasoning. You do not need to treat Helm as a replacement for Kubernetes fundamentals: first understand the resources a chart creates, then use Helm to manage the packaged application and inspect its rendered or installed configuration.
How much security and observability practice is enough?
Security and observability should be studied as operating responsibilities, not final chapters to skim. For each application change, ask what identity, image, secret, network, metric, log, and trace information is exposed. Then practise collecting and interpreting evidence when the service is healthy and when it fails.
Cloud-native security
For 704.1 Cloud Native Security, organise notes around identities and permissions, image and dependency trust, secrets, network exposure, host boundaries, configuration, and secure delivery. Use least privilege in your lab, avoid placing sensitive values directly in an image, and examine which component is responsible for each control. The exam objective is best approached through threat-and-mitigation reasoning rather than product slogans.
A useful exercise is to review a containerized service and mark its trust boundaries: source repository, build process, registry, runtime, cluster API, service network, and external client. For each boundary, identify what could be altered or disclosed and which control reduces that risk. This also connects security with software composition and CI/CD.
Metrics, logs, and traces
For 704.2 Prometheus Monitoring, practise the difference between metrics, labels, targets, scraping, exporters, rules, and alerts. Build a small dashboard or query set around request rate, errors, latency, and resource behavior, then explain what each measurement can and cannot prove. LPI lists Prometheus Monitoring with weight 6, making it a priority for hands-on review.
For 704.3 Log Management and Analysis, compare application and system logging and review the roles of syslogd and systemd-journald. The objective names open source stacks and components including Elasticsearch or OpenSearch, Logstash, Filebeat, Fluentd, Fluent Bit, Kibana, Loki, Promtail, Grafana, and Graylog2. Learn the collection, transport, storage, search, and visualization responsibilities instead of memorizing product names without architecture.
For 704.4 Tracing, understand why a trace follows a request across services and how spans, context propagation, and sampling help locate latency or failure. Review the architecture and purpose of OpenTelemetry. A practical exercise is to compare a log line, a metric alert, and a trace: each provides different evidence, and none alone explains every distributed-system problem.
What study sequence works best?
Study in dependency order, then return to the blueprint by weight. Start with software and Git foundations, move through containers, use Kubernetes to deploy what you built, and finish with security and observability around the same application. This produces a connected lab while still reserving time for lower-weight objectives and terminology review.
Phase one: baseline and blueprint mapping
Begin by downloading or opening the current 701-200 objectives and marking every key knowledge area as new, familiar, or usable. “Familiar” means you can explain it; “usable” means you can perform or diagnose the relevant task. Establish a small Linux environment, a Git repository, a container runtime, and a Kubernetes practice option before intensive study begins.
Read the official LPI learning-materials index alongside the objectives. The materials provide lessons for all four topic areas, including 701 Software Engineering, 702 Application Container, 703 Kubernetes, and 704 Security and Observability. Use the objective list as the authority for scope and the lessons as a structured explanation-and-exercise path.
Phase two: create a connected lab
Build a simple service with a source repository, a container image, a Compose definition, and a Kubernetes deployment. Add configuration, persistent data where appropriate, a service endpoint, a basic metric, logs, and tracing concepts. The application can be small; the value comes from changing it repeatedly and observing how each tool represents the change.
Keep a command and decision journal. Record the command or manifest, the expected result, the actual result, and the reason for any correction. Add short explanations for terms that are easily confused, such as image versus container, Deployment versus Pod, volume versus ephemeral state, metric versus log, and readiness versus mere process existence.
Phase three: close gaps and test recall
After the first lab pass, return to each objective and answer its description without opening notes. Any answer that depends on vague recognition belongs on a gap list. Rebuild the relevant task from an empty directory, explain the output aloud or in writing, and then compare your explanation with the official objective and learning material.
Use practice questions only to test understanding, not to predict or reproduce live exam content. Review every wrong answer by objective label and failure type: vocabulary, architecture, command behavior, configuration interpretation, security reasoning, or time pressure. Memorizing answer patterns without repairing the underlying concept is a fragile strategy.
Phase four: final readiness and scheduling
Schedule only after you can move through the blueprint without abandoning an entire topic area. In the final review, prioritise high-weight objectives where your gap list remains longest, then perform a shorter pass over every lower-weight objective. Confirm the exam code, delivery channel, language, price, appointment requirements, and current LPI information immediately before purchase or scheduling.
Do not spend the final study period installing a large collection of unfamiliar tools. Freeze the lab, review your journal, practise reading unfamiliar snippets, and rehearse a question triage method: answer clear items, flag uncertain ones, eliminate unsupported choices, and return before time expires. This is a practical recommendation, not an official scoring rule.
What mistakes most often waste preparation time?
The most expensive mistakes are scope confusion, shallow tool familiarity, and study plans that ignore the blueprint’s connected workflow. Correct them early by anchoring every session to a version 2.0 objective, performing a small observable task, and recording the design reason behind the task. This approach keeps preparation practical without relying on exam dumps or leaked questions.
Using the wrong objective version
Old notes can emphasize Ansible, machine deployment, or a different container scope because those subjects belong to version 1.0 objectives. If your target is 701-200, map every resource to the current version 2.0 objective list before studying it. If you are intentionally taking 701-100, verify its availability and transition information with LPI rather than assuming the old exam remains available indefinitely.
Learning commands without state
A command memorized without understanding the resulting state breaks as soon as names, namespaces, images, or selectors change. After each operation, inspect what was created, what owns it, where traffic flows, and what persists after replacement. In Kubernetes especially, learn to connect events, descriptions, logs, labels, and controller behavior.
Treating tools as interchangeable
Docker and Podman share important container concepts, but do not assume every option, daemon model, networking behavior, or privilege model is identical. Likewise, Compose, Helm, and Kubernetes solve different layers of application packaging and operation. Compare tools by responsibility and abstraction, then verify the terminology in the official objectives and learning materials.
Ignoring small objectives
A weight 2 objective should receive less time than a weight 7 objective, but it should not receive zero time. Create a one-page summary for software licensing, Helm, log architecture, and tracing, then validate each summary with a short explanation or lab observation. This protects against avoidable gaps while keeping the schedule focused on relative importance.
Conclusion
The best preparation decision is to match your study method to the 701-200 blueprint: use official objectives for scope, LPI learning materials for structured coverage, and a connected lab for application, container, Kubernetes, and observability practice. Confirm the exam version and delivery details with LPI before scheduling. When you can explain the architecture behind your commands and diagnose changed or failing state, your preparation is measuring the skills this certification is intended to validate.