GitLab Certifications

GitLab sells one product that tries to be the whole toolchain — repository, issue tracker, pipeline, registry, scanner, agent — and it sells five exams to match. All five are Associate level, all five were rebuilt in the 2025–26 refresh, and one of them, the Certified CI/CD Associate, sits directly on top of the layer this site cares about most: how code becomes an artifact and how that artifact reaches a cluster. This page is what GitLab’s own pages say today — the exact content-outline percentages, the real logistics, the exams that were quietly retired or renamed, and the hands-on lab GitLab deleted along the way. It also tells you, plainly, when to keep the $150.

What these credentials are and where they sit

☺ Like you’re 10: Five quizzes, one company, one product. Every one of them is the same length and the same price.

None of this is a CNCF credential and none of it is neutral. These are vendor certifications about a specific hosted product, in the same sense that the AWS DevOps Professional is an exam about Amazon. That is not an insult — the SCM-and-CI layer is where a platform’s delivery story starts, and the instincts you pick up (declarative pipelines, versioned reusable units, ephemeral credentials, scanning as a job) transfer even when the YAML does not. It just means you should know exactly which part you are renting.

The programme lives on GitLab University (university.gitlab.com/pages/certifications), which is also where you buy the exam. Every one of the five is an exam-based credential: you purchase a registration, you sit 50 questions, you pass or you do not. The learning paths GitLab recommends alongside them are free, self-paced and entirely optional — you are never buying a course. Separately, GitLab Education Services sells instructor-led classes (the CI/CD one is a four-hour session), but no class is a prerequisite and no class includes the exam.

The five live certifications

These are the five listed on the public certifications page, in GitLab’s own words, with GitLab’s own recommendation to start at Fundamentals. There is nothing above Associate that you can book.

One label worth noticing, because it is not on the marketing page: open any of the five exam pages and the Details tab reads Category: Foundational. GitLab is telling you what it thinks these are. Read that before you plan a career around one.

The Professional tier that exists only on paper

GitLab’s Certification Program Candidate Handbook & Exam Guide (document version 1.1, last updated 8 October 2025) describes a two-level ladder. Associate: 75 minutes, 50 questions, unproctored online, no prerequisites, 3–6 months’ hands-on experience recommended. Professional: 90 minutes, 60 questions, proctored online and scheduled through Certiverse, Associate recommended first, 1–2 years’ experience, also $150. It sounds like the answer to every complaint on this page.

It is not bookable. The public catalogue lists exactly five certification exams and every one of them is Associate. Treat Professional as announced structure — a shape GitLab has reserved in its policy documents — rather than something you can plan around. If it ships, it is the version of this credential worth having.

The rebuild deleted the interesting half

This is the change nobody advertises, and you can still read both versions side by side. The legacy CI/CD exam page describes the old deal: a 15-question written assessment at 80% to pass, retakeable an unlimited number of times, plus a hands-on lab submitted through a dedicated GitLab Demo Cloud, graded by a GitLab team member, results within seven business days, with twelve months to submit. The current page describes the new one: 50 questions, 75%, two attempts, fourteen days, and no lab at all.

Trade honestly. The new exam has far better coverage — a published outline with percentages, a real topic list, immediate results — and the old one was slow and inconsistently graded. But the thing that made a GitLab badge mean something to a hiring manager was that a human looked at a project you built. That is gone. What remains is a 50-question recall test you take alone in your own room. GitLab’s exam terms (last updated 17 October 2025) still contemplate “exams with hands-on components” that “are individually reviewed and may take up to seven (7) business days for results” — a hook left in the contract for a format that no longer ships. Maybe it comes back with Professional.

Why a platform engineer takes one — and when to skip

☺ Like you’re 10: Worth it if your company runs GitLab and you build pipelines for other people. Not worth it if you already do that every day.

The case for is narrow but real. On this site, CI is the half of delivery that pushes — it builds, tests, scans, signs and publishes — and CD is the half that pulls (see GitOps Workflows). Most platform teams own the push half as a product: golden pipeline templates, a runner fleet, a policy about what a team is allowed to include:. The CI/CD Associate outline is the only structured revision map GitLab publishes for that layer, and its five validated tasks are a decent checklist even if you never book the exam. The Security Associate is the better buy if scanning, policies and merge-request approval gates are genuinely yours.

The honest case against

Four situations where you should not do this. You already author pipelines weekly — this is a recall exam about a product you use all day, and your merge requests are better evidence than a badge. Your platform standardised on the other vendor, or on Tekton / Argo Workflows running in-cluster — then this is vendor-locked knowledge with a low transfer rate, and the GitHub exams are the ones to read about instead. You are choosing between this and a CNCF exam — the CNPA and the performance-based CNPE map onto the whole discipline rather than one company’s YAML dialect, and a hands-on exam proves something a multiple-choice paper structurally cannot. You want Fundamentals to “get started” — it is genuinely introductory, GitLab labels it Foundational, and the free learning path covers it without the $150.

One calibration nobody selling a practice course will give you: these exams are online and unproctored. Fifty questions, in your own room, with nobody watching. GitLab’s code of conduct forbids notes, reference material and AI assistance, and it reserves the right to investigate with “statistical analysis, data forensics, and other detection methods” — but the format is honour-system, and experienced hiring managers know it. That makes a GitLab badge a weaker market signal than a proctored exam such as GitHub’s GH- series, which is proctored and delivered through Pearson VUE, and far weaker than a performance-based exam where you either fixed the cluster or you did not. Take the GitLab exam because the outline is a good revision map. Do not take it because the badge will move anyone.

What they actually test — the official content outlines

☺ Like you’re 10: GitLab tells you exactly how much of the quiz each topic is worth. Not a range — an exact number, and they add up to 100.

This is unusually good vendor behaviour and you should use it. Every exam page has a Preparation tab carrying a content outline with exact percentages, plus a long non-exhaustive topic list. If a course sells you different percentages, the course invented them. Here is the CI/CD Associate outline, transcribed from its official page.

Read that twice before you buy. Over half the paper — YAML Configuration, Pipeline Development and CI/CD Fundamentals, 58% together — is authoring, the part you can learn free from the reference docs in a weekend. Runner Configuration, the domain a platform engineer actually lives in, is 8%, tied with Security Integration for the smallest slice. That is the honest shape of this exam: it certifies pipeline authors, not runner-fleet operators.

The same page publishes five validated tasks, which are a better revision checklist than the percentages: create and configure .gitlab-ci.yml files with proper YAML syntax, variables, artifacts and caching strategies; install, configure and manage GitLab Runners across different environments and executors; build and manage container images and packages using GitLab’s integrated registries; implement security scanning tools within CI/CD workflows and interpret vulnerability reports; and diagnose pipeline failures and optimise performance.

Security Associate — eleven domains, no domain larger than 16%

The Security Associate is the most fragmented outline of the five, which tells you something about the exam: it is a tour of every scanner GitLab ships rather than a deep dive into any of them.

The other three, in one glance

Where the outlines are already drifting from the product

Content outlines age faster than products. Three places where GitLab’s exam pages and GitLab’s docs already disagree, all checkable in a minute:

• “Shared” runners are called instance runners now. The CI/CD topic list says “GitLab Runner types (shared, group, project-specific)”; the runner scope documentation says instance runners, group runners and project runners. Learn both words — the exam may still use the old one.
• The executors named are not the executors GitLab develops. The topic list names “Docker, shell, Kubernetes”. Per the executors documentation, shell is in maintenance mode — critical security updates only, no new features — alongside SSH, VirtualBox, Parallels and Custom, and Docker Machine is deprecated. The two GitLab actively points you at for autoscaling, Docker Autoscaler and Instance, appear in no outline at all.
• Dependency scanning has been rebuilt underneath the exam. Per GitLab’s dependency scanning docs, “dependency scanning based on the Gemnasium analyzer is deprecated in GitLab 17.9 and proposed for removal in GitLab 20.0”; the recommended path is now the SBOM-based analyzer via Jobs/Dependency-Scanning.v2.gitlab-ci.yml, generally available in GitLab 19.0. Any practice question that teaches you the old template is teaching you a path with a removal date on it.

And one hole that matters more than all three: no outline mentions GitOps or Flux, even though GitLab’s own documentation has prioritised Flux for GitOps since GitLab 16.1. The exam stops exactly where the interesting part of delivery begins.

The substance you actually need

☺ Like you’re 10: Write the recipe once and version it, never store a permanent key, let the scanner run itself, and know where your jobs actually live.

Strip out the product tour and the exam rewards four instincts, all of which survive a change of employer: don’t repeat yourself (components from the CI/CD Catalog, not copy-pasted YAML), don’t hold long-lived credentials (id_tokens), make the graph explicit (needs:, not “the previous stage”), and let policy enable scanning rather than trusting every project to include the template. Here is a pipeline that does all four.

include:
  # A versioned CI/CD component from the Catalog — the reuse primitive.
  # Reference format: <fqdn>/<project-path>/<component-name>@<version>
  - component: $CI_SERVER_FQDN/acme/platform-ci/go-build@1.4.0
    inputs:
      go_version: "1.24"
  - template: Jobs/SAST.gitlab-ci.yml                 # static analysis
  - template: Jobs/Secret-Detection.gitlab-ci.yml     # pipeline secret detection
  - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml   # SBOM-based; the v1 Gemnasium
                                                          # path is deprecated since 17.9

stages: [ test, build, release ]

variables:
  IMAGE: $CI_REGISTRY_IMAGE            # the project's built-in container registry

unit-tests:
  stage: test
  cache:
    key: { files: [ go.sum ] }         # cache keyed on the lockfile, not the branch
    paths: [ .gocache/ ]
  script: [ "go test ./... -race" ]
  artifacts:
    reports: { junit: report.xml }     # a *report* artifact — parsed and shown in the MR,
                                       # unlike `paths:`, which is just files to download

build-image:
  stage: build
  needs: [ unit-tests ]                # DAG edge — starts the moment tests pass, not
                                       # when every job in the stage finishes
  id_tokens:
    AWS_TOKEN:                         # OIDC JWT minted per job; no static cloud keys
      aud: https://gitlab.example.com  # audience the cloud provider will check
  script:
    - docker build -t "$IMAGE:$CI_COMMIT_SHA" .
    - docker push "$IMAGE:$CI_COMMIT_SHA"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # rules:, not the legacy only/except
      when: on_success
    - when: never

Five things the exam — and production — care about in that file. A component is versioned and resolved from the Catalog by a fully-qualified reference, which is why it is a platform product and a copied .gitlab-ci.yml is not. needs: turns stages into a directed acyclic graph, and knowing the difference between “stage order” and “dependency order” is worth marks and worth minutes of pipeline time. artifacts:reports: is not the same keyword as artifacts:paths: — reports get parsed and surfaced in the merge request, which is the entire mechanism behind security findings appearing in a review. rules: replaced only/except, and any tutorial still teaching the latter is old. And id_tokens is the highest-value line on the page: it deletes your long-lived cloud secrets, exactly as id-token: write does on the GitHub side. Same idea, different noun — which is the honest summary of what transfers between the two vendors.

Runners: the 8% that is 80% of the job

Runners are where GitLab candidates lose marks and where platform teams lose money. A runner is a separate agent process you install, register and scale yourself. Its executor decides where the job body actually runs. Its scope — instance, group or project — decides who may consume it, which is the same governance problem as GitHub’s runner groups. And since GitLab 17.0 the legacy registration-token workflow can be switched off entirely: you create the runner first and register it with an authentication token, prefixed glrt-.

# /etc/gitlab-runner/config.toml — one runner process, Kubernetes executor.
concurrent = 30          # global: total jobs across every [[runners]] block here
check_interval = 3       # global: seconds between polls for new jobs

[[runners]]
  name = "platform-k8s"
  url = "https://gitlab.example.com/"
  token = "glrt-REDACTED"          # runner authentication token, not a registration token
  executor = "kubernetes"

  [runners.kubernetes]
    namespace = "gitlab-runner"    # one pod per job lands here
    poll_timeout = 600             # how long to wait for a pod to become ready
    cpu_request = "500m"
    memory_request = "1Gi"
    service_account = "gitlab-runner-jobs"   # the identity your jobs run as — audit this

  [runners.cache]
    Type   = "s3"
    Shared = true                  # one cache shared across runners, not per-machine
    [runners.cache.s3]
      BucketName         = "acme-runner-cache"
      ServerAddress      = "s3.amazonaws.com"
      AuthenticationType = "iam"   # or "access-key" — prefer the instance role

On a Kubernetes substrate the Kubernetes executor spawns a pod per job, which is why runner capacity is simultaneously a scaling and scheduling problem, a FinOps problem and a security-boundary problem — that service_account line is a bigger deal than the exam suggests. If autoscaling on VMs is your world, Docker Autoscaler and Instance are the executors to learn; anything that teaches autoscaling via Docker Machine is teaching a deprecated path.

Where CI stops and CD begins

The exam will happily let you believe the pipeline should deploy. On this site it does not. CI pushes; CD pulls. Your pipeline builds, scans, signs and publishes an image, then makes one small commit to the config repo — and a reconciler inside the cluster notices and converges. The pipeline never holds cluster credentials. This is not a fringe opinion: GitLab’s own GitOps documentation has prioritised Flux since GitLab 16.1 and says plainly that you should use both Flux and agentk — “Flux keeps the cluster state synchronized with the source, while agentk simplifies the Flux setup, provides cluster-to-GitLab access management, and visualizes the cluster state in the GitLab UI.” The agent manages access and visibility; it is not the thing doing the applying.

None of that is on any of the five exams. If you want it, it is here: GitOps Workflows, Flux, Argo CD, and the GitOps lab where you build the loop yourself.

How it maps onto the CNPE and this site

☺ Like you’re 10: Nearly every quiz topic is already a page here, just written with different words.

One gap worth naming out loud: since the rebuild there is no hands-on component on any GitLab exam, so nothing on it demonstrates that you can build. The nearest equivalents here are the CI/CD lab and the GitOps lab — do those alongside, not instead of, the reading.

Exam logistics — verify before you book

☺ Like you’re 10: Fifty questions, seventy-five minutes, nobody watching, $150, and it expires in fourteen days whether you sit it or not.

All of this comes from GitLab’s own exam pages, its Candidate Handbook, its exam terms and conditions, and the GitLab University FAQ as of writing. The five exams share every one of these numbers.

The two lines to read twice are the ones that cost people money: purchases are final, and access dies 14 days after purchase regardless of whether you sat the exam. Do not buy until the date is in your diary and the week around it is clear. Registration itself is now simpler than it used to be — GitLab University has its own email-and-password login and no longer requires a GitLab.com account to enrol, though you still need one for the free lab environments.

Official pages to verify against: GitLab Certifications, the CI/CD Associate and Security Associate exam pages, the Candidate Handbook & Exam Guide, and the FAQ.

Verdict — where it fits in a realistic order

☺ Like you’re 10: Take it only if your company runs GitLab, take it second or third, and never let it stand in for a hands-on exam.

A defensible order for a platform engineer: get genuinely comfortable with Kubernetes first, because every other page here assumes it. Then, if and only if your employer runs GitLab, take one of these — the CI/CD Associate if you build pipelines for other teams, the Security Associate if scanning and policy are yours. Do not take both; the overlap is large and the second badge adds nothing. Then spend the real effort and the real money on the performance-based CNPE, which asks you to build rather than to recognise. If the gap you are closing is cloud-shaped rather than pipeline-shaped, Terraform Associate or AWS DevOps Professional covers that ground far better than any GitLab exam will.

Three calibrations to close on. First, the transfer rate between GitLab CI and GitHub Actions is much lower than the marketing suggests — reusable workflow becomes CI component, runner group becomes group runner, id-token: write becomes id_tokens — so take the exam for the platform you actually run, not the one you might join. Second, this is an unproctored, 50-question recall test with no lab: a structured reading list with a badge attached, and a hiring manager who reads it as proof you can operate a runner fleet is making a mistake the outline itself contradicts at 8%. Third, the ground keeps moving: GitLab retired two exams, demoted a third from Specialist to Associate, deleted the hands-on lab, changed the login, and left a Professional tier sitting in its handbook with no exam behind it. Learn the ideas — versioned reuse, ephemeral credentials, explicit dependency graphs, scanning as policy rather than etiquette, and the push/pull split — because those survive every rebuild. Rent the badge, which does not. Then head back to the certifications hub to see how this sits beside GitHub, Terraform and the SRE-practice credentials.