GitLab Platform Fundamentals
GitLab Platform Fundamentals
This domain tests how you navigate GitLab as a DevSecOps platform: how projects sit inside namespaces, how visibility changes who can see them, and how role-based permissions control actions. The exam expects you to choose the least-privileged role that still lets a person do the job.
Namespaces and visibility
- A project path is
namespace/project; a group can contain subgroups, and a project inherits membership from its parent group. - Visibility is Private (members only), Internal (any signed-in user), or Public (anyone). Group and instance settings can restrict what a project may choose.
- Personal namespaces are for individual work; group namespaces are for shared ownership and inherited permissions.
Roles and permissions
GitLab's standard roles form a ladder: Guest, Reporter, Developer, Maintainer, Owner. Owner is the highest role and can manage group-level settings. Developer can push code, create branches and merge requests, and run pipelines. Reporter is read-oriented: can view code and pipelines and comment, but cannot push. Maintainer can change project settings and protected branches. Guest has limited visibility and issue participation. Choose the least role that satisfies the task, and remember that group membership grants access to all projects in the group unless restricted.
Objects you will meet
Issues track work, merge requests propose code changes, labels classify both, milestones group work by time, and epics group issues at group level. The left sidebar is the main navigation; the project overview shows files, commits, and pipeline status.
Worked example
A contractor must read pipeline results and comment on issues, but must not push code. Reporter is the correct role. Guest is too limited for code and pipeline visibility; Developer would allow pushes and is excessive. The reasoning is least privilege plus the specific permissions needed: read code/pipelines and comment, no write to the repository.
Traps that cost marks
Do not assume Developer can edit project settings; that is Maintainer territory. Do not treat Internal as public internet access-it requires a GitLab account. Do not forget inheritance: adding someone to a subgroup project does not grant parent-group access, while parent-group membership does flow down. Do not confuse a personal namespace with a group namespace when planning shared work.