Free GitLab Certified CI/CD Associate practice test: 30 questions with answers

Rules are read from top to bottom and the first rule that matches decides the outcome. The schedule matches the first rule, which sets when: never, so the job is dropped and the second rule is never reached. A rule without a when key does not make a job manual, and scheduled pipelines do not change allow_failure on their own.

Job names that begin with a period are hidden jobs, so GitLab never runs them, while extends and !reference can still read them. An underscore has no special meaning in CI/CD, and template: true and a templates key are not recognised keywords.

Artifacts carry job outputs to later jobs and can be downloaded, while the cache stores dependencies for speed and a cache miss is always possible. Because a cache can be missing, it should not carry build output to a deploy job, and artifacts are never restored from the cache.

Artifacts are the mechanism for passing files produced by one job to later jobs in the same pipeline. A cache is for reusable dependencies and is not guaranteed to be present, a variable only stores text, and dependencies expects job names rather than file paths.

A cache key built from key files changes only when the listed file changes, so the dependency cache is reused until the lock file is updated. A pipeline-ID key creates a new cache on every run, and artifacts are meant for passing outputs between jobs rather than reusing dependencies across pipelines.

The needs keyword creates a dependency edge in the pipeline graph, so the deploy job starts once the listed job has succeeded. The dependencies keyword only controls which artifacts are downloaded, parallel splits a job into copies, and extends copies configuration, so none of them change when a job starts.

The retry keyword accepts a max count and a when list, and runner_system_failure matches failures caused by the runner, so script failures are not retried. A plain retry value retries every failure, a longer timeout does not recover a crashed runner, and allow_failure hides the failure rather than retrying it.

The trigger keyword can include a generated configuration file from an artifact, and strategy depend makes the trigger job wait for and mirror the child pipeline's status. Child pipelines are separate pipelines with their own configuration and stages, so they are not limited to the parent's file or stage list.

Without needs, a job waits until all jobs in earlier stages have completed successfully before it starts. Stage ordering is the default behaviour, so the job does not start after only the first build job, and no approval is required.

With auto-cancel redundant pipelines turned on, a newer pipeline on the same ref cancels older running pipelines, but only jobs marked interruptible: true are cancelled this way. Manual approval uses a manual job, restarts after connection loss are a retry matter, and failing without failing the pipeline is the allow_failure keyword.

Continuous delivery keeps the mainline releasable at all times, and a person decides when production gets the change. Continuous deployment goes one step further and releases every change that passes the pipeline without a manual gate. The other options describe skipped tests, technology limits, or branching rules that are not part of either definition.

Frequent integration of small changes, checked automatically on each merge, keeps conflicts and surprises small and visible early. The other options either delay testing until the batch is large, multiply environments without integrating anything, or postpone review, which makes the problem worse.

The services keyword starts additional containers alongside the job container, and each one is reachable using its image name as the hostname. Setting image changes the environment the job itself runs in, while cache and artifacts only move files and cannot start a running database.

Quick checks early stop broken changes before expensive work runs, and needs lets jobs start as soon as their inputs are ready instead of waiting for whole stages. The other options hide failures, delay feedback, or waste runner time on unchanged work.

The workflow keyword decides whether a pipeline is created at all, and when no rule allows a branch push, no pipeline is made. An offline runner or missing tags affects jobs after a pipeline exists, and branch pipelines do not need a manual trigger by default.

CI Lint and the pipeline editor check the syntax and show the configuration after includes and extends are resolved. Previous job logs show what ran rather than the merged configuration, git blame only shows history, and a runner debug flag reports runner activity rather than YAML validity.

A job waits in pending until a runner accepts it, which requires an online, unpaused runner with every tag the job asks for and free concurrency slots. Changing needs or artifact expiry does not affect whether a runner can accept the job.

GIT_DEPTH limits how much history the runner fetches, so a value of 1 clones only the latest commit. The parallel keyword multiplies jobs, interruptible only affects cancellation, and artifact expiry governs how long uploaded files are kept.

The Dependency Proxy keeps a local copy of upstream images such as Docker Hub images, so jobs in the group pull from GitLab and repeat downloads from the public registry are reduced. Storing team-built images is the job of the Container Registry, scanning is a separate security feature, and runner executors are configured on the runner rather than through this proxy.

CI_REGISTRY_IMAGE holds the registry path for the project, and CI_REGISTRY_USER and CI_REGISTRY_PASSWORD are predefined credentials the job can use to log in. Pushed images persist after the job ends, and tags have no required link to job names.

A multi-stage Dockerfile compiles in an intermediate stage and copies only the needed output into the final stage, so build tools never reach the shipped image. Pushing two images, changing parallel job counts, or using a larger base image does not remove the tools from the final image.

CI_COMMIT_SHORT_SHA is a predefined variable that holds the short commit hash, so a tag built from it points to one commit. A latest tag moves with every build, a runner host name says nothing about the code, and a job-name tag would be overwritten by each build.

Including the SAST template adds GitLab's maintained scanner jobs, which publish SAST reports that appear in merge requests. A text search is not full static analysis, cleanup policies handle images, and allow_failure hides results rather than producing them.

The codequality report type accepts Code Climate JSON and displays the findings in merge requests. JUnit reports are XML test results, while cache and dependencies do not turn a file into a merge request report.

The Secret Detection template is GitLab's maintained scanner for leaked credentials, and including it adds a job that reports findings. A variables regex does not scan commits, masking only hides values in job logs, and allow_failure hides findings rather than reporting them.

Protected variables are passed only to pipelines running on protected branches or tags. Masking hides values from job logs rather than restricting access, the Dependency Proxy only pulls upstream images, and an asterisk scope exposes the variable more widely.

A job runs only on runners that have every tag it requests, so the tags must match on one side or the other. Interruptible, artifact settings, and allow_failure do not change which runner can accept the job.

The Docker executor is the standard choice for container-per-job isolation, using the image keyword from the job definition. The shell executor has no container isolation, and the ssh and parallels executors run jobs on a remote machine or inside a virtual machine rather than a container from the job's image.

A group runner is registered at the group level and can run jobs for every project in that group, which fits one runner for five projects. An instance runner serves projects across the whole instance, a project runner only serves the project it was registered with, and tags do not restrict access by group membership.

The global concurrent setting in config.toml caps the total number of jobs the runner process runs at once across all of its registered runners on the host. A per-runner limit caps only that runner, tags decide which jobs a runner may take, and check_interval controls how often it polls for work.