GitLab CI/CD Practice Tests: 300 Questions

A security job runs in one pipeline but is absent from another. There is no failure log to inspect because the job never existed. Checking runner capacity may feel productive, but it is the wrong starting point for a configuration rule that excluded the job.

This course is built around that kind of pipeline reasoning. The tests help you connect configuration, triggering context, execution, and outputs, so you can distinguish an inclusion problem from a runner problem or a failing script. A green result matters more when you can explain how the pipeline reached it.

YAML topics cover reuse, inheritance, and variables. Pipeline topics connect stages, jobs, dependencies, conditions, and sources. Runner questions bring in scope, tags, executors, and the environment a job needs to run appropriately.

Cache and artifacts are treated as different promises: reusable inputs that improve performance versus outputs a downstream job may depend on. Environments and deployments add release controls and the relationship between the thing that was checked and the thing that is promoted.

The explanations encourage you to follow those relationships rather than repair the nearest visible symptom. An upstream variable, missing artifact, unsuitable runner, or unexpected pipeline source can all lead to different fixes. Learning where to look is as important as learning a valid line of configuration.

You get 6 practice tests, with 50 questions in each test (300 questions in total).

The course language is English, and the course level is Intermediate.

For developers, DevOps engineers, platform professionals, and CI/CD Associate candidates with basic GitLab and pipeline knowledge. It is a review resource, not a first YAML lesson or a hosted lab environment. A practice result should inform your study plan rather than stand in for official assessment guidance or hands-on validation.

A build produces a signed package that a deployment job must use unchanged. Dependency downloads should also be reused to improve build speed. How should the pipeline handle the two kinds of files?

Put both the signed package and downloaded dependencies into the same cache.
Pass the package as an artifact and cache the reusable dependency downloads.
Rebuild the package during deployment and keep its filename the same.
Commit the generated package to source so every later job can retrieve it.

Best answer: B. B preserves the producing job's required output while using cache for an optimization. A cache can be absent or replaced, so it is not the same handoff contract as the signed artifact. Rebuilding produces another object, and a matching filename does not establish that it is the one already checked. Committing generated outputs to source is not the intended pipeline handoff.

Illustrative public-page example, reworded for this edition; not a live examination item.

For a missed scenario, sketch which jobs should exist, where they should execute, and what each should receive and produce. Identify the first mismatch before choosing a fix. Review the exact syntax or behavior in current GitLab documentation, then try unfamiliar material. Pay particular attention to the cases that pass only because a warm cache or a convenient runner hides an assumption.

1 / 2

GitLab Certified CI/CD Associate: 6 Mock Exams

Start with the job that never appeared

Read the pipeline as a chain of decisions

Six mock exams covering pipelines, runners, artifacts and deployments.

Is this the right fit?

A sample of the reasoning

Predict the run before checking the answer

GitLab Certified CI/CD Associate: 6 Mock Exams

Cache or Artifact? Ask What Happens When the File Is Missing.

The GitLab Job Did Not Fail. It Was Never Created.

GitLab Certified Security Associate Practice Tests

GitLab Duo Agent Platform Associate Practice Tests

GitLab Agile Portfolio Management Associate: 6 Mock Tests