EX200 Manage containers Practice Question
An administrator is building a container image with a Containerfile. They want to ensure that a specific RUN command always executes without using the build cache. Which build option should they use?
⚠ Common exam trap
Red Hat often tests the distinction between cache-related flags and cleanup-related flags, so candidates may confuse `--no-cache` with `--force-rm` or mistakenly think `--squash` disables caching.
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
✓
--no-cache
The `--no-cache` build option instructs Podman or Docker to rebuild every layer from scratch, ignoring any cached intermediate layers. This ensures that the specific RUN command always executes fresh, which is essential when the command's outcome depends on dynamic external data or must not reuse stale cached results.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
--layers=false
Why it's wrong here
The `--layers=false` argument is not a recognized `podman build` option; the utility rejects it as invalid before any build or caching logic runs. Consequently, it cannot selectively disable cached layers. To bypass the layer cache in Podman, the correct flag is `--no-cache`, which is an entirely separate command-line switch rather than a boolean assignment on a `--layers` toggle.
- ✗
--squash
Why it's wrong here
`--squash` is valid but it only flattens all generated layers into a single layer after the build completes; it does not inspect or purge the builder's layer cache. Cached layers from earlier instructions will still be reused during the build, so in the short term you gain a smaller image while losing the ability to see layer history. To prevent cached layers from being consulted, you need `--no-cache`, not a compression or flattening operation.
- ✗
--force-rm
Why it's wrong here
`--force-rm` controls intermediate container cleanup, not the build cache: it guarantees that any temporary containers created during the build are removed on success and failure. The layer cache remains fully active, so unchanged instructions resolve to already-built layers and never rerun. This option addresses disk hygiene and stale container leftovers, but it is irrelevant when the goal is a cache-disabled build.
- ✓
--no-cache
Why this is correct
`--no-cache` is the correct answer because it tells Podman to ignore every cached layer and execute each instruction from the `Containerfile` as if this were the first build. It forces all dependent stages, such as `RUN` steps, to re-run and pull any changed content from network repositories, giving a pristine result. This is useful for reproducible builds where you need to verify that a fresh base image and package set produce the image.
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX200 question from scratch — 427 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX200 practice question is part of Courseiva's free Red Hat 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 EX200 exam.