200-901 Application Deployment and Security Practice Question
A development team is building a container image for a Node.js API. The Dockerfile currently uses the instruction `COPY . /app` before `RUN npm install`. A security review flags that the image contains local `.env` files and `.git` history. Which approach best prevents these files from entering the build context while keeping the Dockerfile functional?
⚠ Common exam trap
The trap here is assuming that removing files with a later `RUN rm` instruction removes them from the final image, when immutable layers preserve the original data.
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
✓
Add a `.dockerignore` file listing `.env` and `.git`, then rebuild the image.
The build context is everything sent to the Docker daemon, and `COPY . /app` transfers all of it. A `.dockerignore` file filters that context before the build starts, so excluded files never reach any layer. Deleting files later, changing ownership, or relocating them outside the project root does not prevent inclusion and leaves recoverable data in earlier layers.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a `.dockerignore` file listing `.env` and `.git`, then rebuild the image.
Why this is correct
A `.dockerignore` file excludes matching paths from the build context sent to the Docker daemon, so `COPY . /app` will not include `.env` or `.git`. This is the standard, declarative way to keep secrets and repository metadata out of an image without altering application logic. It also speeds up builds by reducing context size, and it works regardless of the base image or runtime.
- ✗
Move the `.env` and `.git` directories outside the project root and reference them with an absolute path in the Dockerfile.
Why it's wrong here
Docker cannot access files outside the build context, so absolute paths outside the project root are unavailable during build. Moving `.git` also breaks normal version control workflows. This does not solve the problem of excluding files from the context and would likely cause the build to fail or require insecure context expansion.
- ✗
Add `RUN rm -rf /app/.env /app/.git` immediately after the `COPY` instruction.
Why it's wrong here
Deleting files in a later layer does not remove them from the earlier layer. Docker layers are immutable and the original `COPY` layer still contains `.env` and `.git`; anyone with the image can extract those layers. This approach also fails if the files are needed by the build but should not persist, and it bloats the image with the deleted data.
- ✗
Change the instruction to `COPY --chown=node:node . /app` so only Node.js-owned files are copied.
Why it's wrong here
The `--chown` flag only sets ownership of copied files; it does not filter which files are copied. `.env` and `.git` would still be included, just owned by the `node` user. This option addresses permissions, not content exclusion, so the security finding would remain unresolved after a rebuild.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-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 Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco 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 200-901 exam.