Interview Questions
Fundamentals
Pipelines
Runners
Security
Prepare for GitLab CI/CD interviews with the questions that come up most often. From fundamentals and pipeline design to runners, caching, and security, each question includes a clear answer and the reasoning behind it.
Interview
Answers
GitLab CI/CD
How to Use This Guide
GitLab CI/CD interviews test more than memorization. They test whether you understand how pipelines work, why certain design choices are made, and how you approach problems you haven't seen before. The questions in this guide are the ones that appear most often in real interviews, organized by topic. Each answer explains not just what the answer is, but why it matters and when it applies.
The best preparation is to practice answering out loud. For each question, try to give a two-minute answer without notes. Then check the answer in this guide and see what you missed. The gaps are what to study. For behavioral or scenario questions ("Tell me about a time when..."), the STAR method (Situation, Task, Action, Result) works well — it gives the interviewer a structured answer that's easy to follow .
Don't try to memorize every answer. Instead, understand the principles: how GitLab evaluates .gitlab-ci.yml, how runners pick up jobs, how caching differs from artifacts, how security controls work. With the principles clear, you can reason through questions you haven't seen before. That's what interviewers are actually looking for — not a dictionary of facts, but a mental model that produces correct answers.
Interview Tip: When you don't know an answer, say so and explain how you'd find out. "I haven't used that feature, but I'd check the GitLab docs and test it in a small project" is a better answer than a confident guess.
Fundamentals
What is GitLab CI/CD, how pipelines work, the role of .gitlab-ci.yml, stages and jobs.
Pipelines
DAG, needs, caching vs artifacts, rules, workflow, parent-child pipelines.
Runners
Executors, tags, shared vs specific runners, scaling, troubleshooting.
Security
Protected variables, OIDC, CI_JOB_TOKEN, protected environments, scanning.
Fundamentals
Fundamentals questions test whether you understand the basic model: GitLab reads a YAML file, builds a pipeline, and assigns jobs to runners. These are the questions that open most interviews. Answering them confidently sets the tone for the rest of the conversation.
# Q: What is GitLab CI/CD?
# A: GitLab's built-in continuous integration and delivery platform.
# It runs pipelines defined in .gitlab-ci.yml on runners.
# Pipelines build, test, and deploy code automatically.
# Everything lives in one application (no external CI server).
# Q: What is .gitlab-ci.yml?
# A: The configuration file that defines the pipeline.
# Lives at the repository root.
# Contains stages, jobs, scripts, rules, variables.
# GitLab reads it on every push and creates a pipeline.
# Q: What are stages, jobs, and pipelines?
# A:
# Pipeline: the entire CI/CD run (all stages, all jobs).
# Stage: a group of jobs that run in parallel.
# Job: a single unit of work (a script, an image, artifacts).
# Stages run sequentially; jobs within a stage run in parallel.
# Q: How does GitLab trigger pipelines?
# A: On push, merge request, schedule, tag, or manual/API trigger.
# GitLab detects the event, reads .gitlab-ci.yml, creates a pipeline.
# Runners pick up jobs based on tags and availability.
# Q: What is a runner?
# A: A lightweight agent that executes jobs.
# Can be shared (all projects), group, or specific (one project).
# Installed on your infrastructure or GitLab's shared runners.
# Uses executors (docker, shell, kubernetes) to run jobs.
# Q: What is the difference between a stage and a job?
# A: A stage groups jobs; a job is the actual work.
# All jobs in a stage must finish before the next stage starts.
# Jobs in the same stage run in parallel.
# Jobs define script, image, artifacts, and rules.
Pipelines and Configuration
Pipeline questions test whether you can design a pipeline that's fast, safe, and maintainable. The most common topics are needs (DAG), the difference between cache and artifacts, and how rules control when jobs run. These are the questions that separate candidates who've only used GitLab from candidates who've thought about how to use it well .
# Q: What is the difference between cache and artifacts?
# A:
# Cache: speeds up jobs. Stores dependencies (node_modules, .m2).
# Stored on runner. Not guaranteed. Reused across pipelines.
# Artifacts: passes files between jobs. Stores build outputs.
# Stored in GitLab. Guaranteed. Passed within the pipeline.
# Use cache for dependencies; use artifacts for outputs.
# Q: What is the needs keyword?
# A: Creates a DAG (directed acyclic graph) of jobs.
# Lets a job start as soon as its dependencies finish,
# without waiting for the entire stage.
# Speeds up pipelines by breaking the stage barrier.
# Example:
# test:
# needs: [build] # Starts when build finishes
# Q: How do you make a job run only on the main branch?
# A: Use rules.
# deploy:
# rules:
# - if: $CI_COMMIT_BRANCH == "main"
# Q: What is workflow:rules?
# A: Controls whether the entire pipeline runs.
# Evaluated before any jobs.
# If workflow:rules says "never", no pipeline is created.
# Used to run pipelines only for MRs, main, and tags.
# Q: How do you avoid duplicate pipelines?
# A: Use workflow:rules with $CI_OPEN_MERGE_REQUESTS.
# workflow:
# rules:
# - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
# when: never
# - if: $CI_COMMIT_BRANCH
# - if: $CI_PIPELINE_SOURCE == "merge_request_event"
# Q: What is include?
# A: Imports configuration from other files, projects, or URLs.
# Splits a large .gitlab-ci.yml into smaller files.
# Example:
# include:
# - local: '/ci/build.yml'
# - project: 'templates/ci'
# ref: 'v1.0.0'
# file: '/templates/test.yml'
# Pin ref to a commit SHA for reproducibility.
# Q: What is extends?
# A: Inherits configuration from a hidden job (starts with .).
# Eliminates duplication of shared settings.
# Example:
# .test_base:
# image: node:18
# before_script: npm ci
# test_unit:
# extends: .test_base
# script: npm test
Runners and Execution
Runner questions test whether you understand how jobs actually execute. The most common topics are executors (Docker vs shell vs Kubernetes), tags (how jobs are matched to runners), and troubleshooting stuck jobs. These questions often come up in scenario form: "A job is stuck in pending, what do you do?" .
# Q: What are the common executors?
# A:
# Docker: runs each job in a container. Isolated, reproducible.
# Shell: runs directly on the host. Fast, no isolation.
# Kubernetes: runs each job as a pod. Scalable, cloud-native.
# Docker Machine: auto-scales runners on cloud VMs.
# Docker is the most common default.
# Q: What are tags used for?
# A: Matching jobs to runners.
# A job with tags: [docker] only runs on runners with the docker tag.
# Used to direct jobs to specific runners (architecture, capabilities).
# If no runner has the tag, the job stays pending.
# Tags are the primary mechanism for runner selection.
# Q: What is the difference between shared and specific runners?
# A:
# Shared: available to all projects in the instance.
# Group: available to all projects in a group.
# Specific: available only to one project.
# Shared runners are convenient; specific runners are isolated.
# Q: A job is stuck in pending. How do you debug?
# A:
# 1. Check if any runner has the job's tags.
# 2. Check if the runner is online and not paused.
# 3. Check if the runner is at capacity (concurrent limit).
# 4. Check if shared runners are enabled (if relying on them).
# 5. Check the runner service is running.
# The error message usually names the missing tag.
# Q: What is the CI_DEBUG_TRACE variable?
# A: Enables verbose logging in job logs.
# Shows commands, environment variables, and shell expansions.
# Useful for debugging, but exposes secrets.
# Use temporarily, never as a permanent setting.
# Restrict to Developer+ role (not runner-level).
# Q: How do you speed up a slow pipeline?
# A:
# 1. Use needs (DAG) instead of sequential stages.
# 2. Cache dependencies with lockfile key.
# 3. Shard tests with parallel.
# 4. Use parallel:matrix for version matrices.
# 5. Build once, promote artifact (don't rebuild).
# 6. Use needs: [] for linting that doesn't need build.
# 7. Mark jobs interruptible when safe.
Security and Compliance
Security questions test whether you understand the trust boundaries in CI/CD. The most common topics are protected variables, OIDC, CI_JOB_TOKEN scoping, and protected environments. These questions often come up in scenario form: "Secrets are exposed in logs, what do you do?" or "How do you prevent a feature branch from accessing production credentials?" .
# Q: How do you protect secrets in CI/CD?
# A:
# 1. Never commit secrets to .gitlab-ci.yml.
# 2. Use masked CI/CD variables (hidden in logs).
# 3. Use protected variables (only on protected branches).
# 4. Scope variables to environments (production vs staging).
# 5. Use a secrets manager (Vault, OIDC) for production.
# Q: What is a protected variable?
# A: A CI/CD variable only available on protected branches/tags.
# Prevents feature branches from accessing production secrets.
# Feature branch pipelines see an empty value.
# Combined with masked, it's the minimum for sensitive data.
# Q: What is OIDC and why use it?
# A: OpenID Connect. Keyless authentication to cloud providers.
# GitLab generates a short-lived JWT per job.
# The cloud provider verifies it and returns temporary credentials.
# No long-lived secrets stored in GitLab.
# Example:
# id_tokens:
# AWS_ID_TOKEN:
# aud: https://gitlab.example.com
# script:
# - aws sts assume-role-with-web-identity ...
# Q: What is CI_JOB_TOKEN and how do you scope it?
# A: A token automatically provided to every job.
# Grants access to the project's API and registry.
# By default, limited to the project.
# Use allowlist to permit specific other projects.
# Settings > CI/CD > Token Access.
# Q: What is a protected environment?
# A: An environment (e.g., production) with restricted access.
# Only specified roles/users can deploy to it.
# Can require approvals before deployment.
# Combined with protected branches, restricts who can deploy.
# Settings > CI/CD > Protected environments.
# Q: Secrets are exposed in CI logs. What do you do?
# A:
# Immediate: Rotate the exposed secret.
# Preventive:
# 1. Mark the variable as masked.
# 2. Mark as protected (if production).
# 3. Check scripts for echo/print of variables.
# 4. Use CI_DEBUG_TRACE sparingly.
# 5. Audit logs for other exposures.
# Q: What security scanners does GitLab offer?
# A:
# SAST: static analysis of source code.
# DAST: dynamic analysis of running app.
# Dependency Scanning: checks libraries for CVEs.
# Secret Detection: finds credentials in git history.
# Container Scanning: checks images for OS vulnerabilities.
# IaC Scanning: checks Terraform/K8s for misconfigurations.
# All enabled via include: template.
Scenario Questions
Scenario questions test judgment, not recall. The interviewer describes a situation and asks what you'd do. There's often no single right answer — they want to see how you think, what you prioritize, and whether you consider trade-offs. The STAR method (Situation, Task, Action, Result) works well for behavioral scenarios .
For technical scenarios, the approach is: identify the layer (configuration, runner, execution, or security), propose a diagnostic step, then propose a fix. Interviewers want to see that you debug systematically rather than guessing. Even if your fix is wrong, a clear diagnostic process is a strong signal.
# Scenario: "A pipeline works locally but fails in CI."
# Approach:
# 1. Check the error message (first error, not last).
# 2. Check environment differences (versions, variables, paths).
# 3. Reproduce locally with the same image.
# 4. Check for missing dependencies or permissions.
# 5. Use CI_DEBUG_TRACE if the error is unclear.
# Scenario: "Secrets are exposed in a job log."
# Approach:
# 1. Rotate the secret immediately (it's compromised).
# 2. Identify how it was exposed (echo, debug trace, script).
# 3. Mark the variable as masked.
# 4. Mark as protected (if production).
# 5. Audit other logs for exposure.
# 6. Add a lint rule to prevent echo of secrets.
# Scenario: "A job is stuck in pending."
# Approach:
# 1. Check the error message (names the missing tag).
# 2. Verify a runner with that tag is online.
# 3. Check if the runner is paused or at capacity.
# 4. Check if shared runners are enabled.
# 5. Check the runner service status.
# Scenario: "A deployment failed and left the app broken."
# Approach:
# 1. Roll back to the previous deployment (GitLab environment rollback).
# 2. Verify the rollback succeeded (health checks, smoke tests).
# 3. Identify the root cause (logs, diff).
# 4. Fix the cause, add a test to catch it.
# 5. Redeploy with the fix.
# Scenario: "How would you design CI/CD for a microservices app?"
# Approach:
# 1. Parent-child pipelines for independent services.
# 2. Each service has its own pipeline (build, test, deploy).
# 3. Shared templates via include (pinned to SHA).
# 4. Independent deployment per service.
# 5. Multi-project pipelines for cross-service dependencies.
# 6. Centralized security scanning and compliance.
# Scenario: "Pipeline time increased significantly. What do you do?"
# Approach:
# 1. Check CI/CD Analytics for duration trends.
# 2. Identify the slowest jobs (job duration metrics).
# 3. Check if cache hit rate dropped.
# 4. Check if new jobs were added without needs.
# 5. Apply optimizations: needs, cache, parallel, build once.
Frequently Asked Questions
How should I prepare for a GitLab interview?
Practice answering out loud, not just reading. For each question, give a two-minute answer, then check what you missed. Focus on principles (how pipelines work, how runners pick jobs) rather than memorizing facts. Build a small project and use every feature you're asked about.
What's the most common mistake in GitLab interviews?
Confusing cache and artifacts. Know that cache is for dependencies (runner-stored, not guaranteed) and artifacts are for outputs (GitLab-stored, guaranteed, passed between jobs). This question comes up in almost every interview.
How do I answer scenario questions?
Use a diagnostic approach: identify the layer (config, runner, execution, security), propose a check, then a fix. Interviewers want to see systematic thinking, not a memorized answer. If you don't know the exact fix, explain how you'd find it.
What should I know about GitLab security?
Masked and protected variables, OIDC for cloud credentials, scoping CI_JOB_TOKEN, protected environments, and the five scanners (SAST, DAST, dependency, secret, container). These are the topics that come up most often.
How do I answer "Why do you want to work here?" for GitLab?
GitLab is remote-first and async-first. Mention that you've read their handbook, that you value written communication, and that you're comfortable working independently. Their CREDIT values (Collaboration, Results, Efficiency, Diversity, Iteration, Transparency) are a good framework.
What if I don't know the answer?
Say so and explain how you'd find out. "I haven't used that feature, but I'd check the GitLab docs and test it in a small project" is a strong answer. It shows honesty and problem-solving, which is better than a confident guess.
What's the difference between GitLab CI and Jenkins?
GitLab CI is integrated into GitLab (same application, same UI). Jenkins is a separate server with plugins. GitLab uses YAML (declarative); Jenkins uses Groovy (scripted or declarative). GitLab is simpler to start; Jenkins is more customizable. Both are valid; the choice depends on the ecosystem.
How do I explain a complex pipeline I've built?
Start with the goal (what the pipeline delivers), then the stages (build, test, deploy), then the key decisions (why needs, why caching, why rules). End with the outcome (time saved, issues caught, deployments automated). Keep it under two minutes.