305-300 VM Deployment And Provisioning Practice Test 3 — 15 Questions

Question 1

Which tool is commonly used alongside Packer to validate the configuration file for syntax errors before attempting a build?

Accepted Answer

packer validate. `packer validate` is the built-in Packer subcommand that parses a template (HCL2 or JSON) and verifies its syntax, required fields, and referenced variables/builders before any build is attempted. It catches schema errors, missing required attributes, and invalid references without provisioning any infrastructure. This makes it the standard pre-build sanity check in CI pipelines alongside `packer fmt`.

Answer

packer fmt

Answer

packer lint

Answer

packer check

Question 2

What is the default behavior of Vagrant when a box is not found locally on the host machine?

Accepted Answer

It downloads it from the Vagrant Cloud. When Vagrant is asked to bring up a machine and the specified box is not present locally, it automatically attempts to download the box from the configured box repository, which by default is Vagrant Cloud (formerly Atlas). This behavior is controlled by the box_url or the shorthand box name in the Vagrantfile, and Vagrant will fetch the box metadata and then the box file itself. No user prompt is required unless the box is not found in the repository or there is an ambiguity.

Answer

It prompts for a path

Answer

It creates an empty machine

Answer

It fails immediately

Question 3

Which cloud-init module is responsible for setting the hostname of the instance during the initial boot process?

Accepted Answer

hostname. The cloud-init 'hostname' module is responsible for setting the instance's hostname and, optionally, the fully qualified domain name (FQDN) during initial boot. It reads the 'hostname' and 'fqdn' keys from the cloud-config or metadata service and applies them via the appropriate system tool. This module runs early in the cloud-init boot stages to ensure the instance is correctly identified before other services start.

Answer

system_name

Answer

network_config

Answer

set_hostname

Question 4

When using Packer with the QEMU builder, what does the 'format' option in the 'qemu' builder define?

Accepted Answer

The output image format. In the Packer QEMU builder, the 'format' option defines the output image format — for example 'qcow2', 'raw', 'vmdk', or 'vdi'. It tells QEMU how to write the resulting disk image so it is compatible with the target hypervisor or platform. This is distinct from filesystem or guest OS settings, which are configured elsewhere.

Answer

The filesystem type

Answer

The hypervisor type

Answer

The guest OS type

Question 5

In a Vagrant environment, where should sensitive data like API keys be stored to avoid committing them to version control?

Accepted Answer

A .env file excluded from git. Sensitive data such as API keys should be stored in a .env file that is excluded from version control (e.g., via .gitignore), so secrets are not committed to the repository. This keeps credentials out of source history while still allowing the application to load them at runtime.

Answer

A box metadata file

Answer

The Vagrantfile

Answer

The provisioner script

Question 6

Which command is used to display the configuration of a Packer build in a readable format?

Accepted Answer

packer inspect. `packer inspect` is the dedicated Packer CLI subcommand that parses a template (HCL2 or legacy JSON) and prints its declared components — builders, provisioners, post-processors, and variables — in a human-readable summary without executing a build. It is the canonical way to review what a template will do before running `packer build`.

Answer

packer view

Answer

packer show

Answer

packer list

Question 7

When using Vagrant with multiple machines in a single Vagrantfile, how do you define individual configurations?

Accepted Answer

config.vm.define :name. In a multi-machine Vagrantfile, each VM is declared with 'config.vm.define :name do |machine| ... end', which creates a named machine block where per-VM settings (box, network, provider, provisioners) are scoped. This is the canonical Vagrant DSL for multi-machine environments and allows 'vagrant up web' or 'vagrant ssh db' to target individual machines.

Answer

config.vm.box_set

Answer

config.vm.instance

Answer

config.vm.multi

Question 8

Which THREE of the following are common cloud-init modules?

Accepted Answer

packages. Option B (packages) is a standard cloud-init module that installs or upgrades packages on first boot by reading the packages and package_upgrade keys, so it is correct. Option C (runcmd) is a core cloud-init module that executes arbitrary shell commands listed under the runcmd key during the final boot stage, making it correct. Option E (users-groups) is the cloud-init module responsible for creating and configuring users and groups from the users and groups directives, so it is also correct. Options A (network-bridge) and D (disk-partition) are not cloud-init modules; networking is handled by modules such as network-config or the distro's network renderer, and partitioning is handled by modules like disk_setup and growpart, so neither belongs here.

Answer

network-bridge

Answer

disk-partition

Question 9

Which TWO components are defined in a Packer 'build' block?

Accepted Answer

sources. In a Packer HCL2 template, the build block is where you declare the sources (option C) that Packer will use to create the image, referencing source blocks defined elsewhere in the template, and the provisioners (option E) that run during the build to customize the machine before the image is captured. Both sources and provisioners are valid arguments inside a build block, e.g. build { sources = ["source.amazon-ebs.example"] provisioners = [ ... ] }. Option A (builders) is not correct because in HCL2 templates the builder is defined inside a source block, not directly as a build block argument. Option B (plugins) is not a build block argument; plugins are installed via packer init and referenced through their source types. Option D (variables) is not defined inside the build block; variables are declared in variable blocks and referenced with var.<name>.

Answer

builders

Answer

plugins

Answer

variables

Question 10

Which THREE configuration items can be managed via cloud-init 'write_files' module?

Accepted Answer

Target path (path). The cloud-init write_files module is designed to create arbitrary files on an instance during boot, and each file entry is defined by three key attributes: the destination path (option A, 'path'), the file's permissions (option C, 'permissions'), and the file's content (option E, 'content'). The 'path' specifies where the file is written on the filesystem, the 'permissions' sets the octal mode (e.g., '0644') applied to the file, and 'content' supplies the actual data written to that file. Options B and D are incorrect because service status is managed by cloud-init's 'runcmd' or systemd/service modules, and kernel parameters are handled by the 'sysctl' module or bootloader configuration, not by write_files.

Answer

Service status

Answer

Kernel parameters

Question 11

Which THREE settings are commonly configured in the 'provider' block of a Vagrantfile for virtualbox?

Accepted Answer

gui. In a Vagrantfile, the provider block for VirtualBox accepts the settings gui, cpus, and memory, which are all valid VirtualBox provider options. Option A (gui) is correct because it controls whether the VirtualBox VM launches with a graphical user interface, a common provider-specific setting. Option C (cpus) is correct because it sets the number of virtual CPUs allocated to the VM through the VirtualBox provider. Option E (memory) is correct because it specifies the amount of RAM in megabytes assigned to the VM by the VirtualBox provider. Option B (disk_size) is not a standard VirtualBox provider setting in Vagrant; disk resizing typically requires the vagrant-disksize plugin or manual VBoxManage commands. Option D (network_type) is not a valid Vagrant provider setting; networking is configured via config.vm.network with types like private_network or public_network.

Answer

disk_size

Answer

network_type

Question 12

Which TWO pieces of information does Packer require to build an image for an existing cloud environment?

Accepted Answer

API credentials. Packer needs API credentials (Option A) so its cloud builder can authenticate to the target cloud provider's API and create, register, and manage the resulting image on your behalf. Packer also needs the region (Option D) to know which geographic endpoint and datacenter location the image should be built in and stored, since cloud resources are region-scoped. A local disk path (Option B) is not required because Packer builds cloud images from a source image or template in the cloud, not from a local file path. A BIOS password (Option C) is irrelevant since Packer does not modify firmware settings during image builds. The host OS version (Option E) is not required because Packer runs on the build host but the target image's OS comes from the configured source image, not the host's OS version.

Answer

Local disk path

Answer

BIOS password

Answer

Host OS version

Question 13

Which THREE directives are valid under the cloud-init 'users' configuration section?

Accepted Answer

name. In the cloud-init 'users' configuration section, the 'name' directive (A) is valid and required, as it defines the login name of the user account to be created. The 'ssh_authorized_keys' directive (B) is also valid, allowing a list of public SSH keys to be injected into the user's ~/.ssh/authorized_keys file for passwordless authentication. The 'groups' directive (E) is valid as well, specifying a list of supplementary groups to which the user should be added. The 'expiration_date' option (C) is not a recognized cloud-init user directive; account expiration is handled via the 'expire' directive (or 'expiredate' in some schemas), not 'expiration_date'. The 'security_level' option (D) is not part of the cloud-init users schema at all and has no meaning in this context.

Answer

expiration_date

Answer

security_level

Question 14

Which TWO methods can be used to pass configuration data to cloud-init during instance creation?

Accepted Answer

user-data. Option B (user-data) is correct because cloud-init's primary mechanism for receiving instance-specific configuration at launch is the user-data blob, which can contain cloud-config YAML, shell scripts, or cloud-boothook directives that cloud-init parses on first boot. Option E (metadata) is correct because cloud-init also consumes instance metadata (for example, EC2 IMDS or OpenStack metadata service) to obtain configuration such as hostname, SSH keys, and network settings during initialization. Option A (kernel-args) is not a standard cloud-init configuration channel, since kernel command-line parameters are used for boot-time kernel behavior rather than passing structured config data to cloud-init. Option C (bios-injection) is not a supported cloud-init datasource method, as BIOS settings are firmware-level and not used to deliver cloud-init configuration. Option D (sys-config) is not a recognized cloud-init mechanism; no such datasource or configuration-passing method exists in cloud-init's documented interfaces.

Answer

kernel-args

Answer

bios-injection

Answer

sys-config

Question 15

You are building a Vagrant environment for a development team. The Vagrantfile must provision three identical web servers and one load balancer, all using the same base box but with different hostnames and static IP addresses. Which Vagrantfile construct should you use to define these machines and their individual settings?

Accepted Answer

config.vm.define. The config.vm.define method is used to declare multiple machines within a single Vagrantfile. Each definition block can set machine-specific attributes like hostname, network, and provider settings. This allows a single Vagrantfile to manage a multi-machine environment, which is exactly what is needed for three web servers and one load balancer.

Answer

config.vm.provider

Answer

config.vm.network

Answer

config.vm.provision