If stages is omitted, GitLab uses build, test, deploy in that order. Jobs without a stage keyword are assigned to test.

extends keyword behavior

extends performs a reverse deep merge: the child job's keys override the parent, and arrays are replaced rather than concatenated.

include supports local, remote, template, and project references. Use ref and file for project includes, and rules to conditionally include configuration.

workflow rules purpose

workflow:rules controls whether a pipeline is created at all and can set workflow:name. It is commonly used to prevent duplicate branch and MR pipelines.

YAML merge key support

GitLab CI/CD does not support the YAML merge key (<<). Use extends for inheritance or anchors and aliases for repeated blocks.

rules evaluation order

rules are evaluated in order and the first match wins. A job runs when its rules evaluate to true and its needs dependencies are satisfied.

needs creates a directed acyclic graph that lets jobs start before their stage completes. needs: optional: true prevents failure when the needed job is absent.

A manual job requires a user to start it and is non-blocking by default (allow_failure: true). Set allow_failure: false to make it blocking.

interruptible keyword

interruptible: true allows a running job to be canceled when a newer pipeline for the same ref starts and auto-cancel is enabled.

resource_group purpose

resource_group serializes jobs that share the same resource, preventing concurrent deployments to the same environment.

retry when conditions

retry:when accepts always, on_failure, on_script_failure, on_runner_system_failure, and on_stuck_or_timeout_failure. retry:max sets the attempt count.

Variable precedence order

Highest to lowest: trigger/manual variables, project/group variables, instance variables, job variables, global variables, deployment variables, predefined variables.

Protected variable scope

Protected variables are only exposed to pipelines running on protected branches or tags, limiting exposure from untrusted merge request pipelines.

Masked variable requirements

Masked variables hide values in job logs and must meet masking requirements, including minimum length and allowed characters.

A file-type variable writes its value to a temporary file and exposes the path. It is used for credentials such as kubeconfig or service account keys.

CI_JOB_TOKEN is a short-lived token scoped to the job. It can authenticate to the GitLab API and package registry with limited permissions.

Environment-scoped variables

Variables defined with an environment scope are only available to jobs deploying to that environment.

Cache versus artifacts

cache is reused between jobs and pipelines and is best-effort. artifacts are uploaded after a job, stored, and passed to later jobs.

cache:key:files computes a hash from lockfiles such as package-lock.json or Gemfile.lock so the cache invalidates when dependencies change.

cache:policy accepts pull, push, or pull-push. It controls whether the job downloads, uploads, or both downloads and uploads the cache.

artifacts:reports types

artifacts:reports supports junit, coverage_report, codequality, sast, dependency_scanning, container_scanning, and license_scanning for merge request widgets.

artifacts:when values

artifacts:when controls upload on_success, on_failure, or always. artifacts:access controls who can download (all or developer).

dependencies: [] effect

dependencies: [] prevents downloading artifacts from previous jobs. needs:artifacts: false downloads only the needed job's artifacts.

Runner types are shared (available to all projects), group, and project-specific. Runner scope and tags determine which jobs a runner can pick up.

Executors include shell, docker, docker-autoscaler, kubernetes, docker-machine (deprecated), virtualbox, parallels, and ssh. The executor determines the job environment.

Tags are case-sensitive. A job with tags runs only on runners that have all listed tags. Jobs without tags run on runners with Run untagged jobs enabled.

protected: true on a runner restricts it to protected branches and tags. Combine with protected variables for deployment security.

The Kubernetes executor creates a pod per job. Use the runner's service account and pod specifications for resource limits and node selection.

Merge request pipeline source

Merge request pipelines require rules with $CI_PIPELINE_SOURCE == "merge_request_event" or workflow:rules to run for merge request events.

Duplicate pipeline prevention

workflow:rules can prevent duplicate pipelines by allowing either branch pipelines or MR pipelines, not both, for the same event.

Exit code 137 usually indicates the job was killed, often due to out-of-memory or timeout. Check the job log and runner system logs.

CI_DEBUG_TRACE variable

CI_DEBUG_TRACE: "true" enables verbose job logs. Avoid in production because secrets may be exposed in the trace output.

GitLab CI/CD Associate study materials

GitLab CI/CD Associate flashcards

GitLab CI/CD Associate · Build recall with a focused review session.

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Default stages order: If stages is omitted, GitLab uses build, test, deploy in that order. Jobs without a stage keyword are assigned to test.
extends keyword behavior: extends performs a reverse deep merge: the child job's keys override the parent, and arrays are replaced rather than concatenated.
include types: include supports local, remote, template, and project references. Use ref and file for project includes, and rules to conditionally include configuration.
workflow rules purpose: workflow:rules controls whether a pipeline is created at all and can set workflow:name. It is commonly used to prevent duplicate branch and MR pipelines.
YAML merge key support: GitLab CI/CD does not support the YAML merge key (<<). Use extends for inheritance or anchors and aliases for repeated blocks.
rules evaluation order: rules are evaluated in order and the first match wins. A job runs when its rules evaluate to true and its needs dependencies are satisfied.
needs keyword effect: needs creates a directed acyclic graph that lets jobs start before their stage completes. needs: optional: true prevents failure when the needed job is absent.
when manual behavior: A manual job requires a user to start it and is non-blocking by default (allow_failure: true). Set allow_failure: false to make it blocking.
interruptible keyword: interruptible: true allows a running job to be canceled when a newer pipeline for the same ref starts and auto-cancel is enabled.
resource_group purpose: resource_group serializes jobs that share the same resource, preventing concurrent deployments to the same environment.
retry when conditions: retry:when accepts always, on_failure, on_script_failure, on_runner_system_failure, and on_stuck_or_timeout_failure. retry:max sets the attempt count.
Variable precedence order: Highest to lowest: trigger/manual variables, project/group variables, instance variables, job variables, global variables, deployment variables, predefined variables.
Protected variable scope: Protected variables are only exposed to pipelines running on protected branches or tags, limiting exposure from untrusted merge request pipelines.
Masked variable requirements: Masked variables hide values in job logs and must meet masking requirements, including minimum length and allowed characters.
File-type variable: A file-type variable writes its value to a temporary file and exposes the path. It is used for credentials such as kubeconfig or service account keys.
CI_JOB_TOKEN scope: CI_JOB_TOKEN is a short-lived token scoped to the job. It can authenticate to the GitLab API and package registry with limited permissions.
Environment-scoped variables: Variables defined with an environment scope are only available to jobs deploying to that environment.
Cache versus artifacts: cache is reused between jobs and pipelines and is best-effort. artifacts are uploaded after a job, stored, and passed to later jobs.
cache:key:files: cache:key:files computes a hash from lockfiles such as package-lock.json or Gemfile.lock so the cache invalidates when dependencies change.
cache:policy values: cache:policy accepts pull, push, or pull-push. It controls whether the job downloads, uploads, or both downloads and uploads the cache.
artifacts:reports types: artifacts:reports supports junit, coverage_report, codequality, sast, dependency_scanning, container_scanning, and license_scanning for merge request widgets.
artifacts:when values: artifacts:when controls upload on_success, on_failure, or always. artifacts:access controls who can download (all or developer).
dependencies: [] effect: dependencies: [] prevents downloading artifacts from previous jobs. needs:artifacts: false downloads only the needed job's artifacts.
Runner types: Runner types are shared (available to all projects), group, and project-specific. Runner scope and tags determine which jobs a runner can pick up.
Executor types: Executors include shell, docker, docker-autoscaler, kubernetes, docker-machine (deprecated), virtualbox, parallels, and ssh. The executor determines the job environment.
Runner tags matching: Tags are case-sensitive. A job with tags runs only on runners that have all listed tags. Jobs without tags run on runners with Run untagged jobs enabled.
Protected runner: protected: true on a runner restricts it to protected branches and tags. Combine with protected variables for deployment security.
Kubernetes executor: The Kubernetes executor creates a pod per job. Use the runner's service account and pod specifications for resource limits and node selection.
Merge request pipeline source: Merge request pipelines require rules with $CI_PIPELINE_SOURCE == "merge_request_event" or workflow:rules to run for merge request events.
Duplicate pipeline prevention: workflow:rules can prevent duplicate pipelines by allowing either branch pipelines or MR pipelines, not both, for the same event.
Exit code 137: Exit code 137 usually indicates the job was killed, often due to out-of-memory or timeout. Check the job log and runner system logs.
CI_DEBUG_TRACE variable: CI_DEBUG_TRACE: "true" enables verbose job logs. Avoid in production because secrets may be exposed in the trace output.