This exam is the final exam of the Docker course. The mission: take over a service you did not write, and carry it from end to end. You must build it and ship it by its digest, deploy it isolated and hardened, recover it when it fails, restore it on a second machine, refuse a rollback that would lose data, then maintain it without cutting its reads. It teaches you no new notion from the course, it brings them all together. It assumes only two basic skills that come from Linux, described in the prerequisites. Allow about 180 minutes on two virtual machines running Docker Engine 29.9.2.
What you will learn
- Say what the exam expects and on which state of the system it grades you.
- Tell apart what the lab measures automatically from what a human assessor reads.
- Work out, depending on the hints requested, the checks you must pass to reach the threshold.
- Find, for each family of checks, the lesson to review.
Prerequisites
All the lessons of the course must be finished, up to Prepare operations, and recognize the limits of a single host. You must also have passed the end-of-module exams that come before: this one chains them, without explaining anything again.
Two skills come from the Linux training: administer and secure a server and are not explained again here: connecting to a machine with an SSH key and running a command on it remotely, then writing a Bash script that runs without arguments and whose exit code says whether it succeeded.
Use the lab environment you used for the previous lessons. The lab provides an incomplete delivery, a local registry and a second machine for the restore. Plan for three uninterrupted hours.
What does the exam ask of you?
The statement describes an application made of an API and a PostgreSQL database, to be shipped and then operated. At the end, the state of the two machines must show that:
- the image is built in several stages, published, pulled and deployed by its digest, and its software inventory matches what is really installed;
- the application is isolated and hardened, and its data survives the replacement of its containers;
- it recovers thanks to your recovery script after failures that you are not told about, without losing what was written;
- it is restored on a second machine, data included;
- a rollback to a faulty image is refused when it would make the data unusable;
- a targeted maintenance removes what is useless without interrupting the reads or touching the data to keep.
The full statement, with the names, the ports, the scripts to deliver and the conditions of the maintenance, is read in the lab, and only there.
How is it graded?
The lab does not read the commands you typed. It gives no grade until the delivery is sound, then it reads back the state of the system through eleven independent checks. Each one covers a family of facts.
| Check | What is read |
|---|---|
| Identity of the delivered image | The manifest in the registry, the pulled digest and the image actually deployed designate the same artifact |
| Software inventory | The inventory matches the packages really installed in the image and its code |
| Multi-stage build and build secret | The build secret was used without staying in the image, and the final image is reduced to the runtime |
| Hardened execution | Unprivileged user, read-only root filesystem, capabilities dropped, no-new-privileges, resource limits, secret kept out of the environment, health and startup order |
| Network isolation and real writes | The database is not published, the internal network is respected, and the requests really write to PostgreSQL |
| Data and replacement of containers | The data survives the replacement of the database and of the API |
| Eight incidents | The eight injected failures are repaired by your recovery script, without losing any data; a single check, passed only if all eight are recovered |
| Interrupted dependency | The database cut off causes a measured outage, then the reads resume without restarting the API |
| Restore on a second VM | The application and the data written since are restored and served on the other machine |
| Rollback | The accepted identity is restored, and an incompatible schema is refused without losing a row |
| Targeted maintenance | The reads continue during the command, the backup really restores, only the designated objects disappear |
Each check reads a measured state, never an intention. For example, the restore queries the restored application with data written after the delivery, and the maintenance probes the reads while it runs.
The threshold is 75 points. It comes with a requirement that no total offsets: five checks must pass, whatever the grade. They cover the data that survives the replacement of containers, the multi-stage build and the build secret, the network isolation with real writes to PostgreSQL, the hardened execution, and the identity of the image by its digest. The lab engine blocks only on these five checks. Elsewhere (maintenance, incidents, restore on the second VM), a fault costs only the check concerned. The 75-point threshold may be recalibrated after the first attempts.
One part of the exam does not count in the lab grade: the runbook you write and the decision in front of an irreversible migration. No script grades them, and the lab does not count them in the 75 points. A human assessor reads them separately, and if you work alone, it is up to you to question yourself, with the questions of the "After the exam" section. This reading completes the eleven checks, it does not replace them.
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 eleven checks of equal weight, each is worth a little over 9 points out of 100. The table shows the margin left by each level of hints.
| Hints requested | Scale | Checks to pass |
|---|---|---|
| None | 100 | 9 out of 11 (about 82 points); 8 out of 11 give about 73 |
| The first | 90 | 10 out of 11 (about 82 points); 9 out of 11 give about 74 |
| The first two | 75 | 11 out of 11 (75 points, right at the threshold) |
| Three or more | 55 at most | Threshold not reachable |
In every case, the five checks that no total offsets must be among the checks passed: those on the identity of the image, the build and the build secret, the hardened execution, the network isolation and the data that survives the replacement.
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, family of checks by family of checks, the lessons that teach an action useful here. Start by rereading those where your last labs were difficult.
For the image, its registry and its identity:
- 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
- Promote the same artifact between two environments
- Check what an image contains, and who signed it
For the build:
For deployment, hardening and isolation:
- Read-only root filesystem, and a shutdown without data loss
- Inject secrets, and know their limits
- Limit resources and restarts of a Compose stack
- Organize the networks of a Compose stack
- Isolating a container from the network: none or an internal network
- Persist the data of a recreated stack
For failures, the restore and the rollback:
- Startup, readiness and health
- Read a Docker startup failure: exit codes and loops
- Back up and restore an application
- Update, and roll back without losing data
For maintenance and operations:
- Find orphan Docker volumes without deleting everything
- Prepare operations, and recognize the limits of a single host
Take the exam
The lab prepares the machines, gives you the statement, then grades the state in which you leave them. Start it when you have about 180 minutes ahead of you, so that you can work in one go.
From your lab environment, the command is launched like this:
dsoxlab run capstone-chaine-completeThe statement is displayed, you work on the machines, then the lab plays its checks. Read the result check by check: a message describes what is missing from the final state, never the command to type.
After the exam
If you clear the threshold with the five checks that no total offsets passed, you know how to ship, recover and maintain a containerized application, on the points measured, which is the goal of the course. A result under the threshold does not mean that you failed to learn: it shows where the gap is.
Link each failed check to the lesson of its family, reread it, then redo the action yourself. Do not try to memorize an answer.
The runbook and the decision in front of an irreversible migration receive no grade from the lab. To assess them yourself, answer these questions in writing, drawn from what the statement asks:
- Does your
RUNBOOK.mddescribe the dependencies, the published access points, the inventory decisions, the recovery and rollback commands, the restore checks and the limits of the service? - Why does going back to a previous image not undo a schema migration that has already been applied?
- Between a proven restore and a corrective migration, how do you choose when the migration is irreversible, and on which criteria?
- Do you distinguish the maintenance window measured by the lab from what a production commitment is (SLO, RPO, RTO)?
- Can you say what this two-machine exercise does not demonstrate, namely high availability and native ARM64 support?
Key points
- The exam is a measurement: nothing is explained again, hints cost points, and the grade covers the final state of the machines, not your commands.
- You need 75 points out of eleven checks. With no hint, nine are enough; with one hint, ten; with two, all eleven; beyond that, the threshold is no longer reachable.
- Five checks that no total offsets fail the exam on their own, whatever the total: data that survives the replacement, multi-stage build with build secret, network isolation with real writes, hardened execution, identity of the image by its digest.
- The runbook and the decision in front of an irreversible migration do not count in the lab grade: going back to an image does not undo a migration.
- A result is proved by a measured state, not by an intention.