This assessment closes the foundation: you are handed a web service that is already published over HTTPS, you document it, you prove it works, you find the cause of an incident that nobody described to you, then you restore its backup. It is meant for someone who has followed the foundation lessons, from Publish a web service to Diagnose a web service layer by layer. Allow an hour and a half. It also assumes you can read the state of a systemd service on Debian 13, edit its unit then reload it, and edit the configuration file of a system service such as a local DNS resolver. No foundation lesson teaches this: these gestures are those of systemctl: list, start and diagnose Linux services, to be read before you start if you do not practise them.
On the bench, the configuration files in place give you, most of the time, the
expected syntax, and the repair then consists of correcting them. One
exception is worth knowing before you meet it: the incident may have
removed a whole line, and the remaining file then shows you no example of it.
This is the case of the line that associates a name with an address in the
resolver; the unbound.conf(5) manual describes it, so try man 5 unbound.conf
on the machine, and failing that, Unbound's online documentation.
What you will learn
The assessment teaches no new gesture: it teaches you to mobilise alone those of the foundation on a service you did not set up, without knowing in advance where the failure hides. You will be able to:
- Describe a published service as it really is, not as it is believed to be
- Accept a publication from an independent client
- Diagnose an unknown failure and justify your reasoning
- Repair with a minimal change
- Restore a backup and prove its reliability
The need
The epreuve.test service answers on the edge.lab machine, over TLS, behind a router
that relays to a protected backend. The backend is the application behind the
router; it holds a business value and its backup. Everything is in place before you
arrive: you are handed a running service, not a blank machine.
Shortly after it went live, an incident was introduced. Nothing tells you which
layer it affects: along the way, the service will not behave the way the document
you will have written claims. The poste.lab machine plays the independent client,
the one that looks at the service from the outside, without the operator's
access.
The constraints
Each requirement is proven by an observable state, not by a statement. A document says what you believe; a response obtained says what the service does. Four requirements are to be met, in this order.
| # | Requirement | What will be observed |
|---|---|---|
| 1 | An architecture document describes the service | the document exists and names epreuve.test |
| 2 | The service works, seen from poste.lab | a correct response to data you did not choose, and /admin denied |
| 3 | The incident is diagnosed then repaired | the layer and the component at fault named, then the service answers again |
| 4 | The backup is restored with trust | the configuration and the data recovered, the service answering under strict TLS |
Before running restaurer.sh, the check deletes the service's configuration and
active data: the script must rebuild everything from the backup, and any work you
have not recorded there is lost.
What you must deliver
Three deliverables, placed in /home/student/ on edge.lab, in addition to the final state of
the service. The document dossier.md describes the real architecture: names,
flows, identities and responsibilities. The incident.yaml file carries three
fields, couche, composant and explication; the last one says
how you reached the diagnosis, hypotheses ruled out included. The
restaurer.sh script replays the restore.
The layer is written with one of these five values: dns, transport,
tls, route or backend, which correspond, in the order of the foundation, to the name,
the port, TLS, routing and the application. The component names the
single faulty part. Citing every part at once is not a
diagnosis: the trails ruled out belong in the explanation, not
in the component.
How to assess yourself
The automated check scores facts compared with the real state of the machine; the relevance of what you write is read by a reviewer. This distinction is deliberate: a machine does not judge a document, and a long text that uses the right words is not coherent for all that.
What the check measures:
- the document exists, is not empty, and names
epreuve.test; - from
poste.lab, the service answers with a value drawn at the time of the attempt, the real business value, under strict TLS verification, and/adminstays denied (403); a request that does not specify the test authority must fail, so that authority must not become trusted for the whole workstation; - the
couchefield designates the layer that is really broken, thecomposantfield names the faulty component without citing any unrelated layer, andexplicationis filled in; - the service answers three times in a row after the repair;
- after the restore, the configuration and the data are those of the
backup, the service answers,
/adminstays denied and the TLS verification stays strict.
What is read and not scored: the coverage of your document and the quality of your reasoning. A green check does not replace this review, and reading every lesson does not prove that you can do it either: only the service's response proves it. A missed requirement does not call for a ready-made solution, because no answer key appears in the guides. Go back to the lesson that teaches the missing gesture, then start again from a clean state.
Practice: take the assessment
The assessment takes place in the lab. It lasts about 90 minutes and gives no hint. Start it when you have time to finish it in one sitting.
Key points
A foundation assessment proves a state and a line of reasoning.
- A document describes the real service, and a diagram alone does not demonstrate its behaviour.
- An acceptance test is played from an independent client, with TLS verification intact.
- A diagnosis names the layer and the component, with the hypotheses ruled out as supporting evidence.
- A backup is worth something only restored, with its configuration, its data and its trust.
- Having read every page does not validate the skill: only the service that answers proves it.