GitLab PM Associate common mistakes
GitLab PM Associate · Understand the traps and how to avoid them.
Treating issues, epics, and milestones as interchangeable labels, so a candidate assigns a milestone to group-level work or expects an epic to appear on an issue board scoped to a single project.
The three objects live at different scopes and serve different purposes: issues are the unit of work, milestones are time-boxed groupings that can span a project or a group, and epics aggregate issues across projects in a group. Candidates who learned GitLab from a single project never encounter epics, so they collapse the concepts.
What to do instead
Build a one-page scope table before the exam: object, where it lives (project vs group), what it groups, and what rolls up into it. Then practise one scenario per row, e.g. 'track a Q3 release across four projects' (group milestone plus epic) versus 'track one team's sprint' (project milestone).
Assuming a merge request merges automatically once pipelines pass, and being unable to explain why an approved MR is still open.
Candidates conflate 'pipeline succeeded' with 'mergeable'. Mergeability also depends on approval rules being satisfied, unresolved threads (when that setting is on), merge conflicts, draft status, and the project's merge method. The pipeline is only one gate.
What to do instead
Memorise the merge-check list as a sequence: conflicts resolved, required approvals obtained, no blocking threads, not a draft, pipeline status acceptable for the merge method. For each item, name the project setting that controls it.
Confusing the roles available at group level with those at project level, for example expecting a group Guest to be able to push code to a project inside that group.
Permissions are inherited downward from the group, and the same role name grants different abilities depending on the scope where it is assigned and on project feature visibility. Candidates memorise a single permission matrix and apply it everywhere.
What to do instead
Learn the default role ladder (Guest, Planner, Reporter, Developer, Maintainer, Owner) with one concrete capability boundary per step, and note that inherited group membership sets the ceiling for that user in child projects. Test your recall by predicting what a Reporter can do on an issue versus in a repository.
Describing CI/CD as a single file rather than a composed configuration, so a candidate cannot say which job runs when a project has both a root pipeline file and included templates.
Real GitLab pipelines are assembled from includes, templates, and rules; candidates who only wrote toy pipelines assume one file executes top to bottom. Questions about job ordering, overrides, and conditional jobs then feel arbitrary.
What to do instead
Practise reading a pipeline as a merge: list the include sources, then for each job identify its stage, its rules, and whether a later definition overrides an earlier one. Draw the resulting DAG on paper for a three-stage pipeline with one manual job.
Answering planning questions with a generic agile answer instead of the GitLab mechanism, e.g. saying 'the team tracks progress in a sprint board' when asked how iteration cadence is configured.
The exam tests product behaviour, not methodology. Candidates with Scrum or Kanban experience answer from habit and skip the specific object (iterations, iteration cadences, boards scoped to a milestone or iteration) that the question is probing.
What to do instead
For every planning concept you know, write the GitLab artefact beside it: sprint → iteration plus iteration cadence; backlog → issue list ordered by milestone and label; board columns → label lists. Answer questions by naming the artefact first, then the workflow.
Treating labels as free-text tags and missing that scoped labels (for example priority::high) enforce mutual exclusivity within their scope.
Labels look like simple tags, so candidates assume adding a second priority label stacks rather than replaces. Scoped labels are a distinct behaviour that changes how boards and filters behave, and it is easy to never have used them.
What to do instead
Remember the rule 'one value per scope': applying priority::high to an issue already labelled priority::low removes the old one. Then connect it to boards: a scoped label scope becomes a natural board column set, which is why teams use them for status.
Explaining code review as 'open an MR and wait for comments', omitting the mechanics that questions actually test: suggestions, draft MRs, approval rules, and squash or fast-forward merge settings.
Candidates review code informally in their own projects and never configure approval rules or merge methods, so they answer from the happy path and miss the configurable behaviours the exam targets.
What to do instead
Walk one merge request end to end and name each lever: draft for work in progress, a suggested change applied from the diff, an approval rule requiring two approvals, and the merge method chosen in project settings. Be able to say what each lever changes about the merge outcome.
Reading a pipeline graph or job log only at surface level, so the candidate cannot state why a downstream job did not run when an upstream job failed or was allowed to fail.
Delivery visibility questions require reading status propagation: needs and stage ordering determine what runs, and allow_failure changes whether a failure blocks the pipeline. Candidates who never debugged a pipeline read the graph as a simple list.
What to do instead
Learn the status vocabulary (success, failed, warning, manual, skipped, canceled) and the rule that a failed blocking job halts later stages while a failed allowed-to-fail job yields a warning. Practise with one failing test job and one optional lint job and predict the overall pipeline result.
Assuming every GitLab feature is available at every licence tier, and answering a tier-dependent question as if the feature were universal.
Many planning and governance features sit above the free tier, and candidates who only used one edition generalise from their own environment. The exam expects awareness that capability depends on the subscription tier.
What to do instead
Keep a short tier-awareness note for the features you study: for each, record whether it is core or paid-tier. When a question hinges on a paid capability, say so in your reasoning rather than guessing the behaviour.
Confusing a fork-based workflow with a branch-based workflow, and describing merge request target branches incorrectly when the source is a fork.
Both produce merge requests, so the visible artefact looks identical. The difference is where the branch lives and which project hosts the MR, and candidates who always worked in branches never internalised the fork case.
What to do instead
State the distinction as a sentence you can recite: in a branch workflow the MR is raised inside the same project; in a fork workflow it is raised from the fork back to the upstream project. Then note the consequences for pipeline minutes and permissions.