How should I use these Scenario practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Scenario questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Scenario domain.

305-300 · topic practice

Scenario practice questions

Practise LPIC-3 Exam 305: Virtualization and Containerization (305-300) (305-300) Scenario practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

5 questionsDomain: Scenario

Practice 10 questions Browse domain →

What the exam tests

What to know about Scenario

Scenario questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Scenario exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Scenario questions

5 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full Scenario explanation →

You are using systemd-nspawn to run a container and need to allow it to use the host's network stack directly, without any network namespace isolation. Which option should you pass to systemd-nspawn?

Trap 1: `--private-network`

`--private-network` does the opposite: it creates a new, isolated network namespace for the container with only a loopback interface unless additional interfaces are configured. It is used when you want network isolation, not when you want to share the host's network stack. Using it would prevent the container from reaching the host's network directly.

Trap 2: `--network-namespace=host`

systemd-nspawn does not have a `--network-namespace=host` option. While similar concepts exist in other tools, this exact flag is not valid for systemd-nspawn. The correct way to share the host network namespace is to simply not create a new one, which is the default behavior unless a network-related option is specified.

Trap 3: `--network-interface=host0`

`--network-interface=host0` assigns a specific host interface to the container, but it still places the container in a separate network namespace. The container will have its own network stack and will not share the host's directly. This option is used for macvlan-like setups, not for sharing the host network namespace.

Study all Scenario common traps →

A
Do not specify any network-related option.
By default, systemd-nspawn does not create a separate network namespace, so the container shares the host's network stack. If you omit all network options such as `--private-network` or `--network-interface`, the container uses the host's interfaces and routing directly. This is the intended way to achieve host network sharing with systemd-nspawn.
B
`--private-network`
Why it fails: `--private-network` does the opposite: it creates a new, isolated network namespace for the container with only a loopback interface unless additional interfaces are configured. It is used when you want network isolation, not when you want to share the host's network stack. Using it would prevent the container from reaching the host's network directly.
C
`--network-namespace=host`
Why it fails: systemd-nspawn does not have a `--network-namespace=host` option. While similar concepts exist in other tools, this exact flag is not valid for systemd-nspawn. The correct way to share the host network namespace is to simply not create a new one, which is the default behavior unless a network-related option is specified.
D
`--network-interface=host0`
Why it fails: `--network-interface=host0` assigns a specific host interface to the container, but it still places the container in a separate network namespace. The container will have its own network stack and will not share the host's directly. This option is used for macvlan-like setups, not for sharing the host network namespace.

Full breakdown with real-world context →

Question 2mediummultiple choice

Read the full Scenario explanation →

You are using Docker and need to inspect the metadata of a running container, including its IP address, environment variables, and mounted volumes. Which command provides all this information in a single JSON output?

Trap 1: docker logs <container>

docker logs retrieves the stdout and stderr output from a container's main process. It does not provide any configuration or metadata about the container's network, environment, or mounts. It is used for troubleshooting application output, not for inspecting container settings. This command is unrelated to the scenario's need for metadata.

Trap 2: docker ps --format json

docker ps lists running containers and supports custom formatting, but it does not provide detailed metadata such as IP address or mounted volumes by default. While you can use --format to show selected fields, it does not output the full JSON configuration that docker inspect provides. It is intended for listing containers, not for deep inspection of a single container's configuration.

Trap 3: docker stats <container>

docker stats displays live resource usage statistics such as CPU, memory, and network I/O. It does not show configuration details like IP address, environment variables, or mounted volumes. It is useful for monitoring performance but not for retrieving static metadata. Therefore, it does not meet the requirement of inspecting container configuration.

Study all Scenario common traps →

A
docker logs <container>
Why it fails: docker logs retrieves the stdout and stderr output from a container's main process. It does not provide any configuration or metadata about the container's network, environment, or mounts. It is used for troubleshooting application output, not for inspecting container settings. This command is unrelated to the scenario's need for metadata.
B
docker inspect <container>
docker inspect returns detailed JSON metadata about a container, including its network settings (IP address), environment variables, mounts, and much more. It is the primary tool for retrieving low-level configuration and runtime information. The output can be filtered with --format to extract specific fields. This command satisfies all the requirements in the scenario with a single invocation.
C
docker ps --format json
Why it fails: docker ps lists running containers and supports custom formatting, but it does not provide detailed metadata such as IP address or mounted volumes by default. While you can use --format to show selected fields, it does not output the full JSON configuration that docker inspect provides. It is intended for listing containers, not for deep inspection of a single container's configuration.
D
docker stats <container>
Why it fails: docker stats displays live resource usage statistics such as CPU, memory, and network I/O. It does not show configuration details like IP address, environment variables, or mounted volumes. It is useful for monitoring performance but not for retrieving static metadata. Therefore, it does not meet the requirement of inspecting container configuration.

Full breakdown with real-world context →

Question 3mediummultiple choice

Read the full DHCP explanation →

You administer a KVM host running libvirt. A developer needs a guest to be able to communicate with the host directly over a private network without any NAT or bridging to the physical LAN. You decide to use libvirt's default virtual network. Which virsh command will display the XML definition of this default network so you can inspect its forwarding mode and DHCP range?

Trap 1: virsh net-dhcp-leases default

net-dhcp-leases lists current DHCP lease assignments for a given virtual network, showing IP and MAC mappings for active guests. It does not display the XML definition, forwarding mode, or address range configuration, so it cannot be used to inspect the network's structural settings as required.

Trap 2: virsh net-list --info default

While net-list --info does exist and shows runtime information such as autostart, persistent, and active state, it does not render the XML definition. It cannot show the forwarding mode or DHCP range, so it does not satisfy the stated requirement of inspecting the network's configuration details.

Trap 3: virsh iface-dumpxml default

The iface-dumpxml command targets host network interfaces managed by libvirt's interface driver, not virtual networks. The name 'default' is a libvirt network, not a host interface, so this command would fail or return unrelated data and would not expose the virtual network's forwarding configuration.

Study all Scenario common traps →

A
virsh net-dhcp-leases default
Why it fails: net-dhcp-leases lists current DHCP lease assignments for a given virtual network, showing IP and MAC mappings for active guests. It does not display the XML definition, forwarding mode, or address range configuration, so it cannot be used to inspect the network's structural settings as required.
B
virsh net-list --info default
Why it fails: While net-list --info does exist and shows runtime information such as autostart, persistent, and active state, it does not render the XML definition. It cannot show the forwarding mode or DHCP range, so it does not satisfy the stated requirement of inspecting the network's configuration details.
C
virsh net-dumpxml default
The net-dumpxml subcommand outputs the full XML definition of a libvirt virtual network. For the default network it reveals the forward mode='nat' element, the 192.168.122.0/24 address range, and the DHCP configuration. This is exactly the inspection needed to confirm how guests on the default network reach the host and external networks.
D
virsh iface-dumpxml default
Why it fails: The iface-dumpxml command targets host network interfaces managed by libvirt's interface driver, not virtual networks. The name 'default' is a libvirt network, not a host interface, so this command would fail or return unrelated data and would not expose the virtual network's forwarding configuration.

Full breakdown with real-world context →

Question 4mediummulti select

Read the full Scenario explanation →

Which TWO of the following are valid storage pool types in libvirt?

Trap 1: nfs-server

libvirt storage pool types are named after the backing source, such as netfs, iscsi, or logical; 'nfs-server' is not one, though an NFS share is configured as a netfs pool. It is tempting because NFS is a genuine supported backing store, so the name sounds like a real pool type.

Trap 2: virtual-disk

libvirt defines pool types by source mechanism — dir, fs, netfs, logical, disk, iscsi, scsi, gluster, rbd, sheepdog, vstorage — and 'virtual-disk' is not among them. It is tempting because pools do surface virtual disks to guests, and 'disk' is a real pool type, making the hyphenated variant sound legitimate.

Trap 3: remote-disk

Pool types describe the storage source, such as netfs, iscsi, rbd, or gluster; 'remote-disk' is not a libvirt pool type, so the pool definition would be rejected. It is tempting because many pools are indeed remote (iSCSI, NFS, Ceph), making the label sound like a plausible category name.

Study all Scenario common traps →

A
nfs-server
Why it fails: libvirt storage pool types are named after the backing source, such as netfs, iscsi, or logical; 'nfs-server' is not one, though an NFS share is configured as a netfs pool. It is tempting because NFS is a genuine supported backing store, so the name sounds like a real pool type.
B
virtual-disk
Why it fails: libvirt defines pool types by source mechanism — dir, fs, netfs, logical, disk, iscsi, scsi, gluster, rbd, sheepdog, vstorage — and 'virtual-disk' is not among them. It is tempting because pools do surface virtual disks to guests, and 'disk' is a real pool type, making the hyphenated variant sound legitimate.
C
logical
logical is a libvirt storage pool type backed by an LVM volume group, where volumes are created as logical volumes. It is a genuine pool driver alongside dir, fs, netfs, disk, iscsi, scsi and mpath.
D
remote-disk
Why it fails: Pool types describe the storage source, such as netfs, iscsi, rbd, or gluster; 'remote-disk' is not a libvirt pool type, so the pool definition would be rejected. It is tempting because many pools are indeed remote (iSCSI, NFS, Ceph), making the label sound like a plausible category name.
E
iscsi
An iSCSI pool is valid because libvirt's storage driver supports the iSCSI pool type, connecting to a remote target and presenting its LUNs as a pool. This satisfies the stem's requirement for a genuine libvirt pool type, unlike directory-based or filesystem-specific alternatives.

Full breakdown with real-world context →

Question 5mediummultiple choice

Read the full DNS explanation →

A system administrator is troubleshooting a container that cannot resolve DNS names for other containers on the same user-defined Docker bridge network. The container's /etc/resolv.conf points to 127.0.0.11. Which Docker feature is responsible for providing this DNS resolution?

Trap 1: The Docker daemon's --dns flag

The --dns flag allows specifying external DNS servers for containers, but it does not provide name resolution for other containers. It is used to override the default DNS settings. The presence of 127.0.0.11 in /etc/resolv.conf is specific to Docker's embedded DNS, not an external server configured via --dns.

Trap 2: A DNS server running in a separate container

While you can run a DNS server in a container, Docker's embedded DNS is built into the daemon and automatically provided. The address 127.0.0.11 is reserved for Docker's internal DNS, not for a user-run container. Therefore, a separate DNS container is not responsible for this resolution unless explicitly configured, which is not the default.

Trap 3: The host's systemd-resolved service

systemd-resolved is a host-level DNS resolver, but it is not used by containers by default. Containers have their own network namespace and do not automatically use the host's resolver. While the host may use systemd-resolved, the container's /etc/resolv.conf pointing to 127.0.0.11 indicates Docker's embedded DNS, not the host's service.

Study all Scenario common traps →

A
The Docker daemon's --dns flag
Why it fails: The --dns flag allows specifying external DNS servers for containers, but it does not provide name resolution for other containers. It is used to override the default DNS settings. The presence of 127.0.0.11 in /etc/resolv.conf is specific to Docker's embedded DNS, not an external server configured via --dns.
B
A DNS server running in a separate container
Why it fails: While you can run a DNS server in a container, Docker's embedded DNS is built into the daemon and automatically provided. The address 127.0.0.11 is reserved for Docker's internal DNS, not for a user-run container. Therefore, a separate DNS container is not responsible for this resolution unless explicitly configured, which is not the default.
C
Docker's embedded DNS server
Docker runs an embedded DNS server for user-defined networks, which listens on 127.0.0.11 and resolves container names and aliases. It allows containers on the same network to communicate using their names. This server is automatically configured in the container's /etc/resolv.conf. It is the correct mechanism for service discovery within a user-defined bridge network.
D
The host's systemd-resolved service
Why it fails: systemd-resolved is a host-level DNS resolver, but it is not used by containers by default. Containers have their own network namespace and do not automatically use the host's resolver. While the host may use systemd-resolved, the container's /etc/resolv.conf pointing to 127.0.0.11 indicates Docker's embedded DNS, not the host's service.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Scenario sessions

Start a Scenario only practice session

Every question in these sessions is drawn from the Scenario domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Scenario questions →Mixed 305-300 session

Frequently asked questions

What does the 305-300 exam test about Scenario?: Scenario questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Scenario questions in a focused session?: Yes — the session launcher on this page draws every question from the Scenario domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other 305-300 topics?: Use the topic links above to move to related areas, or go back to the 305-300 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the 305-300 exam covers. They are not copied from any real exam or dump site.

Scenario only

10 questions 20 questions 30 questions 50 questions

Mixed 305-300 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All 305-300 questions Scenario domain overview 305-300 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Scenario practice questions

What to know about Scenario

Common Scenario exam traps

Scenario questions

You are using systemd-nspawn to run a container and need to allow it to use the host's network stack directly, without any network namespace isolation. Which option should you pass to systemd-nspawn?

You are using Docker and need to inspect the metadata of a running container, including its IP address, environment variables, and mounted volumes. Which command provides all this information in a single JSON output?

Which TWO of the following are valid storage pool types in libvirt?

A system administrator is troubleshooting a container that cannot resolve DNS names for other containers on the same user-defined Docker bridge network. The container's /etc/resolv.conf points to 127.0.0.11. Which Docker feature is responsible for providing this DNS resolution?

Track your progress over time

Start a Scenario only practice session

Related 305-300 topic practice pages

Full Virtualization practice questions

Container Virtualization practice questions

VM Deployment And Provisioning practice questions

305-300 fundamentals practice questions

305-300 scenario practice questions

305-300 troubleshooting practice questions

Frequently asked questions

Track your progress

Study resources

Exam traps to avoid