This exam closes the "Test, shrink and deliver an image" module of the Docker course. The mission: deliver an image that another, bare machine actually runs. You build the image without any build secret staying in it, you publish it to a private registry with the account that is allowed to, then you prove that a client with nothing from your workstation pulls it by its digest and makes it answer. It teaches you nothing new, it checks what you learned. Allow about 60 minutes on two virtual machines running Docker Engine 29.9.2.
What you will learn
- Say what the exam checks, and on which state of the system.
- Spot the lessons to review before you start.
- Launch the exam with
dsoxlab runand read your result.
Prerequisites
The lessons of the module must be finished, up to the last one, Export an image without a daemon with Skopeo. The exam also draws on the lesson BuildKit: build secrets and private access, which belongs to the previous module. The exam assumes that you know how to mount a secret during a build, publish to a registry that requires TLS and authentication, and identify an image by its digest rather than by a tag.
You need the lab environment of the course, with the ability to start two virtual machines. You have nothing else to install.
What does the exam ask of you?
The statement involves two machines. The first one builds and publishes: it holds what is needed to make the image and the account allowed to push. The second one is a bare client, which trusts only the lab's authority and has only a read-only account. An image that runs only on the machine that built it is not delivered.
This page does not describe the scenario or its values, so that the exam stays a measurement. You will read them in the lab statement, and only there.
How is it graded?
The lab does not read your commands. It reads back the state of the two machines when you hand in your work: the published image, what it contains, what the registry serves of it, what you recorded, and the container running on the client. Two different paths that end in the same state get the same grade.
Four checks of equal weight share the grade:
| Check | What is read |
|---|---|
| The delivery is published | The recorded reference carries the digest that the registry actually serves |
| The secret did not survive | The recorded fingerprint is the right one, and the value of the secret is absent from the history and from every layer |
| The client runs the delivery | The container runs on the bare client, created from the reference by digest, and answers |
| The registry stays closed to the client | The registry still refuses the read-only account the publication of a new image derived from your delivery |
A critical requirement comes on top of the threshold of 75 points: the second check must pass in full. The recorded fingerprint must be right, and the secret must be found neither in the history nor in any layer of the image. A wrong fingerprint therefore fails the exam as surely as a forgotten secret. For the layers, the check does not look at what a container sees when it starts: it reads the complete image, layer by layer, and searches for the value of the secret. If this requirement fails, the exam is refused whatever the total: a secret erased by a later instruction stays readable in the layer that wrote it, and an image goes to a registry where others read it.
The fourth check deserves a precaution. The rights of the two accounts are set by the lab, and the check does not grade an attempt of yours: it observes, after your work, that the registry still refuses to write for the reader. It fails if, to get the delivery through, you weakened this refusal. Since it builds its test from the delivery present on the client, it also fails when the client has not pulled your image: it depends on the third check. Knowing how to verify it yourself remains useful: a push that returns code 0 does not prove that the account is limited, because pushing again content that the registry already holds writes nothing, and so asks for no right. Only an attempt that really requests a write establishes that the refusal exists.
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, which cost 10, 15, 20 and 25 points, and whose costs add up. The score is the share of checks passed, multiplied by a scale of 100 points minus the cost of the hints requested.
- You may consult the lessons of the course and the official Docker documentation, as you would at work.
- The statement explains nothing again: the lessons of the course have already taught what you need to know.
With four checks, each is worth a quarter of the scale. The table shows the margin left by each level of hints.
| Hints requested | Scale | Checks to pass |
|---|---|---|
| None | 100 | 3 out of 4 (75 points, right at the threshold) or 4 out of 4 |
| The first | 90 | 4 out of 4 (90 points; 3 out of 4 give 68) |
| The first two | 75 | 4 out of 4 (75 points, right at the threshold) |
| Three or more | 55 at most | Threshold not reachable |
In every case, the critical requirement must be among the checks passed. An exam passed without a hint is therefore passed in full.
Which lessons should you review before starting?
The statement does not say which actions it asks for, and this list does not try to point them out either. It gathers, in the order of the course, the lessons that teach an action useful here, whether or not they belong to this module. Start by rereading those where your last labs were difficult.
- BuildKit: build secrets and private access
- Test the contract of an image
- Publish and pull an image in a controlled way
- Serve a trusted registry, and log in to it
- Pin a base image, and deliver it offline
If the identity of an image by its digest still feels unclear, the page Read an OCI image and its identity details it.
What practice should you do before the exam?
The lesson on the trusted registry had you authenticate an account, but not limit what an account can do: a valid login is not a permission. A short lab works on this precise point, with a separate publisher and reader, in the same kind of setting as the exam. It is optional and is not graded in the exam, but it saves you from discovering the fourth check during the measurement.
Take the exam
The lab prepares the two machines, gives you the statement, then grades the state in which you leave them. Start it when you have about an hour ahead of you, so that you can work in one go.
From your lab environment, the command is launched like this:
dsoxlab run epreuve-livrer-une-imageThe statement is displayed, you work on the two machines, then the lab plays its four checks. Read the result check by check: a message describes what is missing from the delivery, never the command to type.
After the exam
If you clear the threshold with the critical requirement met, you know how to deliver an image usable elsewhere, on the points measured. A result under the threshold does not mean that you failed to learn: it shows where the gap is.
Link each failed check to a lesson in the list above, reread it, then redo the action yourself. Do not try to memorize an answer: a new attempt draws a different build secret.
Key points
- The exam is a measurement: nothing is explained again, hints cost points, and the grade covers the final state of the two machines, not your commands.
- You need 75 points. With no hint, three checks out of four are enough; with one hint, all four must pass, as with two; beyond that, the threshold is no longer reachable.
- The secret check is blocking in full: a wrong fingerprint, or a secret present in a layer even if erased afterwards, fails the exam whatever the total.
- An image is delivered only if a bare client pulls it by its digest and runs it.
- A push that succeeds does not prove a write right: to establish that an account is limited, you must try what the registry does not already hold.