LPIC-3 Virtualization and Containerization v3.0 Free Sample Questions

The virsh numatune command is specifically designed to display and modify NUMA parameters for a running virtual machine. This command provides details on memory node binding and vCPU to physical CPU pinning, which is essential for diagnosing and resolving NUMA-related performance issues. vcpuinfo shows vCPU state but not pinning, nodeinfo shows host NUMA details but not the VM's configuration, and memtune controls overall memory limits, not NUMA placement.

Multi-stage builds allow you to use one stage with a full SDK to build the application (e.g., golang:1.19) and a subsequent stage to copy only the compiled binary into a minimal base image (e.g., scratch or alpine). This ensures that build-time dependencies, compilers, and source code are not present in the final image, dramatically reducing its size and attack surface. It does not automatically handle image signing or affect the build cache in the described manner.

The correct command is qemu-img convert -f vmdk -O qcow2 -c -o preallocation=metadata source.vmdk target.qcow2. The -f flag specifies the source format, -O specifies the output format. The -c flag is the shorthand for enabling qcow2 compression. The -o flag is used for format-specific options, and preallocation=metadata tells qemu-img to create a non-sparse image where only the metadata is preallocated, which can improve performance by avoiding metadata fragmentation.

LXD clustering relies on communication over TCP port 8443 for its API and internal raft consensus protocol. While ICMP (ping) may be allowed, a common security practice is to block most incoming ports by default. A network timeout during the join process, despite successful ping tests, strongly indicates that a firewall is blocking the specific port LXD requires for cluster communication. Storage pool names being different or NTP issues would typically result in different error messages after the initial connection is established.

False. By default, the vagrant-libvirt provider will attempt to connect the VM to libvirt's 'default' virtual network, which is typically a NAT-based network. This allows the VM to access the external network and provides a DHCP-assigned IP address. While defining a private network (config.vm.network "private_network") is a common practice for stable host-to-guest communication, it is not strictly required for the VM to get network connectivity upon creation.

The correct way to apply a custom seccomp profile to a Docker container is by using the --security-opt flag. The syntax is seccomp= . This instructs the container runtime to load the specified profile and restrict the container's allowed system calls to only those defined in the file. The other options use incorrect flags (--seccomp-profile, --apparmor) or incorrect syntax for the security option.

The xl save command is used to stop a domain and save its current state, including its entire memory content, to a file on disk. The domain is terminated on the hypervisor after the save is complete. This state can then be restored later using xl restore. xl snapshot is for disk snapshots, xl suspend pauses the domain but keeps its state in the host's memory, and xl migrate moves a running domain to another host.

A NAT-forwarded network is the standard libvirt configuration that meets these requirements. It creates a virtual bridge, runs a DHCP server to assign IPs to VMs on a private subnet, and uses iptables rules on the host to perform Network Address Translation (NAT) for outbound traffic. This isolates the VMs while providing them with internet access. A bridged network would place them on the same L2 network as the host, an isolated network would prevent internet access, and a routed network requires additional static routes on the external network.

The most effective way to handle builder-specific provisioning is to use a single provisioner block with different environment_vars for each builder, controlled by only or except clauses. However, since the variables are different, a cleaner approach is to use two distinct provisioner blocks. One block would have only = ["amazon-ebs"] and set AWS_REGION, while the other would have only = ["qemu"] and set BUILD_TYPE. This provides clear separation and ensures the correct environment variables are passed to the script depending on which builder is active.

Docker Compose is the ideal tool for this scenario, as it allows defining a multi-container application in a single YAML file (Req 1). By default, Compose creates a custom bridge network for the application, allowing all services to communicate via their service names (e.g., rabbitmq) without exposing ports (Req 2). The ports mapping for the frontend service satisfies Req 3. Defining a named volume at the top level and mounting it into the RabbitMQ service provides persistent storage (Req 4). Kubernetes is a more complex solution than required, and the manual script approach lacks the declarative and portable nature of Compose.