Puppet Certified Professional

The certifications page covers three tool- and cloud-agnostic exams that most DevOps engineers run into first. This page is narrower on purpose: it's the deep profile of Puppet's own vendor credential, for the specific reader who already runs — or is about to inherit — a large, long-lived fleet configured with Puppet. Below: what the credential actually is and who owns it today, what it has historically organized study material around, a format detail worth confirming before you pay for anything, and a direct map onto the Puppet tool page and configuration management lesson that already teach the substance behind it.

What it is, and who owns it now

☺ Like you're 10: It's Puppet's own badge for "I know this specific tool well," and the company handing it out changed hands a few years ago.

The Puppet Certified Professional credential is the vendor certification issued by Puppet — the company, not the open-source project's community fork activity — for demonstrated competency with the Puppet language and platform specifically. It is not a broad configuration-management credential the way this course's own lesson treats the discipline in vendor-neutral terms; it certifies one tool, the way the Terraform Associate certifies one tool rather than infrastructure as code as a field.

Puppet Inc. was acquired by Perforce Software in 2022, and that ownership change matters for anyone considering this exam, not just as trivia. Training and certification programs are exactly the kind of line item that quietly narrows, pauses, or gets rebuilt during a corporate ownership transition, and the open-source ecosystem around Puppet has been in visible motion since — including community-fork activity in response to licensing and investment shifts on some components, as covered on the Puppet tool page. None of that changes what the Puppet language itself does. It does mean you should not assume this page's description of the program's scope, price, or even current availability is still accurate by the time you read it — confirm directly on Perforce's Puppet site that the program is open for new registrations before you plan around it.

What the credential has historically organized study material around

☺ Like you're 10: Eight areas, all of them things you'd already need to know cold to run a real Puppet fleet without constantly guessing.

Puppet has not published the kind of stable, versioned, percentage-weighted domain breakdown the CNCF publishes for the CKA. What follows is a study-oriented reconstruction of the areas the credential has organized around, built from the Puppet language and platform's actual surface area — not a verbatim vendor list, and not a claim about current per-topic weighting. Cross-check against whatever Perforce currently publishes before you plan your prep around it.

1. Puppet language fundamentals — resource declarations, resource types and providers, arrays, hashes, selectors, conditionals (if/unless/case), and Puppet's own data types.
2. Classes, defined types, and modules — the difference between a class (declared once per node) and a defined type (instantiable many times), include versus resource-like class {} declaration, and the module directory layout Puppet discovers by convention.
3. Node classification and the roles & profiles pattern — site.pp, external node classifiers, and the community-standard design pattern that keeps a fleet's node definitions thin and its component logic reusable (see below).
4. Hiera and data separation — the hierarchy, automatic parameter lookup, merge behavior, and correctly predicting which value in a multi-level hierarchy wins for a given node.
5. Facts — core Facter facts, writing custom Ruby facts, and external facts, plus how facts flow into catalog compilation.
6. Ordering and relationships — the ->/~> chaining arrows and the before/require/notify/subscribe metaparameters, and why manifest order alone does not guarantee apply order.
7. Puppet Server, PuppetDB, and the agent lifecycle — the compile-and-apply cycle, certificate signing, and exported-resource collection between nodes.
8. Troubleshooting and reporting — reading an agent run report, and recognizing the classic failure modes: duplicate resource declarations, a single broken class failing an entire node's catalog compilation, an unguarded exec that isn't actually idempotent.

Every one of those eight areas is covered in working depth, with real manifest syntax and command output, on the Puppet tool page — if you've worked through that page already, none of this list should be unfamiliar.

# manifests/site.pp — thin, only assigns roles, never touches component modules directly
node /^web\d+\.acme\.internal$/ {
  include role::web_server
}

# site-modules/role/manifests/web_server.pp — describes what the node IS
class role::web_server {
  include profile::base
  include profile::nginx
  include profile::monitoring
}

# site-modules/profile/manifests/nginx.pp — YOUR organization's opinion of nginx
class profile::nginx {
  class { 'nginx':                    # the component module, e.g. from the Forge
    worker_processes => 8,
    service_ensure   => 'running',
  }
  nginx::vhost { 'acme-app': port => 8080 }
}

A typical scenario-style question built on this pattern hands you a Hiera hierarchy and a node's facts, then asks which value actually gets used — the kind of question that rewards understanding merge behavior over memorizing syntax:

# hiera.yaml — checked top to bottom, first match wins per key (unless the key uses a merge lookup)
hierarchy:
  - name: "Per-node"
    path: "nodes/%{trusted.certname}.yaml"
  - name: "Per datacenter"
    path: "datacenters/%{facts.datacenter}.yaml"
  - name: "Common"
    path: "common.yaml"

# data/common.yaml
profile::nginx::worker_processes: 4
# data/datacenters/us-east.yaml
profile::nginx::worker_processes: 8
# data/nodes/web03.acme.internal.yaml
# (no override for this key at all)

# Q: web03 has fact datacenter = "us-east". What value does profile::nginx::worker_processes resolve to?
# A: 8 — the per-node file is checked first but doesn't set this key, so Hiera falls through
#    to the next level in the hierarchy that DOES set it: per-datacenter. First MATCH wins,
#    not first FILE checked — a distinction the exam-style questions lean on directly.

Format: a detail worth confirming, not assuming

☺ Like you're 10: This course profiles two other exams that hand you a real broken machine and time you fixing it — this one, by most accounts, has instead handed candidates scenario questions to reason through, not a live terminal. Confirm which is true today before you register.

This course's other tool-specific credential profile, the Red Hat Ansible Automation Specialist, is 100% performance-based — real tasks against a live machine, graded on end state, the same philosophy as the CKA. Candidate reports and study material for Puppet's certification have generally described something different: primarily scenario-based multiple-choice and multiple-response questions, proctored online — given a manifest excerpt, a resource declaration, or a Hiera hierarchy like the one above, predict what the compiled catalog will contain, which value wins, or what order resources apply in, rather than typing commands into a live terminal yourself.

Treat that as a strong signal about the kind of preparation that pays off — reading manifests fluently and predicting outcomes, closer to the Terraform Associate's knowledge-based format than to the CKA's hands-on one — but not as a fact to plan a study schedule around without checking. Exam formats change between versions more often than course material gets updated to reflect it, and this is precisely the credential on this page where that gap is least likely to have been caught. Confirm the current format on Perforce's own Puppet certification page before you assume either way.

Where this fits: large, long-lived, Puppet-managed fleets

☺ Like you're 10: This credential only really matters if your actual job is keeping a big, old, Puppet-run fleet correct — it doesn't say much about you if that isn't the job.

The Puppet tool page makes the underlying case in full: Puppet's pull-based, agent-and-server architecture buys automatic, unattended drift correction on every run interval, at the fixed cost of running Puppet Server, PuppetDB, a PKI, and a persistent agent on every managed node. That tradeoff pays off specifically for a large, relatively stable fleet of long-lived hosts — bare metal, traditional VMs, an on-prem datacenter — where unnoticed configuration drift is the bigger risk than deploy latency. Banks, telcos, universities, and hosting providers running thousands of long-lived hosts are the classic Puppet shops, and this credential exists to validate the specific skill those shops actually need: reading and writing Puppet's language correctly, not configuration management in the abstract.

This is also where the credential's value is most conditional. Immutable infrastructure and golden images covers the broader industry shift toward disposable, replaced-not-reconciled hosts in cloud-native shops — infrastructure that Puppet's whole enforced-convergence model was never built to manage, because there's no long-lived host left to keep converging. If your fleet already looks like that, this specific badge tells a hiring manager very little about your actual day-to-day toolset, no matter how well it's earned.

The credential also intersects directly with continuous compliance: Compliance as Code & Policy Enforcement covers how Puppet's automatic, unattended reconciliation gets leaned on specifically to keep a regulated fleet provably in its declared state between audits, not just at deploy time — one of the strongest arguments for a large, compliance-driven shop to standardize on Puppet, and for that shop's engineers to have this credential's underlying knowledge validated one way or another.

Who should consider it, and who should skip it

☺ Like you're 10: Worth it if your servers already run on Puppet and probably will for years; a detour if your infrastructure gets rebuilt from scratch every deploy instead of patched in place.

Consider it if your organization already runs Puppet at fleet scale and plans to keep doing so — the credential validates exactly the skill gap that costs real money when it's missing: an engineer who can read a Hiera hierarchy correctly under pressure instead of guessing which value actually applied to production. It's a reasonable differentiator specifically inside Puppet-shop hiring pipelines, in the same way the Red Hat Ansible credential is a differentiator inside RHEL-and-Ansible shops — narrow, but exactly matched to a real, common job.

Consider skipping it if any of these fit. You're evaluating configuration-management tools rather than already committed to one — spend the time on the vendor-neutral configuration management lesson and Puppet versus Chef versus Ansible comparisons instead of a single-vendor badge. Your infrastructure is cloud-native and largely ephemeral — immutable, replace-don't-patch infrastructure doesn't need enforced convergence, and this credential won't reflect skills your job actually exercises. Or the program turns out, on checking, to be closed to new registrations — in that case, the domain list above and the Puppet tool page still teach the exact knowledge a large Puppet shop needs from you; you simply won't be able to put a badge on it.

Exam logistics — verify every one of these yourself

☺ Like you're 10: This is the table to double-check hardest on this whole page — price, format, and even whether you can register at all are all things this course cannot confirm with confidence right now.