Practice the vocabulary of scanning a container image for a known vulnerability before deployment.
0 / 5 completed
1 / 5
At standup, a dev mentions automatically scanning a built container image's layers for a known vulnerability in an installed package before that image is allowed to be deployed. What is this practice called?
Container image scanning automatically checks a built image's layers for a known vulnerability in an installed package before that image is allowed to be deployed. Deploying an image directly with no scan risks shipping a known, already-published vulnerability straight into production. This automated scanning is a standard, low-friction gate in a container-based deployment pipeline, catching a vulnerable dependency before it ever reaches a running environment.
2 / 5
During a design review, the team wants a scan to block an image from being pushed to the deployment registry if it contains a vulnerability above a defined severity threshold. Which capability supports this?
A severity-based scan gate blocks an image containing a vulnerability above a defined severity threshold from being pushed to the deployment registry in the first place. Scanning only after deployment finds the problem too late, once the vulnerable image is already running. This pre-push gate turns image scanning from a passive report into an active control that actually prevents a risky image from reaching production.
3 / 5
In a code review, a dev notices the base image used across every service is rebuilt and rescanned on a recurring schedule, not just once when the Dockerfile was originally written. What does this represent?
Recurring base image rebuilding and rescanning on a schedule catches a vulnerability disclosed after the Dockerfile was originally written, since a package considered safe at build time can have a new vulnerability published later. Building and scanning only once at creation time misses every vulnerability discovered afterward in that same, unchanged base image. This recurring rebuild-and-rescan cycle is what keeps a container image's security posture current rather than frozen at its original build date.
4 / 5
An incident report shows a container image passed its scan and was deployed months ago, and a newly disclosed critical vulnerability in one of its packages has since gone unnoticed because the image was never rescanned after deployment. What practice would prevent this?
Continuously rescanning a running image's contents against the latest vulnerability database, not only at its original build time, catches a vulnerability disclosed after deployment that the original scan couldn't have known about. Scanning only once at build time leaves a running image's security posture stuck at whatever was known on that original date. This ongoing rescanning is necessary because a container image, once built, doesn't automatically stay aware of a vulnerability published against it later.
5 / 5
During a PR review, a teammate asks why the team continuously rescans a deployed container image instead of trusting the scan result from when it was originally built and pushed. What is the reasoning?
A new vulnerability can be disclosed in a package well after an image containing it was originally scanned and deployed, meaning that one-time scan result inevitably goes stale over time. Ongoing rescanning catches that later-disclosed exposure in an image that's still actively running. The tradeoff is the added ongoing infrastructure cost of continuously rescanning every deployed image rather than treating a single build-time scan as sufficient forever.
What does the "Container Image Scanning Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to container image scanning vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 11 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.