YANG: the model behind network automation
Every mechanism has a step-by-step animation, the configuration explained line by line and the exam notes. Where a parameter changes the outcome, you get a simulator in which you change it yourself.
TL;DR
YANG is the language in which a device describes its data: a tree of modules, containers, keyed lists and typed leaves, with restrictions (range, pattern, must, when) that the server checks before accepting anything. Configuration data lives in running, candidate and startup; state comes from operational. The same tree travels as XML through NETCONF (SSH 830), as JSON through RESTCONF (HTTPS 443, the path becomes a URL) and as protobuf through gNMI, and model-driven telemetry publishes the state nodes without polling. IETF, OpenConfig and native models coexist on a device; hello / yang-library says what's implemented, with revisions, features and deviations. Most errors are structured — unknown-element, invalid-value, data-exists, access-denied — and each one shows exactly the rung where you went wrong.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between platforms and between standards. In the animations, the configuration lines used in the current step are highlighted automatically; the ← → arrows change the step when the animation is selected.
The analogy, in short
Think of a restaurant with a recipe book: every dish, every option and every allowed value is written in the recipe book, and an order is placed only according to it. The waiter (NETCONF) notes it on a draft notepad and sends it to the kitchen all at once; the delivery app (RESTCONF) has an address for every dish; the screen above the bar shows the orders' status live (telemetry).
The model holds up to §10. From §11 on (tools, access control, troubleshooting), it breaks; see the full analogy and its limits in §15.