Career upgrade: Learn practical AI skills for better jobs and higher pay.
Level up
All Practice Exams

100+ Free GitLab CI/CD Specialist Practice Questions

Pass your GitLab Certified CI/CD Specialist exam on the first try — instant access, no signup required.

✓ No registration✓ No credit card✓ No hidden fees✓ Start practicing immediately
100+ Questions
100% Free
1 / 100
Question 1
Score: 0/0

In .gitlab-ci.yml, which block allows you to run commands before every job in the pipeline without repeating them in each job?

A
B
C
D
to track
Same family resources

Explore More GitLab Certifications

Continue into nearby exams from the same family. Each card keeps practice questions, study guides, flashcards, videos, and articles in one place.

2026 Statistics

Key Facts: GitLab CI/CD Specialist Exam

80%

Passing Score (Both Parts)

GitLab University

~2 hours

Total Exam Time

GitLab University (~1h written + ~1h lab)

$650

Exam Fee

GitLab Professional Services

2 years

Validity

GitLab University

40-60 hrs

Study Time

Recommended

2 parts

Written + Hands-On Lab

GitLab University

The GitLab CI/CD Specialist requires 80% on both a 1-hour written assessment and a 1-hour hands-on lab graded by GitLab engineers. The fee is $650 USD and the credential is valid for 2 years. Preparation typically takes 40-60 hours and must include practical .gitlab-ci.yml writing, runner configuration, DAG pipeline design, and security scanning template usage.

Sample GitLab CI/CD Specialist Practice Questions

Try these sample questions to test your GitLab CI/CD Specialist exam readiness. Each question includes a detailed explanation. Start the interactive quiz above for the full 100+ question experience with AI tutoring.

1Which keyword in .gitlab-ci.yml defines the list of pipeline stages in order?
A.jobs
B.stages
C.pipeline
D.workflow
Explanation: The `stages` keyword at the top level of .gitlab-ci.yml defines the ordered list of stages that jobs are grouped into. Jobs in the same stage run in parallel, and stages run sequentially by default. The `workflow` keyword controls whether a pipeline runs at all, not stage order.
2In .gitlab-ci.yml, which keyword specifies the Docker image to use for a job?
A.runner
B.container
C.image
D.docker
Explanation: The `image` keyword specifies the Docker image the job runs in. It can be set globally for all jobs or overridden per job. The `runner` keyword does not exist in .gitlab-ci.yml syntax; runners are configured server-side.
3A job must run after another job in the same stage without waiting for the entire previous stage to finish. Which keyword enables this direct dependency?
A.depends_on
B.needs
C.requires
D.after
Explanation: The `needs` keyword implements a Directed Acyclic Graph (DAG) in GitLab CI/CD, allowing a job to start as soon as its explicitly listed upstream jobs complete, bypassing the normal stage ordering. This reduces total pipeline time when not all jobs in a stage need to complete first.
4Which executor type allows a GitLab runner to spin up a new Docker container for every CI job?
A.shell
B.docker
C.kubernetes
D.virtualbox
Explanation: The `docker` executor launches an isolated Docker container for each job, providing clean environments and easy dependency management via the `image` keyword. The `shell` executor runs jobs directly on the host OS, while `kubernetes` creates pods in a Kubernetes cluster.
5You want to pass build outputs from a build job to a test job in the next stage. Which configuration block achieves this?
A.cache
B.artifacts
C.variables
D.dependencies
Explanation: The `artifacts` block uploads files or directories to GitLab after a job finishes, making them available to later-stage jobs automatically (or via `dependencies`). The `cache` keyword is for speeding up repeated builds by caching directories like vendor packages, not for passing build outputs between jobs.
6A developer wants a pipeline job to only run on the `main` branch and not on feature branches. Which `rules` condition achieves this?
A.rules: - if: '$CI_COMMIT_BRANCH == "main"'
B.rules: - when: main
C.only: [main]
D.filter: branch: main
Explanation: The modern `rules` keyword accepts `if` conditions using CI/CD variable expressions. `$CI_COMMIT_BRANCH == "main"` evaluates to true only on the main branch. While `only: [main]` is older syntax that also works, the question asks for a `rules` condition specifically, making option 0 correct.
7Which predefined CI/CD variable contains the full SHA of the commit that triggered the pipeline?
A.$CI_PIPELINE_ID
B.$CI_COMMIT_SHA
C.$CI_BUILD_ID
D.$CI_COMMIT_REF
Explanation: $CI_COMMIT_SHA contains the full 40-character SHA-1 hash of the commit triggering the pipeline. $CI_PIPELINE_ID is the numeric pipeline ID, not the commit SHA. $CI_COMMIT_REF_NAME contains the branch or tag name, and $CI_BUILD_ID is a legacy alias for the job ID.
8A CI/CD variable set at the project level has the same name as one defined in .gitlab-ci.yml. Which value takes precedence?
A.The .gitlab-ci.yml variable always wins
B.The project-level variable always wins
C.The .gitlab-ci.yml variable overrides project-level variables
D.They are merged and both values are available
Explanation: In GitLab CI/CD variable precedence, variables defined in .gitlab-ci.yml (job-level or global) override project-level variables set in the UI or API when they share the same name. This allows .gitlab-ci.yml to customize or override project defaults on a per-job or pipeline basis.
9You define a variable in GitLab project settings and check the 'Masked' option. What is the primary effect?
A.The variable is encrypted at rest in the database
B.The variable value is hidden from job logs
C.The variable is only available to protected branches
D.The variable cannot be overridden in .gitlab-ci.yml
Explanation: Masking a CI/CD variable prevents its value from appearing in job logs by replacing any occurrence with `[MASKED]`. It does not encrypt the variable at rest (that uses GitLab's secrets vault) and does not restrict it to protected branches — that is a separate 'Protected' flag.
10In .gitlab-ci.yml, which `cache:policy` value tells a job to download the cache at start but NOT upload it at the end?
A.read-write
B.pull
C.push
D.skip
Explanation: Setting `cache: policy: pull` causes the job to download (pull) the cache at startup but skip uploading it at the end, saving time when the job does not modify cached files. The default `pull-push` both downloads and uploads. The `push` policy only uploads.

About the GitLab CI/CD Specialist Exam

The GitLab Certified CI/CD Specialist validates intermediate-to-advanced ability to configure, optimize, and troubleshoot GitLab CI/CD pipelines. The two-part exam covers .gitlab-ci.yml syntax (stages, rules, needs/DAG, includes, templates, CI/CD Components), runner configuration (executors, tags, config.toml), artifact and cache management, environment and deployment workflows (review apps, protected environments, deployment freeze windows), CI/CD variable scoping and protection, pipeline security (SAST/DAST/Dependency/Secret Detection), and advanced pipeline patterns (parent-child, multi-project, dynamic child pipelines). The hands-on lab is evaluated by GitLab Professional Services engineers.

Questions

60 scored questions

Time Limit

~1 hour written + ~1 hour hands-on lab

Passing Score

80% on both parts

Exam Fee

$650 (GitLab University / Professional Services)

GitLab CI/CD Specialist Exam Content Outline

25%

Pipeline Syntax & Fundamentals

.gitlab-ci.yml structure, stages/jobs, image/services, default block, extends/hidden jobs, YAML anchors/!reference, before_script/after_script, allow_failure/retry/timeout/parallel/interruptible, [ci skip]

15%

Runners & Executors

Runner scopes (shared/group/project), executors (shell/docker/kubernetes), runner tags, concurrent, config.toml, privileged/dind, GIT_STRATEGY/GIT_DEPTH/GIT_SUBMODULE_STRATEGY, Windows shell

15%

Rules, Conditions & Workflow

rules vs only/except, workflow:rules, when values, rules:if/changes/exists, $CI_PIPELINE_SOURCE, pipeline deduplication, [ci skip], manual/delayed jobs

15%

Artifacts & Caching

artifacts paths/reports/expire_in/when/untracked, dependencies, cache key/policy/untracked/key:files, JUnit/coverage_report/SAST/DAST/cobertura report types, cross-pipeline artifacts

10%

CI/CD Variables

Predefined variables, variable scopes (project/group/instance), masked/protected flags, environment scope, variable precedence, $CI_JOB_TOKEN, $CI_COMMIT_SHA/$CI_COMMIT_SHORT_SHA, inherit:variables

10%

Environments & Deployments

environment name/url/action/on_stop, review apps, resource_group, GitLab Releases, GitLab Pages, protected environments with approvals, deployment freeze windows, $CI_ENVIRONMENT_URL

10%

Advanced Pipelines & Security

DAG with needs, parent-child/multi-project pipelines, trigger (strategy:depend/forward:), dynamic child pipelines, includes, CI/CD Components & Catalog, SAST/DAST/Dependency/Secret Detection, Auto DevOps

How to Pass the GitLab CI/CD Specialist Exam

What You Need to Know

  • Passing score: 80% on both parts
  • Exam length: 60 questions
  • Time limit: ~1 hour written + ~1 hour hands-on lab
  • Exam fee: $650

Keys to Passing

  • Complete 500+ practice questions
  • Score 80%+ consistently before scheduling
  • Focus on highest-weighted sections
  • Use our AI tutor for tough concepts

GitLab CI/CD Specialist Study Tips from Top Performers

1Write real .gitlab-ci.yml files in a personal GitLab project for every topic — the hands-on lab requires practical skill, not just memorization
2Master the `rules` keyword thoroughly: learn the difference from `only/except`, understand short-circuit evaluation, and practice $CI_PIPELINE_SOURCE conditions
3Build DAG pipelines using `needs:` to understand how jobs fan-out and fan-in across stages; practice with `artifacts: false` on needs entries
4Practice parent-child and multi-project pipeline patterns: `trigger: include:` for child pipelines, `trigger: project:` for multi-project, and `strategy: depend`
5Know all variable scopes and precedence: .gitlab-ci.yml job variables override global variables, which override project-level, which override group-level
6Include every security template (`SAST.gitlab-ci.yml`, `Dependency-Scanning.gitlab-ci.yml`, `DAST.gitlab-ci.yml`, `Secret-Detection.gitlab-ci.yml`) in a test project to see the jobs they add
7Practice `cache: key: files:` patterns for Node.js (package-lock.json) and understand when cache invalidates vs when it reuses
8Understand environment deployment workflows: review apps with dynamic URLs, `environment: on_stop:` with `action: stop`, and protected environment approval gates

Frequently Asked Questions

What is the GitLab CI/CD Specialist exam format?

The GitLab CI/CD Specialist certification consists of two parts: a 1-hour written assessment (multiple choice, minimum 80% to pass) and a 1-hour hands-on lab assessment graded by GitLab Professional Services engineers (also minimum 80% to pass). Both parts must be passed to earn the certification. The exam fee is $650 USD.

What is the difference between the GitLab CI/CD Associate and CI/CD Specialist certifications?

The CI/CD Associate covers foundational topics like basic .gitlab-ci.yml syntax, simple pipelines, runners, variables, and job artifacts — primarily tested through a written exam. The CI/CD Specialist is an intermediate credential that adds advanced topics (DAG/needs, parent-child pipelines, CI/CD Components, security scanning templates, protected environments) and includes a hands-on lab where engineers evaluate your practical pipeline-building skills. The Specialist costs significantly more ($650 vs ~$650 for professional services tier).

What topics does the GitLab CI/CD Specialist hands-on lab cover?

The hands-on lab tests practical ability to write .gitlab-ci.yml files from scratch, configure runners, implement DAG pipelines with `needs:`, set up review apps, configure protected environments, use security scanning templates, and debug pipeline failures. GitLab Professional Services engineers grade the lab submissions against defined rubrics.

How long should I study for the GitLab CI/CD Specialist exam?

Most candidates with existing GitLab CI/CD experience study for 4-8 weeks (40-60 hours). Allocate roughly 40% of time to hands-on .gitlab-ci.yml practice in a real GitLab project, 30% to reading GitLab CI/CD documentation and the official learning path, and 30% to timed practice questions. Focus on DAG pipelines, rules syntax, artifact reports, and security scanning templates.

What are CI/CD Components in GitLab, and do they appear on the Specialist exam?

GitLab CI/CD Components are reusable, versioned pipeline configuration units stored in dedicated repositories and discoverable via the CI/CD Catalog. You include them using `include: component: hostname/namespace/project/component@version`. They are included in the CI/CD Specialist curriculum as part of the advanced pipelines and reusability topics.

Is the GitLab CI/CD Specialist exam available remotely?

Yes, the GitLab CI/CD Specialist exam (both written and hands-on lab) is available remotely through GitLab University. The written assessment is online-proctored. The hands-on lab is submitted remotely and evaluated asynchronously by GitLab Professional Services engineers. Check university.gitlab.com for current scheduling availability.