This exam closes the "Make a stack reliable" module of the Docker course. A Compose stack works, but not reliably, and you must fix it on your own, with no hints, using what the lessons of the module taught you. It teaches you nothing new, it checks what you have learned. Allow about 45 minutes on a virtual machine running Docker Engine 29.9.2 and Compose 5.6.1.
What you will learn
- Say what the exam provides, what it expects and what it grades you on.
- Spot the lessons to review before you start.
- Read your result to decide whether to move on to the next module or to consolidate.
Prerequisites
The lessons of the "Use Docker" level, those of the module "Describe an application with Compose" with its exam, then those of the module "Make a stack reliable" must be finished, up to the last one, Development and deployment: explicit variants. The first of these two modules teaches you to read and edit a compose.yaml and to display the effective configuration with docker compose config. The exam assumes that you know how to do this, and that you have already applied each action of the "Make a stack reliable" module to an example.
Use the lab environment you used for the previous lessons. The images are provided: the exam asks you to build nothing.
What does the exam ask of you?
The statement describes a stack that misbehaves and says what it must do once fixed. You must leave it in a state the lab can check: it starts correctly on the first try, it survives a failure, and its settings are placed where they belong.
The statement gives the expected behavior, not the lines to write. This page does not describe the scenario, 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 the commands you typed. It reads back the state of the system at the moment you hand in your work: what is running, what responds, what Compose has resolved. Some checks trigger the event to be measured themselves, for example the death of a service. The lab itself restarts the stack from scratch using your file, so a setting applied only to a running container does not count. Two different compositions that end in the same state get the same grade.
Five 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 five, multiplied by a scale of 100 points minus the cost of the hints you asked for.
A critical requirement comes on top of the threshold: the password must no longer appear in the containers' environment, in the image or in the configuration resolved by Compose, and the service must still receive it (the application still serves a value that depends on it). If it fails, the exam is refused whatever the total: a good total does not make up for an exposed secret.
With no hint, four checks passed out of five give 80 points and clear the threshold, provided the critical requirement is met. Each hint lowers the maximum you can reach:
| Hints requested | Scale | Checks to pass |
|---|---|---|
| None | 100 | 4 out of 5 (80 points) |
| The first | 90 | 5 out of 5 (4 out of 5 give 72) |
| The first two | 75 | 5 out of 5 |
| Three or more | 55 at most | Threshold 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, from 10 for the first to 25 for the last. With two hints, you must pass all five checks; beyond two, the threshold is no longer reachable. An exam passed without a hint is therefore passed in full.
- 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, compare what you wrote with what Compose understood: the effective configuration often shows where the gap lies.
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 of the module that teach an action useful here. Start by rereading those where your last labs were difficult.
- Inject secrets, and know their limits
- Startup, readiness and health
- Limit resources and restarts of a Compose stack
- Development and deployment: explicit variants
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 45 minutes ahead of you, so that you can work in one go.
After the exam
If you pass the threshold without exposing the secret, you can make a Compose application reliable on your own, 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 the symptom observed, not the action to take. It is up to you to link each failed check to a lesson in the list 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 system.
- The grading ignores the commands you typed. It looks at what is running, what responds and what Compose has resolved, and it triggers the failures to test itself.
- You need 75 points to pass. A password still present in the containers' environment, the image or the resolved configuration, or that no longer reaches the service, fails the exam whatever the total.
- The effective configuration is your first diagnostic tool: compare it with what you meant to write.
- To close a gap, reread the matching lesson, then redo the action.