This exam closes the "Build advanced images" module of the Docker course. A provided image works, but it is heavy, it ships its compiler, the token of a private repository was used to build it and it exists for a single architecture. You rebuild it on your own, so that a single image ends up slimmed down, with no readable secret, served for two architectures and identified by its digest. It teaches you nothing new: it checks that you can chain together actions you saw separately. Allow about 60 minutes on a virtual machine. The exam is attested on Docker Engine 29.9.2.
What you will learn
- Say what the exam provides, what it expects and what it grades you on.
- Link each check to the lesson that teaches what it measures.
- Read your result to decide whether to move on to the next module or to consolidate.
Prerequisites
The four lessons that prepare this exam must be finished:
- Read an OCI image and its identity
- Separate build from runtime: the multi-stage build
- BuildKit: build secrets and private access
- Build an image for several architectures
The exam assumes that you know how to say which exact identity the registry serves for an image, write a multi-stage Dockerfile, pass a secret to an instruction without it staying in the image, and publish an image for two platforms. Use the lab environment you used for the previous lessons: the lab installs the registry and the emulation of foreign architectures itself, so you have nothing to install.
What does the exam ask of you?
The statement describes an image that works but that nobody should ship as it is. The title of the lab speaks of four demands: a multi-stage build, a build secret, two architectures and the identity of the index. Six checks measure them, all on the image published in the lab's registry.
- Two checks cover the multi-stage build: the final image runs its business workload without a compiler or a package manager, and its size stays under a threshold.
- Two cover the secret: nothing readable leaks, and the private dependency was indeed fetched during the build.
- One check covers the architectures: both must run.
- One check covers the identity: the digest is recorded in a file.
This page does not describe the scenario in detail, so that the exam stays a measurement. You will read it in the lab statement, and only there.
How is it graded?
The lab does not look at your Dockerfile or at your commands. It reads back the state of the system at the moment you hand in your work, and it does so on the image pulled from the registry, not on an image left in your local store: publishing without keeping anything at home is the normal way to deliver, and the exam does not punish it. Two different Dockerfiles that produce the same image get the same grade.
Six checks of equal weight share the grade, and you must reach 75 points to pass. The grade is the number of checks passed divided by six, multiplied by a scale of 100 points minus the cost of the hints you asked for, then rounded to the nearest integer, and to the even value on a tie: 62.5 therefore gives 62. The cost of a hint is deducted from the scale before the calculation, so asking for help caps the grade you can reach.
The table below links each check to the lesson that teaches what it measures. It does not say which action to apply.
| What the check verifies | Lesson that teaches it |
|---|---|
| The content of the published image and its execution | The multi-stage build |
| The size of the published image | The multi-stage build |
| What the delivery leaves readable | BuildKit: build secrets |
| The embedded private dependency is indeed the one from the repository | BuildKit: build secrets |
| The architectures the registry serves, and their execution | Build for several architectures |
| The identity recorded in the requested file | Read an OCI image and its identity |
A critical requirement comes on top of the threshold: the token must appear neither in the layers of the image nor in its history. Anyone who pulls an image can read both, while the image looks clean when it runs: this leak is easy to miss. It is the only blocking check. If the token leaks, the exam is refused whatever the total, and no other point makes up for a shipped secret.
The check of the private dependency, for its part, is not blocking. Removing the token without using it is therefore not a way out: the image no longer embeds the repository's dependency, and that costs you this check.
The size threshold is written nowhere in the test. The lab computes it by building a reference itself on your machine, which prevents it from going stale at the first update of a base image. Likewise, the index you publish may carry more than two entries, because the build tool adds its attestations to it: the check looks for the two architectures among them.
With no hint, five checks out of six give 83 points and clear the threshold, provided the token does not leak. Four checks out of six never reach it: even with no hint, they give 67 points. Each hint also lowers the maximum you can reach.
| Hints requested | Scale | With 6 checks out of 6 | With 5 checks out of 6 | Threshold of 75 points |
|---|---|---|---|---|
| None | 100 | 100 | 83 | Reached with 5 out of 6 |
| The first | 90 | 90 | 75 | Reached with 5 out of 6, right at the threshold |
| The first two | 75 | 75 | 62 | Reached only with 6 out of 6 |
| Three | 55 | 55 | Less than 55 | Not reachable |
| Four | 30 | 30 | Less than 30 | Not reachable |
Which rules apply?
This exam measures, it does not guide you. Three rules follow from that.
- The lab offers four hints, from the vaguest to the most explicit, and each one costs you points: 10 for the first, 15 for the second, 20 for the third and 25 for the last. With two hints, you must pass all six checks; beyond two, the threshold is no longer reachable. Only an exam taken without a hint can therefore reach 100 points.
- You may consult the lessons of the course and the official Docker documentation, as you would at work.
- The statement explains nothing again, because the lessons of the module have already taught what you need to know.
If you are stuck, reread the statement and check your work the way someone receiving the image would. An image that works on your machine does not prove that it can be delivered.
Take the exam
The lab prepares the machine, gives you the statement, then grades the state in which you leave it. Start it when you have about an hour ahead of you, so that you can work in one go. A build for two architectures takes longer than a simple build: factor it into your time.
After the exam
If you reach the threshold with the token protected, you can combine in a single image a multi-stage build, a controlled secret and a publication for two architectures, on the points measured. You can move on to the next module. A result under the threshold does not mean that you failed to learn. It shows where the gap is.
The messages of the checks describe what is missing from the delivery, not the action to take. It is up to you to link each failed check to a lesson in the table above, to reread it, then to redo the action yourself. Do not try to memorize an answer.
Key points
- The exam is a measurement. Nothing is explained again, hints cost points and the grade covers the final state of the image pulled from the registry, not your Dockerfile.
- You need 75 points to pass, on six checks of equal weight. With no hint or one, five checks out of six are enough; with two hints, all six must pass; with three or more, the threshold is no longer reachable.
- Only one check is blocking: if the token can be read in the layers or in the history, the exam is refused whatever the total. A missing or wrong private dependency costs its own check, without blocking.
- Shipping means putting the image in a registry and being able to say which exact identity it serves.
- To close a gap, reread the matching lesson, then redo the action.