---
title: "GitLab CI/CD: Pipeline Automation Fundamentals"
description: "Test your mastery of GitLab CI/CD fundamentals, including .gitlab-ci.yml structure, Runner architecture, Pipeline stages, and environment management."
author: "Mohammad Abu Mattar"
canonical: https://mkabumattar.com/quizzes/post/gitlab-cicd-pipeline-quiz
---

# GitLab CI/CD: Pipeline Automation Fundamentals

Welcome to the GitLab CI/CD Basics Quiz! This quiz covers the fundamentals of GitLab CI/CD, including pipelines, jobs, stages, triggers, and best practices. Test your knowledge and see how well you understand this powerful automation tool.

## Questions

### 1. What is the standard filename for a GitLab CI/CD configuration?

- `gitlab-ci.yaml`
  - GitLab specifically looks for a hidden file starting with a dot to identify the configuration.
- **`.gitlab-ci.yml`** ✅
  - This is the default filename GitLab looks for in the repository root to trigger pipelines.
- `.gitlab-pipelines.yml`
  - While "pipelines" is the common term, the file naming convention strictly uses "ci".
- `ci-config.yml`
  - This is a generic name; GitLab requires the specific .gitlab-ci.yml format by default.

**Hint:** It starts with a dot and uses YAML extension.

### 2. What is a GitLab "Runner"?

- A command-line tool for local repository debugging
  - The GitLab CLI exists for local tasks, but the Runner is an execution agent for CI/CD.
- **An application that executes jobs defined in a pipeline** ✅
  - The Runner is the agent that picks up jobs from the GitLab server and runs them on a host.
- A background service that monitors server performance
  - Monitoring is handled by tools like Prometheus, while the Runner focuses on job execution.
- A specialized web browser for testing UI components
  - Runners execute browser-based tests, but the Runner itself is a backend execution service.

**Hint:** The engine that runs the code.

### 3. By default, how do jobs in the same "stage" execute in GitLab?

- Sequentially in the order they are written in YAML
  - Sequential execution is the default for different stages, not for jobs within the same stage.
- **In parallel as long as there are available runners** ✅
  - GitLab attempts to run all jobs in a single stage simultaneously to minimize pipeline duration.
- One at a time based on the alphabetical name of the job
  - Alphabetical ordering is not used for execution; GitLab prioritizes parallel resource allocation.
- Only after the first job in the stage has completed
  - Jobs in a stage do not have inter-dependencies by default and start at the same time.

**Hint:** Think about speed and efficiency.

### 4. What does the "stages" keyword define at the top of the YAML file?

- The permissions levels for different project members
  - Permissions are managed in the GitLab UI Settings, not within the CI/CD YAML configuration.
- **The execution order and grouping of pipeline jobs** ✅
  - Stages organize jobs into a logical sequence, such as Build, then Test, then Deploy.
- The list of external servers used for job distribution
  - Server distribution is handled by Runner tags and configuration, not the stages keyword.
- The version requirements for the GitLab Runner service
  - Runner versioning is independent of the pipeline stages defined in the YAML file.

**Hint:** The order of operations.

### 5. What is an "Artifact" in GitLab CI/CD?

- A snapshot of the Git history used for rollbacks
  - Rollbacks use Git tags or SHAs; artifacts are specifically files generated during a build.
- **A list of files generated by a job to be used later** ✅
  - Artifacts allow jobs in subsequent stages to access files (like binaries) created by previous jobs.
- A deprecated function that is no longer used in code
  - In programming, this is "legacy code"; in CI/CD, artifacts are useful build outputs.
- A temporary log file that is deleted after a job ends
  - Logs are stored in the database, while artifacts are files meant for persistence and reuse.

**Hint:** Passing data between stages.

### 6. How do you prevent a job from running unless a specific condition is met?

- By using the `condition:` block within the job scope
  - There is no "condition" keyword; GitLab CI uses "rules" or "only/except" for logic.
- **By using the `rules:` keyword to define logic** ✅
  - Rules allow you to specify if a job should run based on variables, branch names, or file changes.
- By using the `check-if:` syntax at the top level
  - The "check-if" syntax is not a valid GitLab CI/CD keyword for controlling job execution.
- By using the `validate:` property for shell commands
  - Validation is usually part of the "script" or "test" phase, not a job-level execution trigger.

**Hint:** The "rules" keyword.

### 7. What is the "Cache" keyword used for?

- To store sensitive API keys and login credentials
  - Secrets must be stored in CI/CD Variables to ensure encryption and security masking.
- **To persist project dependencies between pipeline runs** ✅
  - Caching allows runners to reuse downloaded libraries (like npm packages) to speed up execution.
- To save the final production build for public release
  - Final builds should be saved as Artifacts or in a Package Registry for long-term stability.
- To keep a record of the terminal output for auditing
  - Terminal output is saved as job logs automatically and is not related to the cache keyword.

**Hint:** Speeding up subsequent pipeline runs.

### 8. What is a "Shared Runner"?

- A runner that executes jobs from multiple Git branches
  - All runners can execute different branches; "shared" refers to project-level availability.
- **A runner available to all projects within an instance** ✅
  - Shared runners are maintained by administrators for use by any repository in the GitLab instance.
- A runner that uses a shared filesystem for every job
  - Runners typically use isolated filesystems for security; "shared" refers to the resource pool.
- A runner designed for collaborative live coding sessions
  - Live coding is a feature of IDEs or GitLab WebIDE, not a function of the CI Runner.

**Hint:** Available to all projects.

### 9. What does the "image" keyword specify in a job?

- The metadata tag for identifying the project owner
  - Owner metadata is managed in project settings, not within the "image" keyword of a job.
- **The Docker container used for the jobs environment** ✅
  - The image key tells the runner which container (e.g., node, python, alpine) to pull for execution.
- The graphical icon displayed in the pipeline dashboard
  - Dashboard icons are fixed by the GitLab UI and cannot be changed via the "image" YAML key.
- The visual screenshot captured during a failing test
  - Screenshots are artifacts; "image" refers to the runtime environment used by the Runner.

**Hint:** The container environment.

### 10. What is the "script" keyword in a job definition?

- A plain-text description of what the job performs
  - Descriptions are optional metadata; the "script" keyword is functional and executes commands.
- **A list of shell commands executed by the Runner** ✅
  - The script block contains the primary instructions and logic that the job must execute.
- A reference to an external JavaScript configuration
  - While you can run JS files, the "script" key itself is a YAML list of shell-level commands.
- A tool for generating automatic project documentation
  - Documentation is usually generated by running a tool within the script, not by the keyword itself.

**Hint:** The actual commands to run.

### 11. What are "CI/CD Variables" in GitLab?

- Dynamic counters that track the number of job failures
  - Failure counts are metrics, not variables. Variables store configuration and secret data.
- **Custom environment settings used for configuration** ✅
  - Variables allow you to store data like API keys or environment names outside of the YAML code.
- A list of files that change between different commits
  - Changes are tracked by Git diffs; variables are key-value pairs for the execution environment.
- The internal addresses of the GitLab Runner servers
  - Runner addresses are part of the runner registration and are not managed as CI/CD variables.

**Hint:** Secure environment settings.

### 12. What is a "Pipeline"?

- A connection between the database and the web server
  - This is an application architecture concept, not a GitLab CI/CD automation component.
- **A sequence of jobs organized into different stages** ✅
  - The pipeline is the complete set of automated steps triggered by a code change or event.
- A tool for managing the flow of developer communication
  - Communication is handled by Issues and Comments; pipelines automate the software lifecycle.
- A repository used specifically for storing binary files
  - Binary storage is handled by a Package Registry; pipelines are for processing and automation.

**Hint:** The top-level component of CI/CD.

### 13. What is the "allow_failure" keyword used for?

- To permit the deletion of a branch even if tests fail
  - Branch deletion is a Git permission setting, not controlled by job-level failure rules.
- **To let a pipeline continue despite a specific job error** ✅
  - Setting allow_failure to true prevents a non-critical job from stopping the rest of the pipeline.
- To disable the error reporting for a specific project
  - Errors are still reported and logged, but they do not cause the entire pipeline to fail.
- To automatically restart a job when it crashes
  - Automatic restarts are handled by "retry," while allow_failure manages the status of the run.

**Hint:** Non-critical job failure.

### 14. What does "when: manual" do in a job?

- It requires the Runner to be started by hand on a PC
  - Runners are background services; "manual" refers to triggering a job within an active pipeline.
- **It prevents a job from starting without user approval** ✅
  - Manual jobs stay in a "skipped" or "manual" state until a user clicks the play button in the UI.
- It forces the job to execute using a local shell executor
  - The executor is defined in the Runner configuration, not by the "when" keyword in the YAML.
- It disables all automated triggers for the entire pipeline
  - This only affects the specific job it is applied to, not the automation of the whole pipeline.

**Hint:** Human intervention.

### 15. What is a "GitLab Runner Executor"?

- A user role with the permission to cancel running jobs
  - Permission roles (like Maintainer) are different from technical "Executors" used by Runners.
- **The environment type where the pipeline job is run** ✅
  - Executors (like Docker, Shell, or Kubernetes) determine how the job isolation and environment are created.
- A security protocol for encrypting data between Runners
  - Communication is encrypted via TLS, but the Executor is about the local runtime environment.
- A script that cleans up artifacts after a build finishes
  - Cleanup is a function performed by the Runner service, while the Executor is the environment itself.

**Hint:** The environment type (Docker, Shell, etc.).

### 16. What is the "before_script" keyword?

- **A set of global commands that run before every job** ✅
  - The before_script block is used for repetitive setup tasks like logging into a registry or installing tools.
- A way to check for syntax errors before the YAML is saved
  - Syntax checking is done by the CI Lint tool in GitLab, not by the before_script keyword.
- A tool for managing the order of Git commits in a branch
  - Commit ordering is a Git management task (rebase/merge) and is not part of CI/CD job logic.
- A script that executes only when a pipeline is cancelled
  - Cleanup for cancelled jobs is handled by "after_script" or runner-level cleanup logic.

**Hint:** Preparation steps.

### 17. What is "Environment" management in GitLab CI/CD?

- A system for monitoring the hardware health of Runners
  - Hardware health is monitored by infrastructure tools; environments track software deployment targets.
- **A feature to track and manage software deployment targets** ✅
  - Environments allow you to see what is deployed to targets like Production, Staging, or QA.
- A configuration for the physical location of data centers
  - Physical locations are part of cloud provider settings, not GitLab CI/CD environment features.
- A method for calculating the carbon footprint of a build
  - While a noble goal, this is not a built-in feature of the GitLab Environment management system.

**Hint:** Tracking where code is deployed.

### 18. What is a "Downstream Pipeline"?

- A pipeline that has a lower priority in the runner queue
  - Priority is managed by queuing logic; downstream refers to a relationship between pipelines.
- **A pipeline triggered by a parent or external pipeline** ✅
  - Downstream pipelines are separate pipelines (in the same or different projects) initiated by a trigger.
- A pipeline used exclusively for deleting old build logs
  - Log deletion is a maintenance task; downstream pipelines are for modular automation flows.
- A pipeline that runs only on local developer machines
  - Local execution is handled by tools like "gitlab-runner exec," not the "downstream" keyword.

**Hint:** One pipeline triggering another.

### 19. What is the purpose of "Tags" in a job definition?

- To assign labels to a Git commit for version release
  - Those are Git Tags; CI/CD Tags are specifically for routing jobs to the correct Runners.
- **To ensure a job runs on a Runner with specific traits** ✅
  - Tags match jobs to runners that have those same tags (e.g., "ios", "high-cpu", or "production").
- To organize jobs into searchable categories in the UI
  - Search and organization are handled by job names and stages, not by technical Runner tags.
- To notify specific team members when a job starts
  - Notifications are managed via Integrations or Webhooks, not through the job tags system.

**Hint:** Matching jobs to specific Runners.

### 20. What does "needs" allow you to do in GitLab CI?

- To list the required hardware specs for a job
  - Hardware specs are determined by the Runner; "needs" is about job execution dependency.
- **To execute jobs out of stage order based on dependencies** ✅
  - The "needs" keyword creates a Directed Acyclic Graph (DAG), letting fast jobs skip stage-based waiting.
- To specify which users must approve a deployment
  - Approvals are managed in the Protected Environments or Merge Request settings, not via "needs."
- To define the external libraries required by the code
  - Libraries are handled by the package manager (npm, pip, etc.) within the script block.

**Hint:** Directed Acyclic Graph (DAG) pipelines.

### 21. What is the "Merge Request Pipeline"?

- A tool for combining multiple GitLab user accounts
  - Account merging is a profile management task and not related to CI/CD pipelines.
- **A pipeline that runs specifically on code in an MR** ✅
  - MR pipelines allow you to validate code changes in the context of a merge before they hit the main branch.
- A system for automatically rewriting code for developers
  - Pipelines test code but do not typically "rewrite" it unless using specialized linting scripts.
- A way to synchronize different repositories together
  - Synchronization is a Git mirroring task; MR pipelines are for validating specific code changes.

**Hint:** Testing changes before they are merged.

### 22. What is "GitLab Container Registry"?

- A database for storing raw text logs from all jobs
  - Logs are stored in internal job storage; the Registry is for binary container images.
- **A built-in service to store and manage Docker images** ✅
  - The Registry allows you to build, push, and pull container images directly within GitLab.
- A public forum for sharing open-source code snippets
  - Code sharing is the core function of GitLab itself; the Registry is for compiled containers.
- A tool for managing physical server hardware in a lab
  - This would be an Infrastructure Management tool, not a software container registry.

**Hint:** Storing Docker images within GitLab.

### 23. What does "dependencies: []" do in a job?

- It prevents the job from accessing any local Git files
  - Git files are provided by the Runner; "dependencies" only controls artifact downloads from other jobs.
- **It stops the job from downloading artifacts from others** ✅
  - Setting an empty list prevents the job from fetching artifacts, which can reduce job execution time.
- It indicates that the job requires no external software
  - Software requirements are defined by the "image" or "before_script," not by dependencies.
- It disables the network connection for the running job
  - Network access is controlled by the Runner executor settings, not by artifact dependencies.

**Hint:** Controlling artifact downloads.

### 24. What is a "Scheduled Pipeline"?

- A pipeline that only runs when a developer is offline
  - Pipelines do not track developer presence; they run based on code changes or schedules.
- **A pipeline set to run at specific intervals using cron** ✅
  - Scheduled pipelines allow you to automate repetitive tasks like nightly builds or weekly security scans.
- A way to predict the completion time of a project
  - Predicting time is a project management feature; schedules are for triggering automation.
- A tool for organizing developer shifts and meetings
  - This is a calendar or HR function, not a technical CI/CD pipeline feature.

**Hint:** Running jobs on a timer.

### 25. What is the "Parallel" keyword used for in a single job?

- To run a job on two different GitLab instances at once
  - Parallel works within a single pipeline context in one project, not across different instances.
- **To run multiple instances of a job for load balancing** ✅
  - The "parallel" keyword allows you to split a job (like a test suite) into multiple parallel runs.
- To execute the build and deploy stages at the same time
  - Concurrent stages are handled by DAG (needs) or custom stage names, not the "parallel" keyword.
- To allow two developers to edit the same YAML file
  - Collaboration is a function of Git and the WebIDE, not the "parallel" CI/CD keyword.

**Hint:** Splitting one task into many.

### 26. What is "Auto DevOps"?

- A system for automatically hiring and firing developers
  - This is not a feature; Auto DevOps focuses on automating the software development lifecycle.
- **A set of pre-built templates for automated CI/CD** ✅
  - Auto DevOps uses best-practice templates to build, test, and deploy applications without manual YAML.
- A tool for generating code comments using AI models
  - AI commenting is part of GitLab Duo/AI features, not the Auto DevOps automation suite.
- A method for driving automated test vehicles in a lab
  - While "Auto" is in the name, this feature is strictly for software pipeline automation.

**Hint:** Zero-configuration CI/CD.

### 27. What is "Variables: GIT_STRATEGY" used for?

- To define the branching model used by the project
  - Branching models (like GitFlow) are team practices, not controlled by this YAML variable.
- **To choose between "clone" or "fetch" for repository data** ✅
  - GIT_STRATEGY determines if the runner should download the whole repo or just the latest changes.
- To change the default merge behavior of pull requests
  - Merge behavior is controlled in Merge Request settings, not by the Runner fetch strategy.
- To hide the source code from specific Runner instances
  - Runners must have access to code to execute builds; masking code is not a function of GIT_STRATEGY.

**Hint:** Controlling how code is fetched.

### 28. What is "Review Apps"?

- A mobile application for rating developer performance
  - Rating developers is not a function of GitLab Review Apps; they are for reviewing code changes.
- **Dynamic environments for previewing changes in an MR** ✅
  - Review Apps spin up a temporary version of your app so stakeholders can test a feature before merging.
- A system for peer-reviewing technical documentation
  - Documentation review is done via Merge Request comments, not via "Review Apps."
- A tool for checking the spelling of Git commit messages
  - Spelling checks are done by linters or pre-commit hooks, not by the Review Apps system.

**Hint:** Dynamic environments for Merge Requests.

### 29. What does "interruptible: true" do?

- It allows the system to pause the build for maintenance
  - Maintenance pauses the whole runner queue; interruptible is about specific redundant jobs.
- **It lets new pipelines cancel redundant older jobs** ✅
  - If a new commit is pushed, older running jobs marked "interruptible" will be stopped to save resources.
- It makes the job stop whenever a developer logs in
  - Login status does not affect job execution; only pipeline events trigger interruptions.
- It forces the job to wait for manual user intervention
  - Waiting for users is the role of "when: manual," not the "interruptible" setting.

**Hint:** Optimizing for redundant builds.

### 30. What is the "GitLab-managed Terraform State"?

- A list of all physical servers owned by the company
  - Inventory is managed in CMDB tools; this feature is for Terraform infrastructure files.
- **A secure backend to store Terraform infrastructure data** ✅
  - GitLab provides a built-in state file host so you don’t need an external S3 bucket for Terraform.
- A tool for drawing network diagrams in the GitLab UI
  - Diagrams are made in design tools; the state file tracks technical infrastructure resources.
- A way to track the geographical location of Runners
  - Runner location is part of administrative metadata, not Terraform state management.

**Hint:** Infrastructure as Code integration.