Browse Certification Practice Tests by Exam Family

GitLab Git Associate Sample Questions & Practice Test

Try 12 GitLab Certified Git Associate sample questions on repositories, branches, merge requests, issues, permissions, CI/CD basics, and collaborative DevOps workflow.

GitLab Certified Git Associate is the GitLab foundation route for candidates who need practical Git and GitLab workflow judgment: repositories, branches, merge requests, issues, permissions, CI/CD basics, and collaboration across development and operations teams.

This page is also useful if you search for “GitLab Certified Associate” and need the current GitLab foundation route before choosing deeper GitLab CI/CD or DevSecOps preparation.

Practice option: Sample questions available

GitLab Certified Git Associate practice update

Start with the 12 sample questions on this page. Dedicated practice for GitLab Certified Git Associate is not currently included as a full web-app practice page; enter your email to get updates when full practice becomes available or expands for this exam.

Need live practice now? See currently available IT Mastery exam pages.

Occasional practice updates. Unsubscribe anytime. We only publish independently written practice questions, not real, leaked, copied, or recalled exam questions.

GitLab Certified Git Associate snapshot

  • Vendor: GitLab
  • Credential family: GitLab certification
  • Current page status: Sample questions
  • Practice fit: repository workflow, branching, merge requests, issues, CI/CD awareness, permissions, and team collaboration
  • Best adjacent live practice: GitHub Foundations, GitHub Actions, CompTIA Linux+, and cloud DevOps routes

GitLab questions usually reward the option that keeps the repository auditable, protects shared branches, uses merge requests for review, and lets CI/CD validate changes before they reach protected environments.

What these questions test

  • GitLab repository and branch workflow
  • merge request review and approval reasoning
  • issue and milestone coordination
  • protected branch and permission choices
  • CI/CD pipeline and runner basics
  • secure collaboration habits for DevOps teams

Sample Exam Questions

Try these 12 original sample questions for GitLab Certified Git Associate. They are designed for self-assessment and are not official GitLab exam questions.

Question 1

What this tests: protected branch workflow

A team wants to prevent direct commits to main while still allowing developers to propose changes. Which GitLab workflow best supports this?

  • A. Give every developer Maintainer access and ask them not to push
  • B. Protect main and require changes to go through merge requests
  • C. Disable merge requests for the project
  • D. Store production code in an issue description instead of the repository

Best answer: B

Explanation: Protected branches restrict direct changes to important branches. Merge requests preserve review, discussion, CI/CD validation, and auditability before changes are merged.


Question 2

What this tests: merge request purpose

What is the main reason to use a merge request for a code change?

  • A. To permanently delete the source branch before review
  • B. To bypass pipeline checks
  • C. To hide changes from reviewers
  • D. To review, discuss, test, and merge a proposed change in a controlled workflow

Best answer: D

Explanation: A merge request is the collaboration and review surface for proposed changes. It supports comments, approvals, pipeline status, linked issues, and a visible merge decision.


Question 3

What this tests: issue tracking

A bug needs an owner, discussion, labels, and a target milestone before code work starts. Which GitLab feature is the best starting point?

  • A. Issue
  • B. Runner
  • C. Protected tag
  • D. Container registry

Best answer: A

Explanation: Issues track work, discussion, ownership, labels, milestones, and planning context. Runners execute jobs, tags mark commits, and registries store artifacts or images.


Question 4

What this tests: CI/CD pipeline trigger

A developer pushes a branch that contains a valid .gitlab-ci.yml file. What usually happens next?

  • A. GitLab converts the project into a wiki
  • B. GitLab deletes open issues
  • C. GitLab can create a pipeline based on the configured jobs and rules
  • D. GitLab automatically gives the developer Owner access

Best answer: C

Explanation: GitLab CI/CD reads .gitlab-ci.yml and creates pipeline jobs when the configured workflow conditions are met. Pipelines do not change project permissions or issue history.


Question 5

What this tests: runners

What is a GitLab Runner responsible for?

  • A. Approving every merge request
  • B. Picking up and executing CI/CD jobs
  • C. Replacing all repository branches with tags
  • D. Writing issue descriptions automatically

Best answer: B

Explanation: GitLab Runners execute CI/CD jobs assigned by GitLab. They may run shell, Docker, Kubernetes, or other executor types depending on configuration.


Question 6

What this tests: least-privilege access

A contractor needs to create merge requests and push to feature branches but should not change project settings or protected branches. Which access principle matters most?

  • A. Give the highest role to avoid blockers
  • B. Put the contractor in every group
  • C. Share a Maintainer account
  • D. Grant the minimum project role that supports the required work

Best answer: D

Explanation: GitLab access should follow least privilege. The role should support the required workflow without giving unnecessary control over settings, protected branches, or membership.


Question 7

What this tests: branch strategy

A developer is starting a small change for one issue. What is a common GitLab-friendly workflow?

  • A. Create a feature branch, commit the change, open a merge request, and link it to the issue
  • B. Edit main directly in production
  • C. Delete the issue before coding
  • D. Disable all pipeline jobs until release day

Best answer: A

Explanation: A feature branch plus merge request gives the team a reviewable, testable, and traceable change. Linking the issue connects planning context to the code change.


Question 8

What this tests: pipeline failure response

A merge request pipeline fails after a dependency update. What should happen before merging?

  • A. Ignore the failed pipeline because the branch name is correct
  • B. Merge first and troubleshoot later
  • C. Review the failed job output, fix the change or pipeline configuration, and rerun the pipeline
  • D. Delete the project labels

Best answer: C

Explanation: Pipeline failures are evidence. The team should inspect logs, fix the relevant code or CI/CD configuration, and rerun validation before merging into a protected branch.


Question 9

What this tests: labels and milestones

Why would a team use labels and milestones on GitLab issues?

  • A. To encrypt repository files
  • B. To organize, prioritize, and track work across releases or planning periods
  • C. To replace CI/CD runners
  • D. To make all branches protected automatically

Best answer: B

Explanation: Labels and milestones support planning, filtering, prioritization, and release tracking. They do not execute jobs or enforce branch protection by themselves.


Question 10

What this tests: merge conflict handling

A merge request cannot be merged because it conflicts with the target branch. What is the best next step?

  • A. Disable the target branch
  • B. Delete all comments on the merge request
  • C. Convert the repository to an issue board
  • D. Resolve the conflict by updating the source branch, then rerun relevant checks

Best answer: D

Explanation: Conflicts must be resolved in the source branch or through GitLab’s conflict-resolution tools when available. The updated branch should be validated again before merge.


Question 11

What this tests: auditability

Why is a merge request usually better than a private, out-of-band approval for a code change?

  • A. It keeps review comments, approvals, commits, and pipeline status connected to the change
  • B. It guarantees that no defects can exist
  • C. It removes the need for version control
  • D. It hides who approved the change

Best answer: A

Explanation: Merge requests create a visible record of discussion, review, approval, commits, and pipeline status. They improve traceability but do not guarantee defect-free code.


Question 12

What this tests: GitLab versus local Git

A developer commits locally but nobody else can see the change in GitLab. What is the most likely missing step?

  • A. Creating a project milestone
  • B. Changing the issue label
  • C. Pushing the local branch or commit to the GitLab remote
  • D. Adding a new runner

Best answer: C

Explanation: Local commits stay on the developer’s machine until pushed to the GitLab remote. Issues, labels, and runners do not publish local Git history.

GitLab workflow checklist

AreaStrong habitCommon trap
BranchesUse short-lived branches tied to issues or changesWorking directly on protected branches
Merge requestsKeep review, discussion, approvals, and pipeline status visibleTreating merge requests as paperwork after the change is already decided
PipelinesUse job logs and status as evidence before mergingIgnoring failed jobs because the code “looks small”
PermissionsGive users the role needed for their workSharing high-privilege accounts or over-granting Maintainer access
IssuesLink work to planning contextLosing why a change exists after the code is merged

Official sources

Revised on Monday, May 25, 2026