Track

Buildkite Platform Engineer

Currently examining version 1.0.0.

This track is not yet open for attempts. The objectives below describe the exam being built; they are published early so the learning modules and the exam can be reviewed against the same document.

What this credential attests

The holder can stand up and operate Buildkite for an organisation: size and target agent capacity, keep secrets out of pipelines, constrain what pipelines are allowed to do, and diagnose a slow platform correctly rather than by reflex.

It is not a pipeline-authoring credential — that is Pipeline Author, and it is assumed knowledge here.

Format

Not a written exam. Each task is performed in a Buildkite organisation you control and verified against the Buildkite API: that the build was created by you, inside the attempt window, carrying the attempt’s meta-data key, and exhibiting the behaviour the task asked for.

This is deliberate. Someone can describe queue targeting correctly and still misconfigure it. See what a credential attests.

Objectives

1. Clusters, queues and targeting

The cluster → queue → agent hierarchy, and what each layer is for
Assigning a self-hosted agent to a queue with --tags "queue=...", and the constraint that an agent belongs to one self-hosted queue within a cluster
Targeting a queue from a pipeline with the agents attribute, at the pipeline root and on individual steps, and which wins
Choosing queue boundaries: by platform, by cost, by trust level
Buildkite-hosted versus self-hosted agents, and when each applies

2. Capacity and agent operation

What actually determines how many jobs can run at once
Distinguishing a capacity shortage from a concurrency gate from a human approval — three causes with identical symptoms
Agent lifecycle: connection, job polling, disconnection, and what a lost agent does to a job
Autoscaling signals, and why scaling on queue depth alone misleads

3. Secrets and agent security

Why secrets belong in a dedicated secrets service — AWS Secrets Manager, GCP Secrets, HashiCorp Vault — rather than in Buildkite
The agent environment hook as the fallback, and scoping it with conditional logic on pipeline slug and step key so a secret is not exported to every job
Agent token handling, including expiry
Why a secret in pipeline YAML is a secret in your git history

4. Pipeline governance

Restricting plugins with the agent’s allowed-plugins setting: a comma-separated list of regular expressions checked before a job runs, with shorthand references expanded first
no-plugins for agents that should run none at all
Version-pinning plugins, and the supply-chain reasoning behind it
Pipeline signing and verification, and what tampering it detects

5. Access control and auditability

Teams and pipeline-level permissions
SSO and 2FA enforcement for organisation access
The audit log: what it captures and what questions it answers
Fork builds on public pipelines, and why they are a distinct risk

6. Diagnosing the platform

Reading a build’s anatomy: where the time actually went
Separating queue wait from job runtime from approval latency
Recognising when a metric is measuring a person rather than the platform
Cost signals: cancelled-build waste, over-broad artifact globs, retry spend

Preparing

The Platform Engineer modules cover these objectives. The hands-on units use the same mechanism as the exam, so working through them is genuine preparation rather than adjacent reading.

Modules

Modules are associated with this credential rather than owned by it — each can be completed on its own, and can count toward more than one.

Recommended alongside

Assumed knowledge, but never required or gated.