305-300 Exam Guide: LPIC-3 Virtualization and Containerization
Exam 305-300 validates enterprise-level Linux administration across full virtualization, container virtualization, and virtual-machine deployment and provisioning. It is intended for experienced Linux professionals who need to plan, configure, maintain, and troubleshoot virtualization or container environments rather than merely recognize product names. This guide helps you decide whether your LPIC-2 status and hands-on background are sufficient, which objective areas deserve the most study time, and how to build a focused lab and revision plan before scheduling the exam.
What 305-300 is designed to validate
305-300 is the LPIC-3 Virtualization and Containerization exam, version 3.0. It covers enterprise-wide administration of Linux systems with an emphasis on virtualization and containerization. LPI states that the exam resulted from the split of version 2.0 of exam 304, so candidates using older 304-200 materials should map them against the 305-300 objectives before relying on them.
The LPIC-3 standard is aimed at an enterprise-level Linux professional. The LPI Wiki describes the minimally qualified candidate as someone able to understand, plan roll-outs, install, configure, maintain, and troubleshoot the technologies being tested. That profile is more demanding than familiarity with a desktop hypervisor or having launched a few containers from a tutorial.
The certification is specialty-based. LPI lists four separate LPIC-3 specialty certifications and states that passing any one of the four exams grants the LPIC-3 certification for that specialty. For the Virtualization and Containerization specialty, the stated prerequisite is an active LPIC-2 certification, together with passing exam 305.
Check eligibility and scheduling facts first
Before buying a voucher or booking a sitting, confirm that your LPIC-2 certification is active and check the official LPI page for the current scheduling and pricing information in your country. LPI states that an active LPIC-2 certification is required to receive the LPIC-3 Virtualization and Containerization certification; passing the exam alone does not replace that prerequisite.
The official overview identifies the exam as version 3.0 with exam code 305-300. It describes a 90-minute exam containing 60 multiple-choice and fill-in-the-blank questions. Because delivery arrangements, regional pricing, and appointment availability can change, use the official page rather than an unaffiliated listing when making the final booking decision.
LPI lists English and Japanese as available languages at VUE test centers and through OnVUE online delivery. Confirm the language and delivery option shown during the scheduling process, particularly if you need accommodations or have a preference between a test center and online delivery.
LPI states a validity period of five years for the exam and certification and provides options for extending active status beyond that period. Treat renewal or extension as a separate planning task: record the certification status after passing and consult LPI’s current renewal information when the relevant period approaches.
Read the blueprint as a study priority map
The objective weights indicate relative importance, and LPI says objectives with higher weights will be covered with more questions. Use the weights to allocate study time, but do not skip low-weight objectives: a small objective can still expose a knowledge gap, especially when it involves a command, configuration file, or troubleshooting decision you have never practiced.
The Full Virtualization topic includes virtualization concepts and theory with weight 6, Xen with weight 3, QEMU with weight 4, libvirt virtual machine management with weight 9, and virtual machine disk image management with weight 3. Libvirt therefore deserves the largest single block of full-virtualization practice, while the surrounding areas provide the architecture and operational context needed to use it correctly.
The Container Virtualization topic includes container virtualization concepts with weight 7, LXC with weight 6, Docker with weight 9, and container orchestration platforms with weight 3. Docker has the largest single weight in this topic, but the concepts objective should come first because it gives you a framework for distinguishing isolation, images, networking, storage, and lifecycle operations across technologies.
The VM Deployment and Provisioning topic includes cloud management tools with weight 2, Packer with weight 2, cloud-init with weight 3, and Vagrant with weight 3. This topic has smaller individual weights than libvirt or Docker, but it covers a distinct workflow: producing an image, customizing an instance, and managing repeatable development or deployment environments.
A workable order for the blueprint
Start with the concepts objectives, then study one operational stack at a time. A practical sequence is virtualization concepts, QEMU and Xen foundations, libvirt management, disk images, container concepts, LXC, Docker, orchestration, and finally provisioning tools. This order reduces the risk of memorizing commands without understanding which layer owns a resource or failure.
Build a lab that mirrors the objective verbs
The objective wording repeatedly uses action verbs such as install, configure, maintain, migrate, manage, and troubleshoot. Your lab should therefore require you to create and alter systems, inspect their state, introduce controlled faults, and recover from them. Reading command summaries is useful for orientation, but it cannot replace tracing a failed network, storage, or guest configuration.
Keep a written lab record for each exercise. Note the host assumptions, commands used, configuration files changed, expected state, observed state, and recovery method. This produces revision material that is more useful than copied command lists because it connects a tool to a symptom and a decision.
Separate destructive experiments from anything important. Use disposable virtual machines or containers, keep configuration examples in version control, and label commands that affect storage, networking, or running workloads. The purpose is to learn operational reasoning without confusing a practice reset with a production procedure.
Full-virtualization lab exercises
Create a small host-and-guest environment and work through the distinction between the hypervisor, virtual machine monitor, guest, virtual hardware, and emulation. Investigate CPU flags through /proc/cpuinfo and record what changes when hardware virtualization support is exposed or unavailable. Practice explaining the operational consequences of hardware-assisted virtualization, paravirtualization, and emulation in your own words.
For Xen, identify Domain0 and guest domains, inspect the relevant configuration locations, and use the xl toolset to create, list, monitor, and stop domains. The official objectives focus on Xen 4.x and name xl, xl.cfg, xl.conf, xentop, XenStore, XAPI, and boot parameters. Do not study these as isolated vocabulary: connect each item to configuration, lifecycle management, or troubleshooting.
For QEMU, start an instance from the command line, inspect the relationship between QEMU, KVM, /dev/kvm, and the relevant kernel modules, and test guest networking and storage. Practice using the QEMU monitor for snapshot management and install or investigate the QEMU Guest Agent and VirtIO drivers. Record symptoms that distinguish a missing accelerator, a network bridge problem, and an inaccessible disk image.
For libvirt, make this the most systematic lab area. Use libvirt tools to define and manage domains, inspect host and guest state, work with virtual networks and storage pools, and examine XML definitions. Practice changing resources, connecting to the correct libvirt URI, and distinguishing a domain-definition problem from a host-resource problem. The goal is to reason about libvirt domains rather than memorize one preferred command sequence.
For disk images, create or inspect images in more than one format, compare sparse and fully allocated storage, and test backing files, copy-on-write behavior, snapshots, resizing, and conversion. The official objectives also include virtual machine disk and volume management. Before each change, document whether the operation changes the virtual disk metadata, the guest filesystem, or both; confusing those layers is a common source of damage.
Container lab exercises
Begin by comparing a container with a fully virtualized machine. Map process isolation, namespaces, control groups, filesystem layers, networking, and resource limits to observable behavior. Then write a short decision note for when a workload needs a separate kernel boundary and when a process-level container is appropriate. This conceptual distinction helps prevent product-specific memorization.
For LXC and LXD, create containers from existing images, configure networking and storage, apply container properties and resource limits, and use profiles. Inspect images and practice the relevant lxc subcommands. The objectives cover LXC version 3.0 or higher and include awareness of traditional LXC tools, so learn both the LXD-managed workflow and the terminology used to describe the underlying technology.
For Docker, practice node and container administration rather than stopping at image execution. Work with images, containers, volumes, networks, logs, resource controls, and lifecycle operations. Deliberately create failures such as a wrong port mapping, a missing volume, an unsuitable command, or an unavailable network, then diagnose them from state and logs. Keep the host, image, container, and application layers distinct in your notes.
For orchestration, learn the purpose and boundaries of orchestration rather than attempting to master every platform in equal depth. The objectives include Docker Compose and Docker Swarm, Kubernetes and Helm, plus awareness of OpenShift, Rancher, and Mesosphere DC/OS. Be able to explain what problem scheduling, desired state, service discovery, scaling, and release packaging address, and identify which tool belongs to which layer.
Provisioning and repeatability exercises
Treat Topic 353 as a connected pipeline. Cloud management tools provide the environment context; Packer creates reusable system images; cloud-init configures machines created from standardized images; and Vagrant helps manage reproducible development environments. Drawing this pipeline and then implementing a small version of it will reveal gaps that separate tool-by-tool reading can hide.
For cloud management tools, distinguish IaaS, PaaS, and SaaS and learn the basic features of OpenStack and Terraform. The objectives also require awareness of CloudStack, Eucalyptus, and OpenNebula. Focus on the role each name represents and on the distinction between a cloud platform and an infrastructure-as-code tool; do not spend disproportionate time trying to reproduce every provider in a local lab.
For Packer, create and maintain a template, choose an appropriate builder, and build an image. The objective specifically covers Packer functionality, template files, and different builders. Your notes should show which settings control the source, provisioning steps, output artifact, and repeatability. A useful check is whether another person could identify the resulting image and rebuild it from the template.
For cloud-init, start a virtual machine from a standardized image and use cloud-init to configure it. Inspect the rendered configuration and logs, then test user creation, package or service configuration, networking, and first-boot behavior where supported by your environment. The important distinction is between the image’s baseline and instance-specific initialization; mixing those responsibilities makes later image reuse difficult.
For Vagrant, create a small environment, define its machines and resources, and practice bringing it up, inspecting it, connecting to it, and destroying it. Examine how the Vagrantfile expresses the environment and how providers affect the underlying virtualization implementation. The objective weight is 3, so aim for confident workflow understanding instead of an exhaustive survey of every provider or plugin.
Turn objectives into evidence of competence
A useful readiness test is not “Have I seen this term?” but “Can I explain the choice, perform the basic operation, and diagnose a likely failure?” For each objective, create three notes: a concept explanation, a short procedure, and a troubleshooting branch. This format exposes shallow familiarity while keeping revision tied to the skills LPI describes.
For a concept note, define the term and contrast it with the nearest confusing term. For a procedure note, list prerequisites, state-changing commands or files, verification steps, and rollback considerations. For a troubleshooting note, begin with a symptom and list the evidence you would inspect before changing configuration.
Use the official objective lists as your coverage checklist. Record the specific files, terms, and utilities named there, but do not interpret the partial lists as a promise that only those items matter. The descriptions and key knowledge areas define the skill being assessed; the utility list helps you locate the practical surface area.
A strong review question often combines two layers. Examples include: which component owns the virtual network; whether a guest agent or VirtIO driver changes the diagnosis; whether a container image or a running container is being modified; whether a cloud-init change belongs in the image or instance metadata; and whether a libvirt resource is defined persistently or only active now.
A staged study roadmap
Use a staged plan that moves from scope discovery to hands-on implementation and then timed retrieval. Do not schedule solely because you have completed a video course or read a set of notes. Schedule when you can explain the blueprint, complete representative lab tasks without step-by-step prompts, and review mistakes by objective rather than by vague topic labels.
Stage one: establish the baseline
Read the version 3.0 objectives end to end and create a four-part inventory: full virtualization, container virtualization, VM deployment and provisioning, and prerequisite knowledge. Mark each item as strong, familiar, or unknown. Verify LPIC-2 status and investigate the official delivery options before choosing a target window.
Use your inventory to identify transfer gaps. A Linux administrator who knows Docker may still need Xen, QEMU, libvirt, and disk-image management. Someone experienced with virtual machines may need container networking, Docker administration, orchestration concepts, and image-based provisioning. Start with the least familiar high-weight area rather than automatically beginning with the technology you use most often.
Stage two: learn the architecture before the commands
Study virtualization concepts and container concepts first. Build comparison tables for hypervisors, virtual machine monitors, emulation, paravirtualization, namespaces, control groups, images, containers, guests, hosts, and orchestration objects. Then validate each entry in the lab. If you cannot connect a definition to an observable system state, keep it in the active study queue.
Move through Xen, QEMU, and libvirt as related but distinct layers. For each, identify its architecture, configuration surface, networking and storage model, lifecycle tools, and common failure evidence. This prevents a frequent mistake: attributing a guest networking failure to the wrong layer because several tools appear in the same deployment.
Stage three: perform operational scenarios
Work through complete scenarios instead of unrelated commands. For example, create a guest, attach storage, connect networking, change its resources, take or inspect a snapshot, and troubleshoot a deliberately broken component. Repeat the pattern for a container and then for an image-based provisioning workflow.
After each scenario, rebuild it from a blank environment using only your own short checklist. Remove instructions one at a time. Any step you cannot reconstruct should become a targeted review item, but avoid turning the checklist into an unexamined collection of commands. Explain why each step is required and how you would verify it.
Stage four: retrieve and diagnose
Use objective-by-objective questions that require a choice or explanation, not only recognition. Ask yourself what changes between a persistent definition and a running instance, what evidence identifies a storage problem, what a cloud-init configuration is intended to control, and which orchestration feature addresses a stated operational need.
Review incorrect answers immediately. Label the cause as terminology confusion, command recall, architecture misunderstanding, or troubleshooting weakness. Then perform a small lab task or rewrite the explanation that addresses that cause. Repeating the same question without repairing the underlying misconception produces false confidence.
Stage five: make the scheduling decision
Schedule when your objective inventory contains no untested high-weight area, your lab notes include verification and recovery steps, and you can work through mixed-topic review without relying on memorized answer patterns. If one domain remains theoretical, postpone the appointment and create a focused experiment rather than hoping unrelated experience will cover it.
Check the official LPI page again for the language, delivery method, appointment process, and regional pricing that apply to you. Preserve the objective version associated with your preparation. If a course, book, or practice resource uses 304-200 or another version, verify every topic against 305-300 before treating it as current.
Common preparation mistakes to avoid
The most expensive preparation mistakes are usually scope mistakes: studying an older exam, over-practicing one familiar tool, or confusing recognition with administration ability. Correct them by anchoring every study session to the official 305-300 objectives and by requiring a lab or explanation that demonstrates the stated skill.
Relying on older 304 material without checking the split can leave the plan misaligned. LPI identifies 305-300 as the version 3.0 exam and 304-200 as the previous version. Use older notes only after comparing their coverage, terminology, and objective boundaries with the current official list.
Treating Docker as the whole container topic is another weak strategy. Docker has weight 9, but the Container Virtualization topic also covers concepts with weight 7, LXC with weight 6, and orchestration platforms with weight 3. Study Docker deeply while still learning the distinctions and operational purpose of the other areas.
The same problem appears in full virtualization when candidates skip libvirt because they have used a graphical virtualization product. Libvirt virtual machine management has weight 9 and includes host, domain, network, storage, and related management knowledge. Practice the management layer directly rather than assuming that experience with a different interface transfers completely.
Memorizing commands without state verification creates fragile knowledge. After every operation, identify what changed and how you know it changed. Check the relevant domain, container, image, network, volume, log, or configuration state. If an operation fails, preserve the error and diagnose it before resetting the lab.
Studying only product names misses the exam’s enterprise orientation. The LPI Wiki describes an LPIC-3 professional as someone able to plan roll-outs, install, configure, maintain, and troubleshoot tested technologies. Build scenarios involving repeatability, resource limits, migration considerations, storage, networking, and recovery—not just first-run installation.
Using unauthorized dumps or leaked-question material is not a sound preparation method. Such material does not demonstrate competence, may be inaccurate or outdated, and cannot substitute for the objective knowledge. Prepare with the official objectives and legitimate technical references, and use practice questions only as a way to locate gaps rather than as a script of expected answers.
How to use practice questions responsibly
Practice questions are useful when they test reasoning across the blueprint and lead you back to documentation or a lab. They are harmful when they encourage answer memorization detached from configuration state. For every missed item, write the governing concept, the command or file you would inspect, and a small experiment that confirms the answer.
Mix formats because the exam includes multiple-choice and fill-in-the-blank questions. For multiple-choice review, eliminate options that belong to a different layer or lifecycle stage and explain why the remaining choice fits. For fill-in-the-blank review, practice exact terminology, utility names, configuration concepts, and concise distinctions without assuming that a remembered phrase will cover an unfamiliar scenario.
Do not infer an official passing score from practice performance. The supplied LPI information describes the question types, duration, objectives, and weights, but it does not provide a passing score in the research available for this guide. Use practice results to judge readiness by objective coverage and repeatable performance, not by an invented threshold.
Manage the exam session deliberately
The official format is a 90-minute exam with 60 multiple-choice and fill-in-the-blank questions. Enter the session with a pacing method that leaves time to revisit uncertain items, but avoid spending so long proving one answer that you neglect the rest. The exact appointment and delivery instructions come from the provider and should be checked when you schedule.
Read each question for its operational context before focusing on a command or product name. Identify whether it describes a host, guest, domain, container, image, network, volume, or provisioning stage. Then eliminate answers that act on the wrong object or assume a feature belonging to another technology.
For fill-in-the-blank items, check spelling, command names, option syntax, and whether the requested response is a term or an action. Do not add unsupported alternatives merely because they are technically related. For multiple-choice items, compare the complete behavior described by each option rather than selecting the most familiar word.
If a question exposes a weak area, mark it according to the test interface’s available procedure and continue when possible. Your preparation should have separated genuine uncertainty from simple recall delay. After the session, follow LPI’s official result and certification instructions rather than relying on informal claims about processing or status.
Final review checklist for 305-300
In the final review, confirm coverage and retrieval rather than starting a new broad course. You should be able to describe the purpose and trade-offs of virtualization and containers, operate the named management layers, connect failures to evidence, and explain how image creation, initialization, and environment management fit together.
Use this checklist as a last gap scan:
Full virtualization: virtualization terminology, hypervisor variations, migration concepts, Xen 4.x architecture and management, QEMU with KVM, libvirt domains and resources, networking, storage, snapshots, and disk-image operations.
Container virtualization: isolation concepts, LXC and LXD images and profiles, container networking and storage, resource limits, Docker node and container management, and the roles of Compose, Swarm, Kubernetes, Helm, OpenShift, Rancher, and Mesosphere DC/OS.
Deployment and provisioning: IaaS, PaaS, SaaS, OpenStack, Terraform, awareness of CloudStack, Eucalyptus, and OpenNebula, Packer templates and builders, cloud-init configuration of standardized images, and Vagrant environment management.
Readiness evidence: an active LPIC-2 certification, a completed objective inventory, hands-on tasks for unfamiliar areas, troubleshooting notes, mixed-topic practice, and a final check of official language and delivery information.
What to do next
Open the official 305-300 objectives and annotate every objective with one source of explanation, one lab task, and one verification method. Then verify your LPIC-2 status and inspect LPI’s current scheduling information. Those two actions establish both technical scope and eligibility before you commit money or a date.
Next, build the smallest safe lab that lets you work with a hypervisor or virtual machine manager, libvirt, containers, and image provisioning. Prioritize the highest-weight areas—libvirt virtual machine management with weight 9 and Docker with weight 9—while reserving explicit sessions for every remaining objective.
Finally, replace passive review with scenario reconstruction. Start from a clean state, create the required resource, inspect it, change it, break one dependency, and recover it. Keep the resulting notes as your revision set. When you can do that across the blueprint and explain the decisions involved, make the scheduling decision using the official LPI information rather than relying on third-party exam listings.
Conclusion
305-300 rewards structured administration knowledge across virtual machines, containers, and repeatable provisioning. The most reliable preparation path is to verify the version and prerequisite, use official objective weights to set priorities, and turn each objective into a lab task with observable results and a troubleshooting explanation. Use the LPI overview and objective pages for final delivery and eligibility checks, then schedule only when your practical evidence covers both the major domains and the smaller deployment objectives.
