Unit 6 - Practice Quiz

Infrastructure as Code (IaC) is the practice of managing infrastructure (networks, virtual machines, etc.) in a descriptive model, using files similar to source code, rather than through manual configuration.

By defining infrastructure in code, you create a single source of truth that can be applied repeatedly, ensuring environments are consistent and removing the risk of mistakes from manual configuration.

Idempotency is a key principle of IaC. It ensures that applying a configuration will bring the system to the desired state, regardless of its starting state, and making no further changes if it's already in that state.

Terraform is a widely-used open-source IaC tool that allows users to define and provision infrastructure across various cloud providers and on-premises solutions.

The git clone command is used to create a local working copy of an existing remote repository.

git commit takes a snapshot of the staged changes and saves it to the project's history in the local repository. It does not send the changes to a remote server.

The git init command creates a new Git repository. It can be used to convert an existing, unversioned project to a Git repository or initialize a new, empty one.

The .gitignore file tells Git which files or directories to ignore in a project, which is useful for avoiding committing temporary files, build artifacts, or sensitive information.

A hypervisor, or virtual machine monitor (VMM), is software, firmware, or hardware that creates and runs virtual machines (VMs) by separating the computer's OS and applications from the underlying physical hardware.

The "Host OS" is the operating system of the physical machine, while the "Guest OS" is any operating system installed and running on top of the hypervisor within a virtual machine.

Type 1 hypervisors are called 'bare-metal' because they are installed directly on the physical hardware, without needing a host operating system to run on.

Virtualization uses software to allow a piece of physical hardware to host multiple virtual machines, each with its own operating system and resources, thereby improving efficiency and flexibility.

This is the fundamental difference. Because containers share the host kernel, they are more lightweight and have faster startup times compared to VMs, which need to boot a complete operating system.

Docker is the most popular and widely used platform for developing, shipping, and running applications inside containers. The other options are hypervisors for running virtual machines.

A container image is a lightweight, standalone, executable package that includes everything needed to run a piece of software, including the code, a runtime, libraries, environment variables, and config files. A container is a running instance of an image.

Linux containers are made possible by kernel features. Namespaces provide process isolation (making a container think it has its own private system), and cgroups (control groups) manage and limit resource usage (CPU, memory, etc.).

The docker pull command is used to fetch a container image from a remote registry (Docker Hub by default) and save it to your local machine.

The docker run command is a shortcut that first creates a writable container layer over the specified image, and then starts it.

The docker ps (process status) command lists all containers that are currently running on the host system.

A Dockerfile is a script containing a series of commands that Docker uses to automatically build a specific container image. It defines the base image, commands to run, files to copy, and other configuration details.

Idempotence is a core principle of declarative IaC tools. It means that an operation can be applied multiple times without changing the result beyond the initial application. This ensures that running the same script repeatedly will not cause errors or unwanted changes, but will simply enforce the desired state.

git rebase main takes the commits from the current branch (feature-xyz) and reapplies them on top of the latest commit from main. This results in a straight, linear history. In contrast, git merge would create a merge commit, which can make the history more complex to read.

A Type 1 hypervisor, also known as a bare-metal hypervisor, runs directly on the host's hardware to control the hardware and manage guest operating systems. Examples include VMware ESXi and Xen. This is in contrast to a Type 2 hypervisor, which runs as an application on top of a conventional host OS.

The fundamental difference is that containers virtualize the operating system, not the hardware. They share the host's kernel, which significantly reduces the memory and disk space footprint compared to a VM, which must bundle a complete guest operating system, including its own kernel.

The --rm flag tells the Docker daemon to automatically clean up the container and remove its filesystem when the container exits. This is useful for short-lived or temporary containers to prevent the accumulation of stopped containers on the host system.

The core distinction is the paradigm. An imperative approach (e.g., a shell script) specifies the exact commands to run in sequence to reach a state. A declarative approach (e.g., Terraform, Ansible) specifies the desired end state, and the tool is responsible for figuring out the necessary steps to achieve it.

git reset --hard HEAD~1 moves the branch pointer back by one commit (HEAD~1) and discards the changes from both the staging area and the working directory. This effectively erases the last commit. git revert would create a new commit that undoes the changes, leaving the original, sensitive commit in the history.

Linux namespaces are the core technology for container isolation. The mount namespace, in particular, allows each container to have its own set of filesystem mount points, completely separate from the host and other containers. cgroups are used for resource limiting (CPU, memory), not for filesystem isolation.

Docker volumes are the preferred mechanism for persisting data generated by and used by Docker containers. Volumes are managed by Docker and exist on the host filesystem, outside the container's lifecycle. This allows data to persist even when the container is removed and enables sharing data between containers.

In paravirtualization, the guest OS is modified to be 'aware' that it is being virtualized. This allows it to make direct calls (hypercalls) to the hypervisor, bypassing the performance overhead of emulating hardware devices, which is particularly beneficial for I/O-intensive operations.

The state file is crucial for IaC tools like Terraform. It stores the mapping between the resources defined in your code and the actual resources provisioned in your cloud environment. This allows the tool to plan what to create, update, or destroy by comparing the desired state (code) with the last known actual state (state file).

git rebase -i (interactive rebase) is the standard tool for modifying a series of recent, local commits. It allows you to reorder, squash, edit, or reword commits. You would start the interactive rebase from a commit before the one you want to change, and then mark the target commit with reword.

The -p or --publish flag in Docker uses the format <host_port>:<container_port>. To map port 8080 on the host to port 3000 in the container, the correct syntax is -p 8080:3000. The --expose flag only documents which ports the container listens on, but does not actually publish them.

Hardware Virtualization, which creates a Virtual Machine (VM), is the ideal solution. A VM allows you to install a complete, isolated guest operating system with its own specific kernel. Containers, a form of OS-level virtualization, are unsuitable because they share the host's kernel.

An image is the blueprint for a container. It's an immutable, standalone, executable package that contains everything needed to run a piece of software. A container is a runnable instance of an image. When a container is launched, a thin writable layer is added on top of the read-only image layers.

Squashing is the act of combining multiple commits into a single one. This is commonly done using an interactive rebase (git rebase -i) before merging a feature branch. The goal is to keep the history of the main branch clean and concise, where each commit represents a complete feature or fix.

The RUN instruction executes commands during the image build process (docker build) to create new layers in the image, such as installing software. The CMD instruction provides the default command and parameters for an executing container (docker run), which can be overridden by the user at runtime.

Imperative or procedural scripts, such as shell scripts, execute a sequence of commands. They typically lack built-in state management and error handling for partial failures. If a command fails, the script often halts, leaving the system in an unknown, intermediate state. Declarative tools are designed to converge on a target state and can often self-correct from partial failures on subsequent runs.

Because VMs run a full guest OS with its own kernel, the attack surface between a VM and the host (or other VMs) is much smaller and hardened by the hypervisor. In contrast, all containers on a host share the same host kernel. A kernel-level vulnerability could potentially allow a process in one container to escape and affect the host or other containers.

The --volume (or -v) flag is used to mount a host file or directory into a container. The correct syntax is -v <host_path>:<container_path>. This makes the host file appear at the specified path inside the container's filesystem, allowing for dynamic configuration without rebuilding the image.

Declarative IaC tools like Terraform use a state file to track resources. On execution, Terraform performs a 'refresh' operation, comparing its state file with the actual infrastructure. It will notice the web server exists as expected, see that the load balancer recorded in the state file is missing in reality, and that the database is missing from both. It will then create a plan to reconcile the differences: create the load balancer and the database, while taking no action on the server. This demonstrates the power of state management and drift detection.

git rebase works by replaying each commit from the current branch on top of the target branch. When it tries to apply the commit from the feature branch that relies on the now-missing code (due to the revert on main), the patch will not apply cleanly. This results in a merge conflict. The rebase process will halt, requiring the developer to manually fix the conflicting files, stage them, and then continue the rebase with git rebase --continue.

The key architectural difference is that a Type-2 hypervisor runs as an application on top of a conventional host OS. Every I/O operation from the guest VM must traverse the hypervisor process, then the host OS kernel's scheduling and I/O subsystems, before reaching the physical hardware. This extra layer introduces significant latency and jitter, which is detrimental to performance-sensitive workloads like databases. Type-1 hypervisors have more direct access to hardware, minimizing this overhead.

Docker named volumes are typically stored in a directory managed by Docker (e.g., /var/lib/docker/volumes), but the Docker engine itself does not perform encryption. To leverage host-level filesystem encryption, the most direct method is to use a bind mount that points to a specific directory that has been configured for encryption by the host OS (e.g., within an encrypted home directory). Option C adds complexity and overhead inside the container. Option D is not persistent. Option B is incorrect because Docker volumes are not inherently encrypted.

By default, without user namespace remapping, the UID inside the container is the same UID used for permission checks on the host. The directory has permissions 755. The '5' for 'others' means 'read' and 'execute' permissions. Since the container's UID 1000 does not match the owner (root, UID 0) or the group (root, GID 0), it is treated as 'other'. Therefore, the process can read existing files and list the directory contents (cd into it), but it lacks write permissions, so it cannot modify existing files or create new ones.

git filter-branch (or its more modern replacement, git-filter-repo) is designed specifically for rewriting entire repository history based on certain criteria. The --tree-filter option allows you to run a command on the checked-out files of every single commit, effectively removing the file from each one. This purges it from the history. rebase -i is tedious for many commits. revert only creates a new commit that undoes the change, it doesn't remove the file from history. reset --hard is destructive and requires manually re-applying subsequent work, which is error-prone. After rewriting history, a force push is required to update the remote branch.

Configuration drift occurs when manual changes (e.g., through a web console) are made to infrastructure that is managed by IaC, making the actual state different from what the code declares. A failed idempotent execution is an event where the IaC tool (e.g., Ansible, Terraform) starts running but terminates due to an error (like an API failure, syntax error, or permission issue). While a partially completed run can be a source of drift if not handled correctly, the core distinction is the cause: drift is caused by external, manual changes, whereas a failed execution is an internal failure of the automation tool's run.

When a guest OS is not 'virtualization-aware', the hypervisor must present it with virtual hardware that looks and acts exactly like real physical hardware (e.g., an Intel e1000 network card or an IDE disk controller). This is called full device emulation. The hypervisor must 'trap' every attempt by the guest OS to interact with this emulated hardware and translate it into an action on the host. This process of trapping and emulating is computationally expensive, leading to significant CPU overhead and lower I/O performance compared to paravirtualization, where the guest OS knows it's virtualized and can communicate more efficiently with the hypervisor.

A common and critical misconception is that depends_on checks for service readiness. It does not. It only ensures that the db container has been started before the api container is started. The PostgreSQL server inside the db container takes several seconds to initialize its database cluster on first run. The api container will likely start immediately and try to connect to a database that isn't ready, causing it to crash. The proper solution involves implementing a healthcheck in the db service and using the long-form depends_on syntax, or building retry logic into the api application itself.

This requires fine-grained network filtering. Seccomp (A) operates at the syscall level and is too coarse to filter by IP address and port. Network namespaces (B) provide isolation but not filtering. Cgroups (C) are primarily for resource limiting (bandwidth, CPU), not for firewalling. The most direct and powerful method is to use the host's iptables firewall. The administrator can create rules in the DOCKER-USER chain (or FORWARD chain) that specifically match traffic originating from the container's assigned IP address, allowing traffic to the DNS server (port 53) and 10.0.5.10:8080, while dropping all other outbound traffic.

A git submodule is not a copy of the files; it's a pointer. The main (super)project does not track the submodule's content. Instead, it tracks a specific commit SHA-1 from the submodule's repository. When the developer commits the submodule change in the main project, the only thing being recorded is that the main project should now point to this new commit hash from the submodule's history. This is why it's referred to as a 'gitlink' entry in the tree object.

Without EPT/RVI, the hypervisor uses a technique called shadow page tables. It maintains a separate set of page tables that map guest virtual addresses to host physical addresses and must keep them synchronized with the guest's own page tables. This synchronization process involves costly 'VM exits' (context switches from guest to hypervisor) on every page fault. EPT/RVI is a hardware feature that allows the processor's Memory Management Unit (MMU) to handle two levels of address translation (Guest Virtual -> Guest Physical -> Host Physical) directly in hardware. This drastically reduces the number of VM exits related to memory management, significantly improving performance by eliminating the overhead of shadow page table maintenance.

Terraform identifies resources by their address in the code (e.g., module.old_module.my_vm). When you move the code, the old address is no longer present, and a new address (module.new_module.my_vm) appears. Terraform's plan will interpret this as 'the old resource should be destroyed, and a new one should be created'. To prevent this destructive action and simply tell Terraform that the existing resource is now managed by the new code block, you must use the terraform state mv 'module.old_module.my_vm' 'module.new_module.my_vm' command to update the address in the state file before running apply.

The scratch image is a completely empty base image; it contains no libraries, no shell, no utilities, nothing. By default, Go compiles binaries that are dynamically linked against standard C libraries (libc). When you copy such a binary into scratch, it cannot run because its dependencies are missing. The OS loader tries to find them and fails, resulting in a 'not found' error. The solution is to compile the Go application as a static binary, which includes all dependencies within the executable itself. This is typically done with CGO_ENABLED=0 and ldflags like -s -w.

The no-new-privileges flag sets the PR_SET_NO_NEW_PRIVS attribute on the container's processes. This is a specific kernel security feature that ensures a process (and its children) cannot gain more privileges than its parent. It directly blocks the effects of setuid/setgid binaries, which is exactly what the policy requires. While dropping capabilities (D) is a good security practice, it doesn't prevent a setuid binary owned by root from running as root. A read-only filesystem (B) prevents modification but not execution of existing setuid binaries. User namespaces (C) are a powerful isolation tool but no-new-privileges is the most direct control for this specific requirement.

git bisect assumes that if a commit is 'good', all its ancestors are also 'good'. In this scenario, the commits between the introduction of the bug (commit 1) and the introduction of the test (commit 3) are untestable or will report 'good' because the test doesn't exist yet. When git bisect lands on one of these commits and the test passes (or can't run), it will incorrectly assume the bug was introduced later. The correct way to handle this is to have the test script return a special exit code (125) that tells git bisect to skip this commit and try a different one nearby, allowing the bisection to narrow down the correct range.

This is the fundamental architectural difference. Containers are isolated processes on a single host kernel, leveraging features like namespaces and cgroups. A read() syscall from a containerized process is handled directly by the host kernel. In a VM, the same process makes a read() syscall to its guest kernel. The guest kernel then executes privileged instructions to interact with what it thinks is hardware. The hypervisor traps these instructions and translates them into actions on the host, or the guest kernel uses efficient hypercalls to ask the hypervisor to perform the action. This extra layer of indirection (guest kernel + hypervisor) is why VMs have higher overhead but also stronger isolation.

Docker builds images in layers, and it caches each layer. A layer is invalidated if its command changes or if the files it depends on (e.g., via COPY) change. The most effective strategy is to copy and install the dependencies (which change rarely) before copying the application source code (which changes frequently). In the correct option, the RUN npm ci layer only depends on package*.json. As long as those files don't change, this time-consuming layer will be cached. Subsequent builds where only .js files change will only invalidate the COPY . . layer and rebuild from there, which is much faster than re-running npm ci every time, as would happen in the other examples.

In a declarative tool, you define the desired end state. The tool's engine is responsible for figuring out the current state and calculating the minimal set of actions to get there. In an imperative script, you define the actions. To make an update idempotent, your script can't just blindly run aws ec2 modify-instance-attribute.... It must first run aws ec2 describe-instance-attribute..., parse the result, compare it to the desired value, and only if they differ, run the modify command. This explicit checking logic must be written for every single property of every resource, which is incredibly complex, error-prone, and difficult to maintain.

When git bisect identifies a merge commit as the culprit, it means the parent commits of that merge were 'good', but the state after the merge is 'bad'. This points to an integration issue. The code on the feature branch worked fine on its own, and the code on the main branch worked fine on its own, but when they were combined, an unforeseen negative interaction occurred. This is a classic example of an integration bug, and it highlights the importance of --no-ff merges, as they create a single point in history that represents the act of integration, making such bugs easier to pinpoint with tools like bisect.