7.1. Exam Strategy
That works out to roughly 100 to 150 seconds per question, depending on the length of the paper you draw. That's generous for a recall item and tight for a long scenario or an interactive one, so the strategy is triage rather than uniform pacing. Read every question's last sentence first — it states what's actually being asked, and it will often reveal that three-quarters of the scenario text is irrelevant context. Then read the stem for the constraints that discriminate between options: which trigger, which scope, which runner, whose credentials.
Flag and return. The exam interface lets you mark a question for review and come back. Use it aggressively on anything that takes more than about two minutes on first read. Candidates who fail on time almost always lost it to three or four questions they refused to leave. A flagged question you return to with ten minutes left is a question you answer with a clear head; a question you grind on at minute 20 costs you two easy ones at the end.
Multi-select discipline. When a question says "select two" or "select three," the count is a gift — it tells you exactly how many options survive. Eliminate first: options referencing deprecated syntax (::set-output), impossible combinations (Docker action on Windows, composite action with runs-on), or mechanisms that don't exist (cross-file YAML anchors, reading a secret's value back from the API) are wrong regardless of the scenario. There is no penalty for a wrong answer, so never leave one blank.
Interactive items. The exam policy states you may have interactive components, and GitHub publishes a sandbox so you can meet the formats before exam day. Expect to be asked to produce something rather than only recognize it: order a set of steps, complete a YAML fragment, match items to categories, or type a command. Read what the item asks you to build, and check the exact spelling of any command, key, or variable name you enter — these are graded on the artifact, not on recognition.
Scenario items attach a situation to the question. Read it once carefully, noting the stated constraints — compliance requirements, existing runner fleet, repository visibility — then answer against those constraints rather than against best practice in the abstract. The exam frequently rewards the answer that fits the stated environment over the theoretically ideal one.
Reasoning patterns that pay. Decompose every scenario into the Phase 1 chain — event, workflow, job, runner — and identify which link is being tested. When two options both look defensible, ask which one the stated requirement demands: "updates must propagate automatically" eliminates starter workflows; "must run on Windows" eliminates Docker actions; "must not store credentials" points at OIDC; "must require approval" points at environments. When a question describes a failure, classify it before choosing — trigger, resolution, permission, secret scope, or code.
Booking readiness. Aim for consistent 80%+ on practice material before scheduling, with no domain below 70%. Because the exam was substantially revised in January 2026, verify that any practice source post-dates that revision — older banks omit YAML anchors, immutable actions, OIDC, attestations, and service containers entirely, which is a meaningful share of the current blueprint.
