This assessment ends level 2: you take over a Traefik entry point that you do not know, you protect it, you make it observable, then you find the cause of an undocumented failure from the evidence alone. It draws on the middlewares, entry point protection, logs and metrics and troubleshooting. Allow an hour and a quarter. It is meant for someone who has followed the "Traefik: protect" and "Traefik: observe and operate" modules.
What you will learn
The assessment teaches no new gesture: it teaches you to mobilise alone the gestures of level 2 in a realistic situation, where the incident is not explained. You will be able to:
- Secure the administration of an inherited deployment
- Add security headers and rate limiting
- Make the proxy observable with filtered JSON logs and metrics
- Alert on 5xx responses
- Diagnose a failure and record it in a report
The need
You take over a Traefik deployment that you do not know, and
users report that app.lab.test is unavailable. The administration
route has not been reviewed and the proxy has no usable
monitoring. You have 75 minutes.
The initial incident is not documented: nothing tells you which component is at fault. You rely on the observed HTTP response and on Traefik's logs, exactly as on a real on-call shift.
The constraints
Each requirement is proven by an observable state: a response, a log line, a metric. A configuration reread says what you meant to do; a response obtained says what the system really does.
| # | Requirement | What will be observed |
|---|---|---|
| 1 | The administration is secured | an unauthorised access refused |
| 2 | Security headers are added | the headers present in the responses |
| 3 | Rate limiting protects the application | an excess of requests refused |
| 4 | The access logs are in JSON and filtered | usable JSON lines, without the noise to discard |
| 5 | The Prometheus metrics are exposed | the metrics readable |
| 6 | An alert covers 5xx responses | an alert rule on these responses |
| 7 | The application is restored | the right response obtained after repair |
What you must deliver
An incident report, in addition to the final state of the deployment. Record
in /opt/pub-epreuve-niveau-deux/incident-report.txt five elements: the
symptom observed, the evidence taken from the logs, the cause, the
fix applied and the response obtained after repair.
This report must be readable by someone who did not attend the session. It rests on what you observed, not on what you suppose: a cause without evidence is only a hypothesis.
How to assess yourself
Reread the seven requirements then the report: a requirement is met or missed, and a report without evidence does not count. A failure repaired but badly explained remains a diagnosis failure, because the same incident will come back.
A missed requirement does not call for a ready-made solution: the reference answer key does not appear in the guides. Go back to the lesson that teaches the missing gesture, then start again from a clean state. The lab's automated check is authoritative: the assessment is passed when it passes.
Practice: take the assessment
The assessment takes place in the lab. It lasts 75 minutes and gives no hint. Start it when you have time to finish it in one sitting.
Key points
A level 2 assessment proves a state and a line of reasoning.
- The administration, the headers and the rate limiting are proven by responses.
- The JSON logs and the metrics make the proxy observable.
- A 5xx alert warns before the users do.
- The diagnosis starts from the HTTP response and the logs, not from a hunch.
- The incident report ties together symptom, evidence, cause and fix.