EEM: the agent that reacts on the device
Every mechanism has a step-by-step animation, the configuration explained line by line and exam notes. Where a parameter changes the outcome, you get a simulator where you change it yourself.
TL;DR
Embedded Event Manager is on-box automation: detectors watch the logs, the typed commands, the clock, track objects and counters, and the registered policies — applets in the configuration or Tcl / Python scripts — run actions when their event occurs: CLI commands, syslog, mail, configuration changes, even reload. Everything happens locally, in seconds, even when the link to the NOC is down. The rules that decide whether an applet works: enable before the commands, labels sorted alphanumerically, maxrun larger than the duration, an explicit _exit_status when intercepting commands and a pattern tested on a real message.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between IOS-XE, NX-OS and IOS-XR. In the animations, the configuration lines used at the current step are highlighted automatically; the ← → arrows change the step when the animation is focused.
The analogy, in short
Think of the butler of a large house, with a notebook of cards received from the masters: "when the kitchen bell rings a third time within a minute, close the door and send a letter". He does not invent events, he executes the cards literally, in the order they sit on the shelf, and has twenty minutes for each.
The model holds up to §11. At §12 (the platforms) it stretches, and at the syntax differences it breaks; see the full analogy and its limits in §15.