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
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.
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.
Try these 12 original sample questions for GitLab Certified Git Associate. They are designed for self-assessment and are not official GitLab exam questions.
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?
main and require changes to go through merge requestsBest 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.
What this tests: merge request purpose
What is the main reason to use a merge request for a code change?
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.
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?
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.
What this tests: CI/CD pipeline trigger
A developer pushes a branch that contains a valid .gitlab-ci.yml file. What usually happens next?
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.
What this tests: runners
What is a GitLab Runner responsible for?
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.
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?
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.
What this tests: branch strategy
A developer is starting a small change for one issue. What is a common GitLab-friendly workflow?
main directly in productionBest 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.
What this tests: pipeline failure response
A merge request pipeline fails after a dependency update. What should happen before merging?
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.
What this tests: labels and milestones
Why would a team use labels and milestones on GitLab issues?
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.
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?
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.
What this tests: auditability
Why is a merge request usually better than a private, out-of-band approval for a code 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.
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?
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.
| Area | Strong habit | Common trap |
|---|---|---|
| Branches | Use short-lived branches tied to issues or changes | Working directly on protected branches |
| Merge requests | Keep review, discussion, approvals, and pipeline status visible | Treating merge requests as paperwork after the change is already decided |
| Pipelines | Use job logs and status as evidence before merging | Ignoring failed jobs because the code “looks small” |
| Permissions | Give users the role needed for their work | Sharing high-privilege accounts or over-granting Maintainer access |
| Issues | Link work to planning context | Losing why a change exists after the code is merged |