Puppet enforces configuration with an agent on each node that pulls a catalog on an interval, rather than an operator pushing over SSH the way Ansible does. What do you gain and what do you give up by choosing the pull model?
answer
- initiative belongs to the node
- the thousandth run is where the value is
- no inventory to keep current
- no primitive for host-by-host ordering
- a merge reaches everything within one interval
basics
~20 sPull buys continuous, unattended enforcement: every node re-applies its catalog on an interval, so manual changes get corrected and rebuilt nodes converge without anyone driving them. The cost is an agent and certificate per node, propagation latency, and no ordered cross-host orchestration.
solid answer
~60 sThe gain is that enforcement is continuous and node-initiated. Nothing has to know the fleet exists: a node that was off, or that was rebuilt an hour ago, converges on its own the next time its agent runs, and a change someone made by hand at 3am is corrected within an interval rather than at the next time an operator remembers to run something. It also inverts the network direction — agents dial out to the server, so you do not need operator SSH reach into every subnet, and the fleet size is bounded by server capacity rather than by one workstation's fan-out. What you give up is immediacy and coordination. Agents run independently on their own schedules, so there is no "do this now, host by host" primitive: rolling restarts and multi-node sequencing need a separate orchestration tool such as Bolt. You also inherit an agent and a certificate authority to operate, and a merge to the production branch reaches everything within one interval — which is why canary node groups and environments matter.
go deeper
Be able to state the mechanical difference plainly: Puppet's agent asks the server for its configuration on a schedule, rather than an operator connecting to the node and running something.
Explain the consequences that follow from that direction — no inventory to maintain, outbound-only connections, and a manual change corrected on the next run rather than the next time someone runs the tool.
Bring the costs unprompted: the CA and agent to operate, the propagation window, and the absence of any host-by-host ordering primitive, which is why an agentless orchestrator sits alongside it.
Own the estate decision — which workloads justify continuous enforcement at all versus immutable images, how environments and canary groups bound a merge's blast radius, and what interval the server fleet can actually sustain.
## What "pull" actually means here In Puppet's agent/server model the initiative belongs to the node. An agent daemon on each machine wakes on its run interval (30 minutes by default), authenticates to the Puppet Server with its own certificate, sends its facts, receives a compiled catalog, applies it and reports. The server is a passive service: it answers requests and stores reports. It holds no list of machines it must reach, and it opens no connection to them. A push tool inverts every part of that. Something outside the fleet decides *when*, decides *which hosts*, connects inward over SSH, and runs to completion. Between runs, nothing is watching. ## What the pull model buys **Continuous enforcement.** This is the headline. The catalog is not applied once; it is re-applied forever. Someone edits a config file by hand to get through an incident, and within one interval the file is back to what the code says. "Configured" stops being an event that happened at provisioning time and becomes a property the node keeps having. **Self-registration and self-healing scope.** New nodes do not have to be added to anyone's inventory to become managed — they install an agent, get a certificate signed, get classified, and converge. A node that was powered off for a week catches up on its first run back. There is no reconciliation step where someone notices the inventory is stale. **Network direction.** Agents make outbound HTTPS connections to the server. That is far easier to justify in a segmented network than an operator's laptop needing inbound SSH to every subnet, and it removes the "who has the deploy key" problem: the trust anchor is the certificate the node was issued. **Fan-out that is someone else's problem.** With push, one machine holds thousands of connections and its own concurrency limits define how long a fleet-wide change takes. With pull, load is spread across the interval, and scaling is a matter of sizing the servers that compile catalogs. `splay` exists precisely to smear that load. ## What the pull model costs **An agent and a CA to run.** Every node needs the package installed and a signed certificate. The certificate authority becomes production infrastructure: expiry, revocation for decommissioned nodes, and the recovery story when a node is rebuilt with the same name are all now yours. Agentless tools skip that entirely. **No on-demand, ordered orchestration.** This is the sharpest limitation and the one interviews probe. Agents are independent; there is no primitive for "drain node 1, restart it, verify, then node 2." You can force a single node with `puppet agent -t`, but coordinating a sequence across hosts is outside the model. Puppet's own answer is a separate agentless tool, **Bolt**, for imperative, ordered tasks — which is a candid admission that pull is the wrong shape for orchestration. **Latency and uncertainty about when a change lands.** A merge to production is picked up by each node at some point in the next interval. That is fine for configuration and terrible as a deployment gate: you cannot easily say "the change is live everywhere" at a moment in time, only that it will be, eventually, on nodes whose runs succeed. **Blast radius by default.** Because every node pulls the same environment's code, a bad commit reaches the whole fleet within one interval with nobody driving it. Push has an accidental safety property here — a human chose the target list. The pull answers are environments, canary node groups pinned to a branch, and treating a merge to production as a production change. **Drift in the gaps.** Enforcement is periodic, not instantaneous. Between runs the node can be anything at all. If you need "never wrong", an interval is not it. ## How to answer the comparison well Do not frame it as one tool being better. Frame it by what the workload needs. Long-lived, mutable servers whose configuration must hold for months — that is the pull model's home ground, because the value is in the thousandth run, not the first. Short-lived instances baked from an image, or a task that is inherently a sequenced operation across hosts, get very little from continuous enforcement and pay the full agent cost. The strongest version of the answer notes that the two models are frequently run together: pull for the steady-state configuration that must stay true, and an agentless, imperative tool for the ordered, on-demand operations that a scheduled loop is structurally unable to express.
- If pull enforcement is continuous, why do teams still keep an agentless tool around?Because ordered, on-demand operations are not expressible as an interval. Draining a node, restarting it, checking health, then moving to the next one is a sequence with a driver — exactly what independent agents on their own schedules cannot coordinate. Puppet ships Bolt for that reason. The healthy split is pull for state that must stay true and a push tool for operations that must happen in a particular order, right now.
- A bad commit lands on the production branch. How is the pull model's blast radius contained?By making the code a node pulls a deliberate choice rather than a single global branch. Environments map to code branches, node groups pin canary nodes to a candidate environment first, and promotion to production is a separate, reviewed step. Reports and noop runs on the canary group are the signal. Without that structure, one merge reaches every node within an interval with nobody in the loop.
- Does continuous enforcement mean the node is never in a wrong state?No — it means wrong states are bounded, not prevented. Enforcement is periodic, so between runs the node can be anything, and the window is up to a full run interval plus the run's own duration. Shortening the interval reduces the window but raises server compile load. If a configuration genuinely must never be wrong, you want an immutable image, not a shorter interval.
saying these in an interview costs you the question
- Claims pull means changes reach nodes instantly
- Says push tools cannot enforce state at all
- Ignores the certificate authority as operational cost
- Thinks Puppet can sequence a rolling restart across hosts
- Frames it as one tool being simply better