Puppetクライアントはサービスとして動作するため、Puppetサーバは設定の変更内容をクライアントマシンにいつでもプッシュできる。また、クライアント側は通常、システムの設定が該当するマニフェストに記述された内容と一致しているかどうかを定期的にチェックしている。たとえば、上記のようにPuppetの起動によって「/etc/puptest」ファイルのパーミッションが変更されたあとで、このファイルの所有者を私の手で「ben」に変えても、この変更はPuppetによる次回のチェック時に、マニフェストに記述された設定に戻されることになる。デフォルトでは、こうした設定のチェックが30分ごとに行われる。この間隔は「/etc/puppet/puppet.conf」ファイルの「[main]」セクションにある「runinterval」の値を秒数で指定することで変更できる。
Puppetは、必ずしもクライアントサーバモードで実行する必要はない。ホストがPuppetをサービスとして実行していなくても「puppet /etc/puppet/manifests/site.pp」のようなコマンドでPuppetクライアントを実行すれば、設定ファイルの内容を直接そのクライアントに適用できる。また、中央のサーバから各ホストに対してすべての設定ファイルを適用することもできる。あるいは、変数への代入操作やテンプレートファイルを利用して、パスやホスト名といった要素を設定ファイルに盛り込み、クライアントに適用することも可能だ。
Puppetは、ディストリビューションによる設定の違いをサポートしている。言語に関するチュートリアルには、sshサービスの設定ファイルをオペレーティングシステム別に指定する例が載っている。これは、宣言型の言語を使ってマシン別の設定を行うための重要なポイントだ。
マシンが2、3台あっても、Puppetサーバによってシステム設定の変更内容を各マシンにプッシュすれば、ソフトウェアのインストールや設定はそれほど大変ではなくなる。さらに、「/etc/puppet/manifests」ツリーをリビジョン管理システムで扱うようにすれば、ネットワーク上の全マシンの設定を正常に機能していた以前の状態にすばやく戻すことも可能だろう。
最終的にPuppetが成功を収めるかどうかは、どれだけ多くのシステム管理者がPuppetの言語を覚え、優れたコーディングによる質の高いレシピ（recipe）の作成に貢献して、ほかのユーザが管理の省力化のためにPuppetを利用する際の障壁をどれだけ低くしてくれるかにかかっている。
Ben Martinは10年以上もファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティングサービスを提供している。