The Chef agent: how the desired state reaches every node
Every mechanism has a step-by-step animation, the configuration explained line by line and exam notes. Wherever a parameter changes the outcome, you get a simulator where you change it yourself.
TL;DR
Chef puts an agent, chef-client, on every machine; every 30 minutes (plus a random splay) it authenticates to Chef Infra Server with an RSA key, fetches its run-list and cookbooks, compiles the Ruby recipes into a resource collection and then checks every resource against the real state, changing only what differs. The model is agent + pull: the server never connects to the nodes; the workstation touches the node directly only once, at bootstrap. Roles and environments (or Policyfiles) decide which cookbook version each node gets, attributes merge across 15 levels with Ohai on top, and data bags and search give recipes data about the rest of the infrastructure. On Nexus, the agent runs in the bash shell with the Cisco cookbook; on IOS-XE and IOS-XR, agentless tools take its place. Typical incidents: the clock (401), unsatisfied pins (412) and typos in the names of notified resources.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between Chef, Puppet, Ansible, Salt and between platforms. In the animations, the configuration lines used at the current step are highlighted automatically; the ← → arrows change the step when the animation is selected.
The analogy, in short
Think of a retail chain with a standards manual kept at headquarters. In every store, the store manager comes to the archive on his own every 30 minutes, with his badge, takes the chapters that concern him and walks the store: what is in its place he leaves alone, what differs he fixes. Headquarters sends nobody to the stores after opening.
The model holds up to §11. From §12 on (agentless devices, the comparison with the other tools) it breaks down; see the full analogy and its limits in §15.