305-300 Practice Test 1 — 10 Questions

Question 1

Which component is responsible for the actual hardware-assisted virtualization in KVM?

Accepted Answer

KVM kernel module. The KVM kernel module (kvm.ko and hardware-specific modules like kvm_intel or kvm_amd) is responsible for hardware-assisted virtualization. It leverages CPU virtualization extensions (Intel VT-x or AMD-V) to execute guest code directly on the host CPU while trapping privileged instructions. This provides near-native performance for virtual machines.

Answer

Virt-manager GUI

Answer

Libvirtd daemon

Answer

QEMU user-mode binary

Question 2

You are managing an LXC container and need to create a snapshot of the container's root file system. Which command achieves this?

Accepted Answer

lxc-snapshot -n container_name. The `lxc-snapshot -n <container_name>` command creates a snapshot of an LXC container's root filesystem. It is the standard LXC utility for snapshotting containers, allowing you to capture the current state of the container's filesystem for backup or rollback purposes.

Answer

lxc-checkpoint -n container_name

Answer

lxc-copy -s container_name

Answer

lxc-backup

Answer

lxc-clone --snapshot

Question 3

In a Packer build process for OpenStack, which 'post-processor' type is typically used to upload the resulting image to the Glance image service?

Accepted Answer

openstack. Packer's `openstack` post-processor takes the artifact produced by the builder (typically a qcow2 or raw image) and uploads it to the OpenStack Glance image service, registering it as a bootable image. It handles authentication against Keystone and can set image metadata such as name, visibility, and tags. This makes it the standard way to publish a Packer-built image into an OpenStack cloud.

Answer

manifest

Answer

shell-local

Answer

compress

Question 4

Which of these is a valid virtualization storage pool type supported by libvirt?

Accepted Answer

dir. libvirt supports several storage pool types, including 'dir' (directory), 'disk', 'fs', 'logical', 'netfs', 'iscsi', 'scsi', 'mpath', 'rbd', 'sheepdog', and 'gluster'. The 'dir' type is a directory-based storage pool that uses a local directory to store volume files. Options like 'cpu', 'interface', and 'network' are not storage pool types; they are related to other libvirt objects such as CPU models, network interfaces, and virtual networks.

Answer

cpu

Answer

interface

Answer

network

Question 5

Which Docker network driver should you use if you want containers to have their own IP addresses on the physical network, as if they were physically connected to the network?

Accepted Answer

macvlan. The macvlan driver assigns each container a unique MAC address and IP address on the physical network, making containers appear as physical devices to the network. This is exactly the behavior described — containers get their own IPs on the physical network.

Answer

bridge

Answer

overlay

Answer

ipvlan

Question 6

In systemd-nspawn, how do you specify a different root directory for the container?

Accepted Answer

-D. The -D flag (long form --directory) in systemd-nspawn specifies the root directory for the container. This is the documented option for pointing nspawn at a directory tree that should be used as the container's filesystem root. For example, 'systemd-nspawn -D /var/lib/machines/mycontainer' boots the container using that path as its root.

Answer

--path

Answer

--root

Answer

-r

Question 7

You need to inspect the metadata of a specific Docker image without pulling it from a remote registry. Which command should you use?

Accepted Answer

docker manifest inspect. 'docker manifest inspect' queries the registry's manifest API directly and returns metadata such as platform variants, digests, and layer information without downloading the image layers. It is the correct tool for inspecting a remote image's metadata without pulling it.

Answer

docker pull --metadata

Answer

docker image history

Answer

docker image inspect

Question 8

In a Vagrantfile, which method is used to pass environment variables into the guest virtual machine during the provisioning phase?

Accepted Answer

config.vm.provision "shell", env: { "VAR" => "value" }. In a Vagrantfile, environment variables are passed to a shell provisioner using the `env` option on the provisioner block: `config.vm.provision "shell", env: { "VAR" => "value" }`. This injects the variables into the environment of the provisioning script running inside the guest. It is the documented, supported way to make host-side values available to guest provisioning.

Answer

config.env.set

Answer

config.vm.env

Answer

vagrant.env.set

Question 9

Which THREE of the following are necessary components for a successful KVM virtualization environment on Linux?

Accepted Answer

The kvm kernel module. Option A (the kvm kernel module) is correct because KVM is implemented as a Linux kernel module that exposes the /dev/kvm interface and provides the core virtualization capability, so without loading kvm (or kvm_intel/kvm_amd) no guest can execute. Option B (QEMU userspace tools) is correct because KVM only handles CPU and memory virtualization in the kernel; QEMU provides the userspace device emulation, BIOS/firmware, and the qemu-system-x86_64 process that actually creates and runs the VM. Option C (hardware support for Intel VT-x or AMD-V) is correct because KVM requires CPU virtualization extensions (vmx or svm) exposed in the CPU flags; without them KVM cannot run hardware-accelerated guests. Option D (a dedicated storage network switch) is not required, since KVM guests can use local disks, files, or any existing network via virtio, and a separate storage switch is only an optional design choice. Option E (a full Xen hypervisor installed) is not required and is in fact an alternative hypervisor; KVM does not depend on Xen, and installing Xen would be a different virtualization stack.

Answer

A dedicated storage network switch

Answer

A full Xen hypervisor installed

Question 10

How do you view the logs of a running container?

Accepted Answer

docker logs [container]. The correct command to view the logs of a running container is `docker logs [container]`. This command retrieves the standard output (stdout) and standard error (stderr) from the container's main process, which Docker captures and stores using a logging driver (default is json-file). It works for both running and stopped containers, and options like `-f` (follow) and `--tail` allow real-time monitoring or limiting output.

Answer

docker show-logs

Answer

cat /var/lib/docker/logs

Answer

docker log