GitLab CI/CD Associate sample questions with answers

GitLab CI/CD Associate sample questions

GitLab Certified CI/CD Associate, GitLab.

1. Question 1

   Domain: YAML Configuration

   A job has rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH with when: manual and no allow_failure setting. On the default branch, a later-stage job does not start.

   Why does the later-stage job not start?

   1. With `when: manual` inside `rules`, `allow_failure` defaults to `false`, so the manual job blocks later stages until it runs
   2. `when: manual` cannot be used in `rules`, so the job silently failed validation
   3. Rules-based manual jobs are always skipped on the default branch unless `interruptible` is set
   4. Later stages wait because rules-based jobs are always evaluated after all other stages
   Show the answer

   Answer: A. With `when: manual` inside `rules`, `allow_failure` defaults to `false`, so the manual job blocks later stages until it runs

   The default for `allow_failure` is reversed for manual jobs added through `rules`: it becomes `false`, making the job blocking. To get the non-blocking behaviour of a job-level `when: manual`, set `allow_failure: true` in the rule.

   Checked against: https://docs.gitlab.com/ci/yaml/#rulesallow_failure

2. Question 2

   Domain: YAML Configuration

   How does GitLab evaluate a job's rules list when creating a pipeline?

   1. Rules are checked in order and the last matching rule decides; if none match, the job runs with `when: on_success`
   2. Rules are checked in order and the first matching rule decides; if no rule matches, the job is not added to the pipeline
   3. All rules are checked and the job is added only if every rule matches
   4. Rules are checked in parallel and any rule with `when: never` overrides all the others
   Show the answer

   Answer: B. Rules are checked in order and the first matching rule decides; if no rule matches, the job is not added to the pipeline

   `rules` are evaluated in order until the first match, and that rule's attributes (such as `when`) are applied. If no rule matches, the job is excluded, which is why a final catch-all rule is often added; a `when: never` rule later in the list has no effect once an earlier rule has matched.

   Checked against: https://docs.gitlab.com/ci/yaml/#rules

3. Question 3

   Domain: Pipeline Development

   A DEPLOY_KEY variable is marked Protected in the project settings. The deploy job works on main but on an unprotected feature branch the variable is empty.

   What explains this?

   1. Protected variables are hidden from job logs, which makes them appear empty
   2. Protected variables require the job to set `environment: production`
   3. Protected variables are only available to jobs with `when: manual`
   4. Protected variables are only passed to pipelines running on protected branches or protected tags
   Show the answer

   Answer: D. Protected variables are only passed to pipelines running on protected branches or protected tags

   The Protected flag restricts a variable to pipelines on protected branches and tags, which is how deployment secrets are kept away from arbitrary branches. Hiding values in logs is what masking does; a masked variable still has its value inside the job.

   Checked against: https://docs.gitlab.com/ci/variables/#protect-a-cicd-variable

4. Question 4

   Domain: Pipeline Development

   The build stage has build:linux (3 minutes) and build:mac (15 minutes). In the test stage, test:linux has needs: [build:linux] and test:mac has needs: [build:mac].

   When does test:linux start?

   1. At the same time as `build:linux`, because `needs` runs jobs concurrently
   2. After `test:mac` finishes, because jobs in a stage run in file order
   3. As soon as `build:linux` finishes, without waiting for `build:mac`
   4. Only after both build jobs finish, because stages still gate execution
   Show the answer

   Answer: C. As soon as `build:linux` finishes, without waiting for `build:mac`

   With `needs`, a job waits only for the jobs it lists, so `test:linux` starts after roughly three minutes. Waiting for the whole `build` stage is the behaviour without `needs`, which is exactly what a DAG removes.

   Checked against: https://docs.gitlab.com/ci/yaml/#needs

5. Question 5

   Domain: CI/CD Fundamentals

   The target branch moves quickly, and a merge request whose pipeline passed sometimes breaks main after merging because it was never tested with the latest target changes.

   Which GitLab pipeline type addresses this?

   1. Branch pipelines, which test only the latest commit of the source branch in isolation
   2. Scheduled pipelines, which run the full test suite on the default branch every night
   3. Merged results pipelines, which test the source branch merged into the current target
   4. Child pipelines, which split the configuration into smaller files run from a parent
   Show the answer

   Answer: C. Merged results pipelines, which test the source branch merged into the current target

   A merged results pipeline tests a temporary merge commit of source and target, so it catches conflicts with recent target-branch changes; merge trains extend this by queuing merges. A normal branch pipeline only tests the source branch in isolation, which is the gap described.

   Checked against: https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/

6. Question 6

   Domain: CI/CD Fundamentals

   In GitLab CI/CD, which component actually executes the jobs defined in .gitlab-ci.yml?

   1. Gitaly, the service that stores Git repositories
   2. GitLab Runner, an application that picks up jobs from GitLab and runs them
   3. The Container Registry, which runs each job as an image
   4. The GitLab web interface, which runs jobs in the user's browser
   Show the answer

   Answer: B. GitLab Runner, an application that picks up jobs from GitLab and runs them

   GitLab coordinates pipelines, but jobs are executed by runners, agents running GitLab Runner on your infrastructure or GitLab-hosted machines. Gitaly provides Git repository access; it does not run CI jobs.

   Checked against: https://docs.gitlab.com/runner/

7. Question 7

   Domain: Troubleshooting and Optimization

   After a commit, the pipeline does not start and shows a YAML error: jobs:unit config contains unknown keys: scirpt.

   What should the developer fix?

   1. The misspelled `scirpt` keyword in the `unit` job, which should be `script`
   2. The project's CI/CD variables, because `scirpt` is referenced as an undefined variable in the job
   3. The `unit` job's stage, which must be declared in `stages` before use
   4. The runner registration, because `unit` does not match any runner tag
   Show the answer

   Answer: A. The misspelled `scirpt` keyword in the `unit` job, which should be `script`

   The error names the job and the unrecognised key, which here is a typo of `script`, so GitLab cannot build the job. Runner and tag problems only appear after a pipeline is created and show as pending jobs, not as YAML validation errors.

   Checked against: https://docs.gitlab.com/ci/yaml/lint/

8. Question 8

   Domain: Container and Package Management

   A build-image job must push an image to the project's Container Registry without storing a personal access token.

   Which login command is appropriate in the job?

   1. `docker login docker.io -u $GITLAB_USER_LOGIN -p $CI_COMMIT_SHA`
   2. `docker login $CI_SERVER_URL -u $CI_PROJECT_NAME --password-stdin`
   3. `docker login $CI_REGISTRY_IMAGE -u root -p $CI_JOB_ID`
   4. `echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin`
   Show the answer

   Answer: D. `echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin`

   GitLab provides `CI_REGISTRY_USER` and `CI_REGISTRY_PASSWORD` for each job, giving read-write access to the project's registry, and piping the password via `--password-stdin` keeps it off the command line. `CI_JOB_ID` and `CI_COMMIT_SHA` are identifiers, not credentials.

   Checked against: https://docs.gitlab.com/user/packages/container_registry/authenticate_with_container_registry/

9. Question 9

   Domain: Security Integration

   A security team wants to know whether a transitive library pulled in through package-lock.json has a known CVE.

   Which GitLab scanner is designed for this?

   1. Dependency scanning
   2. Pipeline secret detection
   3. Code Quality
   4. Static application security testing (SAST)
   Show the answer

   Answer: A. Dependency scanning

   Dependency scanning identifies known vulnerabilities in a project's dependencies, including transitive packages. SAST analyses your own source code for insecure patterns and does not check third-party package versions against advisories.

   Checked against: https://docs.gitlab.com/user/application_security/dependency_scanning/

10. Question 10

    Domain: Runner Configuration

    An organisation already operates Kubernetes clusters and wants each CI job to run as a short-lived workload in a cluster namespace.

    Which executor, and what does it create for each job?

    1. The SSH executor, which opens a session to a Kubernetes node per job
    2. The Kubernetes executor, which creates a pod for each job
    3. The Docker executor, which creates a Kubernetes deployment for each pipeline
    4. The Shell executor, which runs `kubectl` on the node hosting the runner
    Show the answer

    Answer: B. The Kubernetes executor, which creates a pod for each job

    The Kubernetes executor uses the cluster API to create a pod for each job, containing the build, helper and any service containers. The Docker executor talks to a Docker daemon, not to Kubernetes, and does not create cluster workloads.

    Checked against: https://docs.gitlab.com/runner/executors/kubernetes/