This exam closes the "Persist your data" module of the Docker course. You receive a containerized application that no longer works, and you must bring it back into service on your own, with no hints, using what the previous lessons taught you. The exam tells you whether you can do it, not only whether you understood. 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.
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 Compose or to consolidate.
Prerequisites
The lessons of the first five modules, from "Discover Docker and run a container" to "Persist your data", must be finished, up to the last one, Docker volume permissions: three common causes of an access denied. The exam assumes that you know how to start, observe and stop a container, and that you have already handled networks and volumes.
You also need to be able to write a short shell script and make it executable, because the exam asks you to deliver one. The Linux course teaches it, for example in Your first Bash script: create and run it step by step.
This deliverable is placed in a system directory that only root can modify: you will need sudo to install a file there. The account on the exam machine must therefore be able to use it.
Finally, use the lab environment you used for the previous lessons.
What does the exam ask of you?
The statement describes a containerized service that no longer does what it used to do. You must bring it back to working order, then leave it in a state the lab can check: it responds, its access is limited and its data is kept. In other words, it must be reachable only through the intended paths, and everything it had accumulated must still be there.
Nobody tells you where to look. The statement gives a symptom you can observe, not the cause, and several elements may be at fault at the same time. The diagnosis is therefore part of the exam, just as much as the repair. 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, and one of the checks also runs the short shell script you delivered. Two different paths that end in the same state get the same grade, and a correct command that did not produce the expected effect earns nothing.
Five checks of equal weight share the grade, and you must reach 75 points to pass. One requirement comes on top of the threshold. Keeping the data is critical: a good total does not make up for lost data. Since the grade covers the final state, check what you leave behind before you hand in.
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. 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 does not explain anything a second time, because the previous lessons have already taught what you need to know.
If you are stuck, first read what the system answers before trying something else. An error message, an exit code or the result of an inspection often points to the next command. Remember too that a connection that succeeds does not prove that a service responds. Read the response it returns.
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. Start by rereading those where your last labs were difficult. That is a better criterion than the order of the list.
- Images, containers and registries: the anatomy
- Run a Docker container and choose what it runs
- Container lifecycle, PID 1 and clean shutdown in Docker
- Inspect a running container with Docker
- Read a Docker startup failure: exit codes and loops
- Publish a Docker port without exposing the whole host
- Default Docker network or your own: which to choose?
- Docker volumes: keep your data and mount files
- Docker volume permissions: three common causes of an access denied
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 and your data is kept, you can bring a containerized service back into working order on your own, on the points the exam measures. You can move on to Compose. 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 a second time, 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 is reachable and what has been kept, and it runs the script you delivered.
- You need 75 points to pass, and keeping the data is a separate requirement.
- The diagnosis counts as much as the repair. Read the messages, the exit codes and the inspection before you act.
- To close a gap, reread the matching lesson, then redo the action.