305-300 Practice Test 10 — 10 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

docker inspect <container>. The docker inspect command outputs comprehensive JSON metadata for a container, including network settings, environment variables, and mounts. Other commands like docker ps, docker stats, and docker logs serve different purposes such as listing, monitoring, or retrieving logs. Only docker inspect provides the full configuration details required in this scenario.

Answer

docker logs <container>

Answer

docker ps --format json

Answer

docker stats <container>

Question 2

You are using QEMU/KVM with libvirt on a host and want to gracefully shut down a running domain named 'db01' so the guest OS performs its normal shutdown sequence. Which virsh command should you use?

Accepted Answer

virsh shutdown db01. A graceful shutdown is initiated with virsh shutdown, which delivers an ACPI power-button event or uses the QEMU guest agent to request an orderly OS shutdown. This allows the guest to flush caches and stop services cleanly. Hard power-off, suspension, and configuration removal do not perform a graceful guest shutdown, so they do not meet the requirement.

Answer

virsh suspend db01

Answer

virsh destroy db01

Answer

virsh undefine db01

Question 3

You are configuring a rootless Podman container that must persist data across container restarts and also needs to communicate with other containers on the same host using a user-defined network. Which two actions must you perform to achieve these goals? (Choose two.)

Accepted Answer

Create a user-defined network with podman network create and attach the container to it.. To persist data across restarts in rootless Podman, a named volume created with podman volume create and mounted into the container is the correct approach. For containers to communicate by name on the same host, a user-defined network created with podman network create and attached to the container is required. The other options either introduce unnecessary privileges or do not address both requirements.

Answer

Use a bind mount to a host directory and set the --userns=host flag to avoid permission issues.

Answer

Add the --ipc=host flag to allow containers to share memory and communicate.

Answer

Run the container with the --privileged flag to allow volume mounting and network access.

Question 4

You are using systemd-nspawn to run a container and want to ensure that the container's processes are isolated from the host's process tree. Which option should you use?

Accepted Answer

Process isolation is enabled by default with PID namespaces; no additional option is needed.. systemd-nspawn automatically sets up a PID namespace for each container, ensuring that processes inside the container are isolated from the host's process tree. This means container processes cannot see or interact with host processes, and vice versa. No additional option is needed to achieve this basic level of process isolation. Other options like --private-users add user namespace isolation, but process isolation is a default behavior. Therefore, the correct answer is that no extra option is required.

Answer

--private-users

Answer

--boot

Answer

--private-network

Question 5

You are configuring an LXC container and need to limit its CPU and memory usage. Which TWO of the following configuration options in the container's config file are valid for this purpose? (Choose two.)

Accepted Answer

lxc.cgroup2.cpu.max = 50000 100000. LXC uses cgroup v2 settings to enforce resource limits. The options lxc.cgroup2.cpu.max and lxc.cgroup2.memory.max are valid and directly limit CPU bandwidth and memory usage, respectively. The other options either use non-existent configuration keys or, in the case of cpuset.cpus, control CPU affinity rather than usage limits. Thus, only the cgroup2-based limits achieve the goal.

Answer

lxc.cgroup2.cpuset.cpus = 0-1

Answer

lxc.memory.limit = 1G

Answer

lxc.cpu.limit = 2

Question 6

A guest was created with a 20 GB qcow2 disk and has been running for months. The administrator wants to give the guest additional space without recreating the disk, and the guest uses a single ext4 partition with no LVM. Which approach is valid with virsh and standard tools?

Accepted Answer

Run 'virsh vol-resize --pool default --vol disk.qcow2 30G' to enlarge the backing file, then grow the partition and filesystem inside the guest.. Enlarging a libvirt-managed qcow2 volume is done with virsh vol-resize, after which the extra space appears as a larger block device the guest can partition and grow. Device renaming, attaching an unrelated disk, or running resize2fs against the qcow2 file on the host do not extend the existing disk and filesystem in the required way.

Answer

Edit the domain XML to change the disk's '<target dev>' from vda to vdb and restart the guest.

Answer

Use 'virsh attach-disk' to add a second qcow2 image and merge the two disks with mdadm inside the guest.

Answer

Run 'qemu-img resize disk.qcow2 +10G' and then immediately run 'resize2fs' on the host against the qcow2 file.

Question 7

A Docker host runs a container with the default bridge network. The container needs to resolve external DNS names, but `docker exec mycontainer ping example.com` fails with 'unknown host'. The host itself resolves names correctly. Which Docker daemon configuration should you check first?

Accepted Answer

The `--dns` flag or `dns` setting in `/etc/docker/daemon.json`. Containers using the default bridge network inherit DNS resolver settings from the Docker daemon. When the host resolves names but the container does not, the daemon's DNS configuration is the prime suspect. Inspecting `/etc/docker/daemon.json` for a `dns` key or the daemon's `--dns` flag reveals whether an unreachable or incorrect resolver was injected into the container.

Answer

The `--iptables` flag in the Docker daemon configuration

Answer

The `--userland-proxy` setting in the Docker daemon

Answer

The `--bridge` flag specifying a custom bridge interface

Question 8

An administrator is configuring a KVM host that will run a latency-sensitive guest. The goal is to reduce scheduling jitter and improve cache locality for that guest's vCPUs. Which TWO measures are appropriate? (Choose two.)

Accepted Answer

Isolate host CPUs from the general scheduler using the kernel's isolcpus or cpuset controls and assign the guest to them.. Reducing jitter and improving cache locality for a latency-sensitive guest is achieved by dedicating host CPUs to it and preventing the scheduler from moving or preempting its vCPU threads. Pinning vCPU threads to specific physical CPUs and isolating those CPUs from the general scheduler via isolcpus or cpusets together provide that isolation. Disk cache settings, memory ballooning, and adding vCPUs do not address CPU scheduling jitter.

Answer

Increase the number of vCPUs assigned to the guest so the scheduler has more threads to choose from.

Answer

Set the guest's disk cache mode to 'none' in the domain XML.

Answer

Enable the virtio-balloon driver and set a memory balloon target for the guest.

Question 9

A KVM host uses a bridged network 'br0' with the physical NIC enslaved. You want a guest to obtain an IP address from the same DHCP server as the host's physical LAN, without NAT. Which libvirt network interface definition in the domain XML achieves this?

Accepted Answer

. To place a guest directly on the physical LAN through an existing host bridge, the domain XML must use an interface of type bridge whose source bridge is br0. This connects the guest's virtio NIC to the bridge enslaved to the physical NIC, so the guest shares the LAN segment and can use the same DHCP server without NAT. NAT networks, macvtap direct interfaces, and raw ethernet TAPs do not provide this exact behavior.

Answer

Answer

Answer

Question 10

You are troubleshooting a Docker container that fails to start with the error message: 'Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting /proc: no such file or directory'. The host is running a recent Linux kernel and Docker is using the default runtime. What is the most likely cause?

Accepted Answer

The container's root filesystem is missing the /proc directory.. The error occurs because runc tries to mount a new proc filesystem at /proc inside the container, but the target directory does not exist in the container's root filesystem. Minimal images built from scratch often lack standard directories like /proc, /sys, and /dev. Creating these directories in the Dockerfile resolves the issue. The other options do not match the specific error message about a missing file or directory during mount.

Answer

The Docker daemon is not running with the correct seccomp profile.

Answer

The host's /proc filesystem is not mounted or is inaccessible.

Answer

The container image is corrupted and needs to be pulled again.