GitLab PM Associate case studies

GitLab PM Associate · Put your knowledge to work in context.

The GitLab PM Associate credential is presented here as a study target for people who plan, track, and report on work inside GitLab. This page is an independent preparation resource. It is not affiliated with, endorsed by, or operated by GitLab, and it does not reproduce any official exam content. The material is organized around four domains of equal weight: GitLab platform fundamentals, planning and project management, source code and collaboration workflows, and CI/CD and delivery visibility. Topics on this exam: GitLab platform fundamentals, Planning and project management, Source code and collaboration workflows, and CI/CD and delivery visibility. The GitLab PM Associate case studies are 5 cases and about 3,205 words.

Inherited group membership and a contractor’s 404

Your company has a top-level group acme with subgroups platform and data . The data subgroup contains project etl-pipeline . A contractor, Priya, needs to read code and comment on issues in etl-pipeline only. An administrator adds her as Guest to acme because Guest is read-only.

618 words, about 3 min 2

Iteration burndown distorted by late scope and carryover

Team of nine runs two-week iterations. At iteration start, 26 issues are assigned, total weight 61. On day 4, the product manager adds 9 issues (weight 18) for a customer escalation that cannot wait. On day 7, four issues are moved to the next iteration without changing labels.

635 words, about 3 min 3

Protected branch and approval gaps under audit

Six engineers maintain payments-api . main is protected, but Maintainers may push directly; two Maintainers do so for hotfixes. Merge requests require one approval from anyone. The project does not reset approvals when new commits are added.

640 words, about 3 min 4

Production deployments counted by job retries

orders-service deploys to staging automatically on every merge to main . Production deploys are manual jobs in the same pipeline, started by a release manager who runs a wrapper script from a laptop. The team counts deployment frequency by counting successful production jobs, but the release manager often re-runs the same job after a failed deploy, so one release can produce two or three records. Lead time is measured from first commit to production job start.

653 words, about 3 min 5

Board, cross-project closure, and epic rollup before OKR review

Group checkout contains projects web , api , and infra . Product managers maintain 18 epics at the group level and 120 open issues across the projects. The group issue board lists stage::deployed , but infra uses stage::deploy ; those issues sit in No stage. A cross-project merge request from web to api includes Closes api#42, but api#42 remains open after merge.

659 words, about 3 min