GitLab Certified Associate Exam Preparation

Earning the GitLab Certified Associate credential validates your ability to use the GitLab platform for modern DevOps workflows. This certification focuses on practical, hands-on knowledge of GitLab's core CI/CD capabilities, project management, and integrated security features, signaling to employers that you can effectively contribute to automated software delivery pipelines.

Core GitLab CI/CD Concepts and Pipeline Configuration

At the heart of GitLab's automation is its CI/CD system, which you control through a file named .gitlab-ci.yml placed in your repository's root. This file defines the entire pipeline—a series of steps that run automatically on code changes. You must understand its syntax and structure. A pipeline is composed of stages (e.g., build, test, deploy), which run in sequential order. Within each stage, you define one or more jobs, which are the individual units of work that execute scripts.

For example, a basic pipeline configuration looks like this:

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Compiling the code..."

test_unit:
  stage: test
  script:
    - echo "Running unit tests..."

Here, build_job runs in the build stage, and only after it succeeds will test_unit in the test stage begin. A critical exam concept is the difference between artifacts and cache. You use artifacts to save output files (like compiled binaries) from a job and pass them to jobs in later stages. Conversely, cache is used to store dependencies (like npm packages) to speed up subsequent pipeline runs, but it is not guaranteed to be available and can be overwritten.

Runner Configuration and Pipeline Execution

Jobs do not run on GitLab's servers by default; they are executed by runners. A runner is a lightweight agent that picks up jobs from the GitLab instance. You need to know the types: shared runners (managed by GitLab.com or instance administrators) and specific runners (registered to a specific project or group). For the exam, understand how to register a runner and how tags work: you can tag a runner (e.g., docker, linux) and then in your .gitlab-ci.yml, direct jobs to runners with those specific tags using the tags: keyword.

Pipeline execution is event-driven. It typically triggers on a push to a branch or the creation of a merge request. You can control this with rules. For instance, you might configure a deploy job to only run for the main branch. A key troubleshooting skill is interpreting pipeline graphs and job logs to diagnose failures, which is a common exam scenario.

Merge Request Workflows and Branch Strategies

GitLab is built around the merge request (MR), the core vehicle for code review and collaboration. The certification tests your understanding of a complete MR workflow: creating a feature branch, pushing code, opening an MR, and using GitLab's tools to facilitate review. This includes code review processes like inline commenting, thread resolutions, and approvals.

Underpinning this workflow is a branch strategy. GitFlow or trunk-based development are common patterns, but GitLab often facilitates a simpler protected branch model. You should know how to protect the main branch by requiring merge requests, approvals, and successful pipeline completion before code can be merged. This ensures quality and prevents broken code from reaching production.

Integrated Platform Features: Registry, Packages, and Security

Beyond CI/CD, GitLab provides an integrated ecosystem. The GitLab Container Registry is a private space to store Docker images. Your pipelines can build and push images to this registry using CI/CD jobs, which are then available for later deployment stages.

Similarly, package management features allow you to create project-specific or instance-wide repositories for various package types (e.g., npm, Maven, PyPI). This centralizes dependencies and streamlines development.

A major focus for modern DevOps is shifting security left. GitLab's built-in security scanning features are crucial. You should be familiar with how these scanners run automatically in the test stage of a pipeline. These include Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Dependency Scanning, and Container Scanning. The exam will test your knowledge of how to enable these features (often via CI/CD templates or configuration) and how to interpret their findings, which appear in the Merge Request widget and the Security Dashboard.

Project Management and Administration Fundamentals

While heavily CI/CD focused, the Associate exam covers essential project management within GitLab. This includes configuring project settings, managing members and permissions, and using issues, milestones, and epics to track work. You should understand the role of CI/CD variables: where to set them (project, group, or instance level), how to mask them to protect secrets, and how they are made available to jobs.

Another practical skill is pipeline management: knowing how to manually run, retry, or cancel pipelines and jobs. For scheduling pipelines, you use the CI/CD Schedules feature, which is vital for regular maintenance or reporting tasks.

Common Pitfalls

1. Misunderstanding Artifacts vs. Cache: A frequent error is using cache for build outputs that need to be passed between stages. Remember: use artifacts to pass files to downstream jobs; use cache for temporary speed boosts on dependencies.
2. Overlooking Job Dependencies: If Job B requires an artifact from Job A, they must be in sequential stages, or you must explicitly define the dependency using dependencies:. Jobs in the same stage run in parallel and cannot share artifacts directly.
3. Incorrect Runner Tagging: If a job is tagged with [linux, docker] but the only available runner is tagged only [linux], the job will hang indefinitely, waiting for a compatible runner. Always verify runner tags match job requirements.
4. Ignoring Pipeline Security: Storing secrets in .gitlab-ci.yml instead of using protected CI/CD Variables is a critical security misstep. The exam expects you to know to use the project settings to define variables, especially masked ones for passwords and API keys.

Summary

• Master the .gitlab-ci.yml file: You must be fluent in defining stages, jobs, script, artifacts, and cache to construct effective CI/CD pipelines.
• Understand the GitLab Runner model: Know the difference between shared and specific runners, how tags control job execution, and how to diagnose runner-related pipeline failures.
• Leverage Merge Requests and Protected Branches: The merge request is the centerpiece of collaboration. Implement branch protection rules that require MRs, approvals, and pipeline success to enforce code quality.
• Utilize Integrated DevOps Features: Use the GitLab Container Registry for images, package repositories for dependencies, and built-in security scanners (SAST, DAST) to automate security checks within your pipeline.
• Manage Projects and Pipelines Practically: Configure CI/CD variables securely, schedule pipelines, and know how to navigate the GitLab UI to manage projects, members, and running pipelines.