I85PREP
⌘ K
GitLab CI/CD Associate study materials
GitLab CI/CD Associate study resources

GitLab CI/CD Associate practice questions

One question at a time. Build your GitLab CI/CD Associate understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Pipeline configuration and CI/CD YAML fundamentals

In a .gitlab-ci.yml file, which top-level keyword is required for the pipeline to be valid?

  1. variables
  2. stages
  3. script Correct answer.
  4. image

Explanation

A job must define what to execute, and the `script` keyword supplies the shell commands that the runner executes. `stages`, `image`, and `variables` are all optional configuration that shape how jobs run but are not mandatory for a valid pipeline.

Question 2Pipeline configuration and CI/CD YAML fundamentals

What does the `stage` keyword inside a job control?

  1. The Docker image layer used to run the job
  2. The maximum runtime allowed before the job times out
  3. The branch on which the job is allowed to execute
  4. The order in which the job runs relative to other jobs Correct answer.

Explanation

`stage` assigns a job to one of the pipeline stages, and stages execute sequentially so jobs in the same stage run in parallel while later stages wait. It does not influence images, timeouts, or branch restrictions, which are configured by other keywords.

Question 3Pipeline configuration and CI/CD YAML fundamentals

A pipeline defines stages `build`, `test`, and `deploy`. Job A is in `build`, jobs B and C are in `test`. Which statement describes the default execution behavior?

  1. A and B run in parallel, then C runs
  2. A runs first, then B and C run in parallel Correct answer.
  3. B and C run first, then A runs
  4. A, B, and C all start simultaneously

Explanation

Stages run in the order listed, and all jobs within a single stage run concurrently when enough runners are available. Because B and C share the `test` stage, they start together only after every `build` job succeeds.

Question 4Pipeline configuration and CI/CD YAML fundamentals

Which keyword lets you run a set of commands before the main `script` of every job without repeating them in each job?

  1. pre_stage
  2. prepare
  3. before_script Correct answer.
  4. setup_script

Explanation

`before_script` defines commands that GitLab prepends to each job's `script`, which is useful for shared setup such as installing dependencies. `pre_stage`, `setup_script`, and `prepare` are not valid GitLab CI/CD keywords.

Question 5Pipeline configuration and CI/CD YAML fundamentals

How does GitLab handle the exit status of commands listed in a job's `script`?

  1. Each command's status is collected and reported but never fails the job
  2. The job fails as soon as any command returns a non-zero status Correct answer.
  3. Only the last command's status determines job success
  4. Non-zero statuses are ignored unless `allow_failure` is true

Explanation

The runner treats the `script` as a shell sequence and aborts on the first command that exits non-zero, marking the job failed. To tolerate a failing command you must handle it explicitly, for example with `|| true` or by placing it in `allow_failure` logic.

Question 6Pipeline configuration and CI/CD YAML fundamentals

Which `rules` clause makes a job run only for pipelines triggered by a merge request event?

  1. if: '$CI_COMMIT_BRANCH == "merge_request"'
  2. if: '$CI_PIPELINE_SOURCE == "merge_request_event"' Correct answer.
  3. only: merge_requests
  4. when: merge_request

Explanation

`rules:if` evaluates a CI/CD expression, and `$CI_PIPELINE_SOURCE` holds the event that created the pipeline, with `merge_request_event` for merge request pipelines. The `when` keyword controls job status behavior rather than pipeline source, and `only: merge_requests` is not the correct syntax for this purpose.

Question 7Pipeline configuration and CI/CD YAML fundamentals

In a `rules` entry, what happens when the `when` value is `never`?

  1. The job is excluded from the pipeline for matching conditions Correct answer.
  2. The job runs only after a manual approval
  3. The job runs but is allowed to fail
  4. The job is retried automatically on failure

Explanation

Setting `when: never` in a matching rule prevents the job from being added to the pipeline. It is the standard way to exclude jobs for specific branches, tags, or pipeline sources.

Question 8Pipeline configuration and CI/CD YAML fundamentals

Which keyword is the current recommended way to run the same job definition against multiple values, such as several Node.js versions?

  1. matrix
  2. parallel:matrix Correct answer.
  3. loop
  4. foreach

Explanation

`parallel:matrix` expands a job into multiple parallel jobs, one per combination of the listed variable values. It replaced the older `only`/`except` matrix approach and keeps the YAML compact.

Question 9Pipeline configuration and CI/CD YAML fundamentals

What is the purpose of the `needs` keyword in a job?

  1. To declare external services the job depends on
  2. To install packages required by the job
  3. To run a job out of stage order as soon as its listed jobs finish Correct answer.
  4. To require manual approval before the job starts

Explanation

`needs` creates a directed acyclic graph so a job can start as soon as the jobs it lists complete, even if those jobs are in an earlier stage than other pending work. This shortens pipelines compared with waiting for an entire stage to finish.

Question 10Pipeline configuration and CI/CD YAML fundamentals

A job declares `needs: []` with no entries. What effect does this have?

  1. The job is skipped entirely
  2. The job starts immediately without waiting for earlier stages Correct answer.
  3. The job runs only when triggered manually
  4. The job waits for every job in the pipeline

Explanation

An empty `needs` array tells GitLab the job has no dependencies, so it can be scheduled at the start of the pipeline regardless of stage order. This is often used for quick setup or lint jobs that block nothing.

Question 11Pipeline configuration and CI/CD YAML fundamentals

Which keyword stores files produced by a job so they can be downloaded or passed to later jobs?

  1. reports
  2. artifacts Correct answer.
  3. dependencies
  4. cache

Explanation

`artifacts` uploads files produced by a job and makes them available to later stages and for download from the UI. `cache` is for reusable files between pipeline runs and is not guaranteed to persist.

Question 12Pipeline configuration and CI/CD YAML fundamentals

What is the main difference between `cache` and `artifacts` in GitLab CI/CD?

  1. Cache is shared between jobs in the same pipeline, artifacts only within one job
  2. Artifacts are deleted after each stage, cache persists forever
  3. They are interchangeable keywords with identical behavior
  4. Cache is intended to speed up jobs across pipeline runs, artifacts are job outputs passed downstream Correct answer.

Explanation

`cache` is designed to reuse files such as dependency directories between pipeline executions, while `artifacts` are the declared outputs of a job that later jobs can fetch. Artifacts are tied to a specific pipeline and job, whereas cache is a performance optimization.

Question 13Pipeline configuration and CI/CD YAML fundamentals

Which keyword defines named, reusable sets of CI/CD configuration that jobs can include with `extends`?

  1. default
  2. extends Correct answer.
  3. include
  4. .job_templates

Explanation

`extends` lets a job inherit configuration from another job or hidden job, and the referenced definition is often stored in a hidden job whose name begins with a dot. `include` imports whole files, while `default` sets global defaults for keywords.

Question 14Pipeline configuration and CI/CD YAML fundamentals

A hidden job named `.test_template` defines `script` and `image`. A job uses `extends: .test_template`. What is the result?

  1. The job fails because hidden jobs cannot be extended
  2. The job imports `.test_template` as a separate pipeline
  3. The job inherits only `image` because `script` is mandatory
  4. The job inherits `script` and `image` and can override either Correct answer.

Explanation

Jobs whose names start with a dot are not added to the pipeline but can serve as templates. A job using `extends` merges the referenced keys and may override any of them with its own values.

Question 15Pipeline configuration and CI/CD YAML fundamentals

Which keyword merges configuration from another YAML file into the current pipeline?

  1. extends
  2. import
  3. reference
  4. include Correct answer.

Explanation

`include` pulls in configuration from local files, other projects, or remote URLs, and the included content is merged with the current `.gitlab-ci.yml`. `extends` performs job-level inheritance rather than file inclusion.

Question 16Pipeline configuration and CI/CD YAML fundamentals

Which `include` form is used to pull a CI file from a different GitLab project?

  1. include: remote
  2. include: local
  3. include: template
  4. include: project Correct answer.

Explanation

`include: project` references another project and a file path within it, optionally pinned to a ref. `local` is for files in the same repository, `remote` for public URLs, and `template` for GitLab-provided templates.

Question 17Pipeline configuration and CI/CD YAML fundamentals

Which keyword allows a job to be started by a user from the pipeline view rather than automatically?

  1. rules: manual
  2. when: manual Correct answer.
  3. interruptible: true
  4. allow_failure: true

Explanation

`when: manual` creates a job that requires a user to click play before it runs. By default a manual job is considered optional, so it does not block the pipeline unless `allow_failure: false` is set.

Question 18Pipeline configuration and CI/CD YAML fundamentals

A job sets `when: manual` and `allow_failure: false`. What is the effect on the pipeline?

  1. The job runs automatically after a timeout
  2. The pipeline is blocked until the manual job is run Correct answer.
  3. The job is removed from the pipeline
  4. The job is skipped and the pipeline continues

Explanation

By default manual jobs are optional and do not block progress. Setting `allow_failure: false` makes the manual job blocking, so the pipeline waits for a user to trigger it before continuing.

Question 19Pipeline configuration and CI/CD YAML fundamentals

Which keyword defines variables scoped to a single job?

  1. env
  2. variables at the top level
  3. global
  4. variables inside the job Correct answer.

Explanation

A `variables` block placed inside a job defines variables available only to that job, while a top-level `variables` block applies to all jobs. Job-level values take precedence over global values with the same name.

Question 20Pipeline configuration and CI/CD YAML fundamentals

In a job, a variable named `DEPLOY_ENV` is defined both at the top level as `staging` and inside the job as `production`. Which value does the job use?

  1. The job fails due to a duplicate definition
  2. staging
  3. production Correct answer.
  4. Both values are concatenated

Explanation

Job-level variables override global variables with the same name, so the job sees `production`. Global definitions act as defaults that individual jobs can replace.

Question 21Pipeline configuration and CI/CD YAML fundamentals

Which syntax correctly references a variable in a `script` line so that the shell expands it at runtime?

  1. echo <CI_COMMIT_BRANCH>
  2. echo %CI_COMMIT_BRANCH%
  3. echo {{CI_COMMIT_BRANCH}}
  4. echo $CI_COMMIT_BRANCH Correct answer.

Explanation

Variables are exposed to the job environment and expanded by the shell, so the standard `$NAME` form works. The other forms are not GitLab CI/CD variable syntax.

Question 22Pipeline configuration and CI/CD YAML fundamentals

Which keyword runs a job only when a specific file, such as `Dockerfile`, changes?

  1. rules: changes Correct answer.
  2. trigger: changes
  3. cache: key: files
  4. only: files

Explanation

`rules: changes` compares the listed paths against the changes in the pipeline's commit range and includes the job only when a match is found. It is commonly paired with `if` conditions to scope the check to merge request or branch pipelines.

Question 23Pipeline configuration and CI/CD YAML fundamentals

What does the `interruptible` keyword enable for a job?

  1. The job can be retried automatically on failure
  2. The job can be canceled when a newer pipeline for the same ref starts Correct answer.
  3. The job can be paused for manual input
  4. The job can run without a runner

Explanation

Marking a job `interruptible: true` allows GitLab to cancel it when a newer pipeline supersedes it on the same ref, which saves runner capacity. It affects cancellation behavior, not retries or manual input.

Question 24Pipeline configuration and CI/CD YAML fundamentals

Which keyword specifies the maximum amount of time a job may run before GitLab terminates it?

  1. deadline
  2. expire_in
  3. retry
  4. timeout Correct answer.

Explanation

`timeout` sets a per-job or project-level limit on execution time, after which the job is failed and stopped. `expire_in` controls artifact retention, and `retry` controls re-execution attempts.

Question 25Pipeline configuration and CI/CD YAML fundamentals

A job uses `rules` with one entry `if: '$CI_COMMIT_BRANCH == "main"'` and no `when` key. What happens on a pipeline for a feature branch?

  1. The pipeline fails validation
  2. The job is excluded because no rule matched Correct answer.
  3. The job runs with the default `when: on_success`
  4. The job runs in manual mode

Explanation

When a job has `rules` and none of the entries match, the job is not added to the pipeline. A matching rule without an explicit `when` defaults to `on_success`.

Question 26Pipeline configuration and CI/CD YAML fundamentals

A job defines `script` with three commands. One command exits with status 1. What does GitLab CI/CD do with the remaining commands in that job?

  1. It retries the failing command automatically before moving to the next line.
  2. It skips only the failing line and continues, reporting a warning in the job log.
  3. It continues running the remaining commands and reports the job as passed as long as the last command succeeds.
  4. It stops executing the job and marks it failed, because each script line runs in sequence and a non-zero exit fails the job. Correct answer.

Explanation

The `script` section is executed line by line by the runner's shell, and the job fails as soon as a command returns a non-zero exit status. Later commands are not executed once that happens. This fail-fast behavior is the default for shell execution in GitLab CI/CD jobs.

Question 27Pipeline configuration and CI/CD YAML fundamentals

Which keyword should you use to define a default `image` and `before_script` that apply to every job in the pipeline unless a job overrides them?

  1. `default` Correct answer.
  2. `stages`
  3. `variables`
  4. `workflow`

Explanation

The `default` keyword holds global defaults such as `image`, `services`, `before_script`, `after_script`, `cache`, and `tags`, which are copied into jobs that do not define those keys themselves. A job that sets its own value overrides the default for that key. `variables` and `stages` are separate top-level keywords with different purposes.

Question 28Pipeline configuration and CI/CD YAML fundamentals

A pipeline YAML file references `$CI_COMMIT_TAG` inside a `rules:if` expression. On a branch pipeline with no tag, what value does that variable have for the comparison?

  1. It is empty, so a comparison such as `$CI_COMMIT_TAG == "v1"` evaluates false. Correct answer.
  2. It contains the branch name, so the comparison matches the branch.
  3. It causes the pipeline to fail configuration validation.
  4. It contains the literal string `null`, which always matches.

Explanation

Predefined variables that do not apply to the current pipeline, such as `CI_COMMIT_TAG` on a branch pipeline, are empty. An equality comparison against a non-empty string therefore evaluates to false. This is why `$CI_COMMIT_TAG` is commonly used to gate tag-only jobs.

Question 29Pipeline configuration and CI/CD YAML fundamentals

Which top-level keyword lets you declare the ordered list of stages and thereby control when jobs become eligible to run relative to each other?

  1. `rules`
  2. `needs`
  3. `environment`
  4. `stages` Correct answer.

Explanation

The top-level `stages` keyword declares the ordered stage names, and jobs run stage by stage in that order by default. Jobs in the same stage run in parallel, and later stages start only after earlier stages succeed. `needs` can change this behavior, but the stage ordering itself comes from `stages`.

Question 30Pipeline configuration and CI/CD YAML fundamentals

A job must run in every pipeline regardless of branch, but only after the `build` job succeeds and without waiting for other jobs in intervening stages. Which configuration achieves this?

  1. Set `dependencies: ["build"]` on the job so it starts immediately after build.
  2. Set `rules` with `when: always` on the job so it ignores stage order.
  3. Set `stage: build` on the job so it shares the stage with the build job.
  4. Set `needs: ["build"]` on the job so it starts as soon as `build` finishes. Correct answer.

Explanation

`needs` creates a directed dependency that lets a job start as soon as its listed jobs complete, even if those jobs are in an earlier stage than the job's own stage. This is what enables out-of-order execution within a pipeline. `dependencies` only controls which artifacts are downloaded and does not change scheduling.

Question 31Pipeline configuration and CI/CD YAML fundamentals

You want a job to run only when a merge request pipeline exists and the target branch is `main`. Which `rules` clause expresses both conditions in one entry?

  1. `if: '$CI_COMMIT_BRANCH == "main" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"'`
  2. `if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main"'`
  3. `if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"'` Correct answer.
  4. `if: '$CI_PIPELINE_SOURCE == "merge_request_event" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"'`

Explanation

The `&&` operator requires both sides to be true, so the entry matches only merge request pipelines whose target branch is `main`. `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` is populated only in merge request pipelines, which makes it the right variable for the target branch. Using `||` or the push source would match pipelines you do not want.

Question 32Pipeline configuration and CI/CD YAML fundamentals

A job sets `rules` with two entries: the first has `if: '$CI_COMMIT_BRANCH == "main"'` and `when: manual`; the second has `when: on_success`. A pipeline runs on `main`. Which outcome applies?

  1. The job is added as a manual action because the first matching rule wins. Correct answer.
  2. The job runs automatically and also appears as a manual action.
  3. The job runs automatically because the second rule is evaluated last.
  4. The job is not added to the pipeline because the rules conflict.

Explanation

Rules are evaluated in order from top to bottom, and the first rule whose condition matches determines the job's behavior. Because the `main` branch matches the first entry, its `when: manual` applies and later entries are ignored. The catch-all second entry only governs pipelines where the first condition is false.

Question 33Pipeline configuration and CI/CD YAML fundamentals

Which approach correctly reuses a block of `script` lines shared by several jobs while keeping the block from running as a job itself?

  1. Define the block under a top-level `variables` key and reference it with `!reference`.
  2. Define the block under `workflow` and let jobs opt in with `rules`.
  3. Define the block under a hidden job key beginning with a dot and reference it with `extends`. Correct answer.
  4. Define the block under `default` and let every job inherit it implicitly.

Explanation

Keys that start with a dot are hidden jobs: they are not added to the pipeline but can be reused through `extends` or `!reference`. This is the standard way to share script blocks without executing the template as a job. `default` applies to all jobs and is not a selective reuse mechanism.

Question 34Pipeline configuration and CI/CD YAML fundamentals

A job uses `extends` from two templates: the first sets `script: ["a"]` and the second sets `script: ["b"]`. What is the resulting `script` for the job?

  1. The job's `script` is the second template's value, `["b"]`, because later parents override earlier ones for the same key. Correct answer.
  2. The job's `script` is the concatenation `["a", "b"]` from both parents.
  3. The job's `script` is the first template's value, `["a"]`, because the first parent wins.
  4. The pipeline fails because two parents cannot define the same key.

Explanation

`extends` performs a reverse deep merge in which the job's own keys take precedence, then parents are applied in order so that later parents override earlier ones for scalar and array keys. Arrays such as `script` are replaced, not concatenated. The job therefore ends up with the value from the last parent that defines the key.

Question 35Pipeline configuration and CI/CD YAML fundamentals

Which `include` configuration pulls a CI file from another project and pins it to a specific ref so the content is stable?

  1. `include: template: 'Jobs/Build.gitlab-ci.yml'`
  2. `include: local: '/templates/build.yml'`
  3. `include: project: 'group/ci-templates', ref: 'v2.1', file: '/templates/build.yml'` Correct answer.
  4. `include: remote: 'https://example.com/ci/build.yml'`

Explanation

The `project` form of `include` takes a project path plus a `ref` (branch, tag, or commit SHA) and one or more `file` entries. Pinning `ref` to a tag or SHA keeps the included configuration stable across pipeline runs. The other forms pull from the same repository, a URL, or GitLab-provided templates.

Question 36Pipeline configuration and CI/CD YAML fundamentals

A job needs the artifacts of two earlier jobs and must also start before its stage would normally begin. Which pair of keywords should be combined?

  1. `needs` listing both jobs, which also makes their artifacts available by default. Correct answer.
  2. `needs` listing both jobs plus `dependencies: []` to force artifact download.
  3. `stage` set to the earlier stage plus `cache` keyed on both jobs.
  4. `dependencies` listing both jobs plus `when: always`.

Explanation

`needs` establishes the scheduling dependency and, by default, downloads artifacts from the listed jobs. Combining it with an explicit `dependencies` list is only needed when you want to restrict which needed jobs' artifacts are fetched. Setting `dependencies: []` would actually disable artifact downloading.

Question 37Pipeline configuration and CI/CD YAML fundamentals

Which `rules` entry makes a job run only when a variable named `DEPLOY` is set to `true`, and otherwise keeps the job out of the pipeline entirely?

  1. `rules: [{ if: '$DEPLOY == "true"' }, { when: never }]`
  2. `rules: [{ changes: ['$DEPLOY'], when: on_success }]`
  3. `rules: [{ if: '$DEPLOY == "true"', when: on_success }]` with no fallback entry. Correct answer.
  4. `rules: [{ if: '$DEPLOY != "true"', when: never }]`

Explanation

When a job's `rules` list has no entry that matches, the job is not added to the pipeline. A single entry that matches only when `DEPLOY` equals `true` therefore excludes the job in all other cases without needing an explicit `when: never`. Adding a fallback `when: never` entry is redundant but not harmful.

Question 38Pipeline configuration and CI/CD YAML fundamentals

A pipeline has stages `build`, `test`, and `deploy`. The `deploy` job sets `needs: ["unit-test"]`. The `build` job is still running when `unit-test` finishes. What happens to `deploy`?

  1. It fails because `needs` cannot reference a job in a different stage.
  2. It starts only after `build` finishes because stage order always takes precedence.
  3. It can start as soon as `unit-test` succeeds, without waiting for `build` to finish. Correct answer.
  4. It waits for all jobs in `build` and `test` to finish before starting.

Explanation

When a job uses `needs`, it becomes part of the directed acyclic graph and starts as soon as its needed jobs complete successfully, regardless of whether other jobs in earlier stages are still running. Stage order is no longer the gating factor for that job. This is the core behavior that makes DAG pipelines faster.

Question 39Pipeline configuration and CI/CD YAML fundamentals

A job template sets `rules` with `if: '$CI_COMMIT_BRANCH'`. A child job extends the template and adds its own `rules` entry. What is the resulting rules behavior?

  1. The child's `rules` is appended to the template's `rules`, and both entries are evaluated in order.
  2. The child's `rules` is ignored and the template's `rules` is used.
  3. The pipeline fails because `rules` cannot be overridden by `extends`.
  4. The child's `rules` replaces the template's `rules` entirely, so only the child's entry is evaluated. Correct answer.

Explanation

`extends` deep-merges hashes but replaces arrays, and `rules` is an array. The child job's `rules` therefore overwrites the template's `rules` rather than being combined with it. To combine behaviors, the child must restate every entry it needs.

Question 40Pipeline configuration and CI/CD YAML fundamentals

A maintainer wants a job to appear in the pipeline but require a manual click, and wants the pipeline to be considered blocked until that click happens. Which combination achieves this?

  1. `when: manual` with `allow_failure: true`
  2. `when: delayed` with `start_in: '1 hour'`
  3. `when: on_success` with `interruptible: true`
  4. `when: manual` with `allow_failure: false` Correct answer.

Explanation

A manual job with `allow_failure: false` is a blocking manual job: the pipeline status becomes blocked and does not proceed until someone runs the job. With `allow_failure: true`, the manual job is optional and the pipeline can succeed without it. `when: delayed` schedules the job automatically after a wait rather than requiring a click.

Question 41Job execution, stages, and pipeline flow control

In a GitLab CI/CD pipeline, which keyword defines the ordered list of stages that jobs are assigned to?

  1. stage
  2. flow
  3. pipeline
  4. stages Correct answer.

Explanation

The top-level `stages` keyword declares the ordered sequence of stages for the pipeline, and jobs reference one of these names via their own `stage` keyword. If `stages` is omitted, the default sequence build, test, and deploy is used.

Question 42Job execution, stages, and pipeline flow control

A job has no `stage` keyword and the configuration does not declare `stages`. Which stage does the job run in?

  1. build Correct answer.
  2. test
  3. deploy
  4. review

Explanation

When `stages` is not defined, GitLab uses the default stage order build, test, and deploy, and a job without an explicit `stage` is assigned to the first default stage, which is build.

Question 43Job execution, stages, and pipeline flow control

Two jobs are both assigned to the `test` stage and neither declares `needs`. How does GitLab schedule them?

  1. Sequentially in the order they appear in the file
  2. In reverse alphabetical order of job names
  3. In parallel, since they share the same stage Correct answer.
  4. Only the first job runs and the second is skipped

Explanation

Jobs in the same stage run in parallel by default, subject to available runners. File order does not serialize them, and no job is skipped merely because it shares a stage.

Question 44Job execution, stages, and pipeline flow control

Which keyword on a job makes it run before earlier stages have finished, by letting it start as soon as its listed dependencies complete?

  1. needs Correct answer.
  2. dependencies
  3. extends
  4. before_script

Explanation

`needs` lets a job start as soon as the jobs it lists finish, even if those jobs are in an earlier stage, which produces a directed acyclic graph rather than strict stage barriers. `dependencies` only controls artifact downloading.

Question 45Job execution, stages, and pipeline flow control

What does the `when: manual` setting do to a job in a pipeline?

  1. It skips the job unless the pipeline is a merge request pipeline
  2. It runs the job immediately without a runner
  3. It converts the job into a scheduled pipeline trigger
  4. It creates a job that must be triggered by a user before it runs Correct answer.

Explanation

`when: manual` marks a job as a manual action: it is created in the pipeline but does not execute until someone starts it from the UI or API. By default a manual job is optional and does not block the pipeline from completing.

Question 46Job execution, stages, and pipeline flow control

A job sets `when: on_success`. Under what condition does the job run?

  1. When the pipeline is triggered by a schedule
  2. Only when a previous job in the same stage fails
  3. When all jobs in earlier stages succeed Correct answer.
  4. Regardless of the outcome of earlier stages

Explanation

`on_success` is the default value and runs the job only if all jobs in earlier stages completed successfully. If an earlier job fails, the job is not executed.

Question 47Job execution, stages, and pipeline flow control

Which value of `when` causes a job to run only when at least one job in an earlier stage fails?

  1. delayed
  2. always
  3. never
  4. on_failure Correct answer.

Explanation

`when: on_failure` executes the job only if a job in an earlier stage fails, which makes it useful for cleanup or notification jobs. `always` runs regardless of earlier outcomes.

Question 48Job execution, stages, and pipeline flow control

Which keyword pauses a job for a fixed amount of time before its script executes?

  1. when: delayed with start_in Correct answer.
  2. interruptible
  3. retry
  4. timeout

Explanation

Setting `when: delayed` together with `start_in` (for example `start_in: 30 minutes`) schedules the job to start after the given duration. `timeout` instead limits how long a job may run.

Question 49Job execution, stages, and pipeline flow control

A pipeline has stages build, test, deploy. The build job fails, but a test job is configured with `when: always`. What happens?

  1. The test job is converted into a manual job
  2. The entire pipeline is rejected before any job starts
  3. The test job runs because `always` ignores earlier failures Correct answer.
  4. The test job does not run because build failed

Explanation

`when: always` runs the job regardless of the status of jobs in earlier stages, so a build failure does not prevent it. Other jobs using the default `on_success` would be skipped.

Question 50Job execution, stages, and pipeline flow control

A job uses `needs: []` with no other entries. What is the effect?

  1. The job downloads artifacts from all earlier jobs
  2. The job is skipped unless manually triggered
  3. The job waits for every job in all earlier stages
  4. The job starts immediately at the beginning of the pipeline Correct answer.

Explanation

An empty `needs` array tells GitLab the job has no prerequisites, so it can start as soon as the pipeline is created, in parallel with the first stage. This is commonly used for independent setup or lint jobs.