GSEC Virtualization, Cloud, and AI Essentials Practice Question
A software company runs its CI/CD build agents as containers on a Docker Engine host that is shared by several development teams. A security engineer observes that a build job launched by one team was able to read environment variables belonging to a concurrently running build from a different team, and that the job also reached the host's filesystem through a mounted path. Which configuration change most directly prevents both of these cross-tenant exposures on the same host?
⚠ Common exam trap
The trap here is assuming that any single Docker hardening flag, such as a read-only root filesystem or user namespace remapping, provides full multi-tenant isolation when the real gap is the shared kernel and shared daemon.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Run each team's build agents in separate virtual machines on the same physical host rather than as containers on one Docker Engine instance.
The two symptoms — reading another build's environment variables and reaching the host filesystem through a mount — both stem from workloads sharing a single kernel and Docker Engine instance. Container isolation is namespace- and cgroup-based, so a misconfigured or privileged container can see peer processes and host paths. Placing each team's agents in its own virtual machine restores a separate kernel and process table per tenant, which is the change that directly removes both exposures at once.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Run each team's build agents in separate virtual machines on the same physical host rather than as containers on one Docker Engine instance.
Why this is correct
Separate virtual machines on the same host give each team its own kernel and its own isolated process table, so one build cannot inspect another build's environment variables and cannot traverse into another tenant's mounted paths. Because the containers shared one Docker Engine instance, the kernel-mediated isolation was insufficient; moving to per-team VMs restores a hardware-enforced boundary that directly prevents both observed exposures.
- ✗
Configure the Docker daemon to use a different storage driver for each team so image layers are not shared between build jobs.
Why it's wrong here
Changing the storage driver affects how image layers are stored and deduplicated on disk; it does not create a process or namespace boundary between running containers. Environment variables live in each process's memory and host mounts are kernel bind mounts, neither of which is governed by the storage driver, so the cross-tenant reading would continue.
- ✗
Add the --read-only flag when starting each build container so the container filesystem cannot be modified at runtime.
Why it's wrong here
A read-only root filesystem prevents writes inside the container's own image layers but does not stop a process from reading another container's environment variables or from reading a host path that was already bind-mounted into the container. The exposure observed was cross-tenant reading, not modification, so this flag leaves both problems intact.
- ✗
Enable user namespace remapping (userns-remap) on the Docker daemon so container root maps to an unprivileged host UID.
Why it's wrong here
User namespace remapping limits the damage a container's root user can do on the host by shifting UIDs, which addresses part of the filesystem exposure but does nothing to separate environment variables between processes on the same kernel. The build job would still be able to read another container's environment through shared process inspection, so this change alone does not close both exposures described.
About these practice questions
This GSEC question is part of Courseiva's 351-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GSEC practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GSEC exam.