GitLab nests instance, group, subgroup, and project. Issues, merge requests, and repositories belong to projects; epics and shared milestones belong to groups. Permissions inherit downward from group to project.

Owner is the highest role and exists only at group level, not project level. Owners manage group membership, group settings, and can delete the group.

A project marked Internal is visible to every authenticated user on the instance, including users outside the group. Anonymous users cannot see it.

Planner sits between Guest and Reporter. It can create and edit issues, boards, and milestones but cannot push code or view the repository contents.

A branch rule restricting who may push or merge into it. Allowed roles are configured per branch, and force push can be disabled to preserve history.

A token scoped to a single project, used by automation such as CI jobs. It carries a chosen role and expires on a configured date.

DevOps lifecycle stages

GitLab names ten lifecycle stages: plan, create, verify, package, secure, release, configure, and monitor, plus manage and defend in some documentation. Each maps to concrete features.

A milestone defined at group level and shared across every project in that group. Project milestones are visible only inside their own project.

Labels containing a double colon, such as priority::high. Only one label per scope may exist on an issue, so applying priority::low removes priority::high automatically.

Each board list is bound to a label. Dragging a card between lists adds the destination label and removes the source label from the issue.

Slash commands entered in an issue or merge request comment, such as /assign, /label, /close, or /due. They execute when the comment is submitted.

Epics group related issues across multiple projects inside a group. They exist at group level, so a standalone project without a group has no epics.

Time-boxed, sequential sprints scoped to a group. Unlike milestones, iterations cannot overlap and carry fixed start and end dates.

An issue visible only to project members with Reporter or higher. It is hidden from public search results and from users with Guest access.

Each issue can carry a numeric weight estimating effort. Weights sum automatically at the milestone and epic level to show total planned effort.

A link type marking one issue as blocked by another. Blocked issues display a warning and appear in dependency views such as the roadmap.

Merge request approvals

Rules requiring a set number of approvals before merge. Rules can be scoped to named users or groups and can be reset when new commits are pushed.

A queue that merges approved merge requests one at a time against the latest target branch, so each is tested against the combined result and semantic conflicts are avoided.

A merge request whose title starts with Draft: or WIP:. It cannot be merged until marked ready, signalling that work is still in progress.

A file mapping path patterns to owners. When code owner approval is required, matching paths need approval from those owners before merge.

A fork is a project copy under another namespace. Contributors push to their fork and open merge requests against the upstream project, which is standard for external contributors.

Project or group settings enforced before a push completes. They can reject commit messages by regex, block secret files, or require signed commits.

A merge option that collapses all commits from the source branch into a single commit on the target branch, keeping the target history linear.

Semi-linear merge method

A merge method that fast-forwards the target branch to the source branch and then adds a merge commit, producing a linear history with explicit merge points.

A button on merged merge requests that opens a new merge request reversing the original diff. It adds a commit rather than rewriting existing history.

CI/CD configuration file

The .gitlab-ci.yml file at the repository root defines pipelines. It declares stages, jobs, scripts, images, rules, artifacts, and caches in YAML.

A CI keyword evaluated top-down; the first matching rule decides whether a job runs. It replaces only/except and supports when: never to exclude jobs.

A CI keyword that makes a job start as soon as its named dependencies finish, ignoring stage order and forming a directed acyclic graph pipeline.

Artifacts versus cache

Artifacts are files saved after a job and passed to later stages; they are guaranteed for that pipeline. Cache persists paths across pipelines but is not guaranteed to exist.

A job declared with when: manual. It pauses the pipeline until a user triggers it. Adding allow_failure: true makes it optional and non-blocking.

Merge request pipeline

A pipeline that runs on the merge request source branch, configured with rules matching CI_PIPELINE_SOURCE equal to merge_request_event. It gates merges via status checks.

Named deployment targets such as staging or production. They record deployment history, support rollback to a prior deployment, and can be protected to restrict who deploys.

A downstream pipeline started by a job using the trigger keyword. It runs its own configuration file and appears nested under the parent pipeline.

GitLab PM Associate study materials

GitLab PM Associate flashcards

GitLab PM Associate · Build recall with a focused review session.

33 cards. Read the term and the definition here. The deck at the top of this page is optional.

Project hierarchy: GitLab nests instance, group, subgroup, and project. Issues, merge requests, and repositories belong to projects; epics and shared milestones belong to groups. Permissions inherit downward from group to project.
Owner role scope: Owner is the highest role and exists only at group level, not project level. Owners manage group membership, group settings, and can delete the group.
Internal visibility: A project marked Internal is visible to every authenticated user on the instance, including users outside the group. Anonymous users cannot see it.
Planner role: Planner sits between Guest and Reporter. It can create and edit issues, boards, and milestones but cannot push code or view the repository contents.
Protected branch: A branch rule restricting who may push or merge into it. Allowed roles are configured per branch, and force push can be disabled to preserve history.
Project access token: A token scoped to a single project, used by automation such as CI jobs. It carries a chosen role and expires on a configured date.
DevOps lifecycle stages: GitLab names ten lifecycle stages: plan, create, verify, package, secure, release, configure, and monitor, plus manage and defend in some documentation. Each maps to concrete features.
Group milestone: A milestone defined at group level and shared across every project in that group. Project milestones are visible only inside their own project.
Scoped labels: Labels containing a double colon, such as priority::high. Only one label per scope may exist on an issue, so applying priority::low removes priority::high automatically.
Issue board lists: Each board list is bound to a label. Dragging a card between lists adds the destination label and removes the source label from the issue.
Quick actions: Slash commands entered in an issue or merge request comment, such as /assign, /label, /close, or /due. They execute when the comment is submitted.
Epic scope: Epics group related issues across multiple projects inside a group. They exist at group level, so a standalone project without a group has no epics.
Iterations: Time-boxed, sequential sprints scoped to a group. Unlike milestones, iterations cannot overlap and carry fixed start and end dates.
Confidential issue: An issue visible only to project members with Reporter or higher. It is hidden from public search results and from users with Guest access.
Issue weight rollup: Each issue can carry a numeric weight estimating effort. Weights sum automatically at the milestone and epic level to show total planned effort.
Blocking issue links: A link type marking one issue as blocked by another. Blocked issues display a warning and appear in dependency views such as the roadmap.
Merge request approvals: Rules requiring a set number of approvals before merge. Rules can be scoped to named users or groups and can be reset when new commits are pushed.
Merge train: A queue that merges approved merge requests one at a time against the latest target branch, so each is tested against the combined result and semantic conflicts are avoided.
Draft merge request: A merge request whose title starts with Draft: or WIP:. It cannot be merged until marked ready, signalling that work is still in progress.
CODEOWNERS file: A file mapping path patterns to owners. When code owner approval is required, matching paths need approval from those owners before merge.
Fork workflow: A fork is a project copy under another namespace. Contributors push to their fork and open merge requests against the upstream project, which is standard for external contributors.
Push rules: Project or group settings enforced before a push completes. They can reject commit messages by regex, block secret files, or require signed commits.
Squash on merge: A merge option that collapses all commits from the source branch into a single commit on the target branch, keeping the target history linear.
Semi-linear merge method: A merge method that fast-forwards the target branch to the source branch and then adds a merge commit, producing a linear history with explicit merge points.
Revert merge request: A button on merged merge requests that opens a new merge request reversing the original diff. It adds a commit rather than rewriting existing history.
CI/CD configuration file: The .gitlab-ci.yml file at the repository root defines pipelines. It declares stages, jobs, scripts, images, rules, artifacts, and caches in YAML.
rules keyword: A CI keyword evaluated top-down; the first matching rule decides whether a job runs. It replaces only/except and supports when: never to exclude jobs.
needs keyword: A CI keyword that makes a job start as soon as its named dependencies finish, ignoring stage order and forming a directed acyclic graph pipeline.
Artifacts versus cache: Artifacts are files saved after a job and passed to later stages; they are guaranteed for that pipeline. Cache persists paths across pipelines but is not guaranteed to exist.
Manual job: A job declared with when: manual. It pauses the pipeline until a user triggers it. Adding allow_failure: true makes it optional and non-blocking.
Merge request pipeline: A pipeline that runs on the merge request source branch, configured with rules matching CI_PIPELINE_SOURCE equal to merge_request_event. It gates merges via status checks.
Environments: Named deployment targets such as staging or production. They record deployment history, support rollback to a prior deployment, and can be protected to restrict who deploys.
Child pipeline: A downstream pipeline started by a job using the trigger keyword. It runs its own configuration file and appears nested under the parent pipeline.