MPLS: labels instead of addresses, services on top of labels
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 where you change it yourself.
TL;DR
MPLS puts a 4-byte header with a 20-bit label in front of the packet: the ingress PE does the only IP lookup and pushes the label, the P routers swap it from the LFIB without looking at the IP, and the penultimate hop pops it. Labels are distributed by LDP (following the IGP), RSVP-TE (along a path chosen by the head-end) or Segment Routing (from the IGP, with a global block). On top of the transport label sit the service labels: VPN (MP-BGP, with VRF, RD and RT), VC (pseudowire, targeted LDP) or BGP-LU (between ASes). The core does not know the customer routes; that is why almost every MPLS incident looks the same: IP ping works, the VPN does not — and you find it with traceroute mpls, not with ping.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between standards and between Cisco platforms. 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 airport baggage tags: at check-in nobody reads your home address, a short code is stuck on; the hubs scan the code, stick on the code of the next leg and send the bag onward; the last hub tears the tag off before the final flight. A group's bags travel in a container with a transport tag on top and group tags inside, read only by the agency's representative at the destination.
The model holds up to §9. From §10 onward (TE reservations, segment lists, per-label QoS), it is stretched to its limit; see the full analogy and its limits in §17.