Chapters and transcript times will be ready shortly. You can use the video’s Play control or open the MP4 below.
Chapters
Narration transcript
The English narration in this video. Select a time to watch that moment.
Checkpoints let an instructor check specific tasks in each learner’s own class lab.
Start with a prepared lab and open the class draft from your instructor account.
Create the draft before adding checkpoints, and confirm its learner group and source lab.
In Checkpoints, write a student task that explains what the learner should achieve.
Choose Config Contains, then enter the device name, two colons and the required configuration line.
Add a Reachability check when the task requires a device to reach an IP address.
Use the help shown for each check type; its expected expression must match that type’s syntax.
Expressions describe conditions to check, rather than commands to run; use names from the learner’s topology.
To check one interface’s configuration, separate its context from the required line with two greater-than signs.
Add startup-config before the colons when the learner must save that configuration as well.
Interface State checks the actual interface property; operationally up is different from administratively enabled.
Route Present checks a prefix in the routing table, with optional protocol and next-hop requirements.
Neighbor State checks a routing adjacency, such as an OSPF neighbour reaching FULL.
Host File can check a script’s output file, including a specific JSON value.
All Of combines conditions in a JSON list; every condition must pass for the checkpoint to pass.
An optional not flag requires a condition to fail; an unknown result never becomes a pass.
Other types check switching, wireless, services and recorded actions; choose the matching type and follow its hint.
The companion Help article includes examples for all fifty class-compatible types and explains their prerequisites.
Malformed expressions are refused without replacing the saved checkpoint.
You can edit a checkpoint or remove an unwanted one before the class starts.
Expected expressions are visible to the named instructor; learners receive the task descriptions.
Publish the class, enrol the learners and start the session.
Release to Practice so each learner can work in a separate lab copy.
The learner reads the tasks and selects Check my work to evaluate the current lab.
Not yet passed means the condition was checked and is not currently satisfied.
Could not be checked means there is no definite verdict; inspect the checkpoint and the available lab.
Here the interface name is wrong. Correct it in the instructor’s checkpoint editor.
Changing a checkpoint clears that checkpoint’s earlier marks, so test definitions before teaching.
Back in the learner’s terminal, configure the required domain name.
Check the work again and confirm that the configuration task now passes.
Configure and enable the connected interface, then verify the neighbour with a ping.
Check again to confirm that reachability and interface state now pass too.
In Radar, the instructor can compare each learner’s checkpoint progress.
Live practice can refresh results after changes; Check my work requests another check when needed.
If a learner later breaks a completed task, the latest outcome can change while the first passing time is retained.
Restore the configuration before finishing the exercise.
End the class, then expand a learner in Class results to review the recorded outcomes.
Opening this report reads saved results; it does not run another evaluation.
Learners can review their own results without seeing their classmates’ marks.
The instructor can also open Reports and read the recorded history for a teaching group.
An older draft may ask you to review its learner audience before editing.
Choose the current group and confirm it; the draft’s source lab and checkpoints are preserved.
Use class checkpoints for assessment. Standalone lab assignments do not provide automatic checkpoint scores.