Checkpoint Lab — GitLab Platform Foundations: GitLab.com, Self-Managed, Dedicated, Tiers, and Architecture

1. Checkpoint mission

Your goal is not to demonstrate every GitLab menu. Your goal is to prove that you can identify a GitLab resource, predict which layer an operation changes, observe the resulting state from more than one surface, diagnose a mismatch without escalating privileges, and clean up safely.

2. Preflight checklist

• Choose a unique project name such as platform-foundations-checkpoint.
• Confirm the selected namespace is your personal training namespace, not an employer or valuable group.
• Use only synthetic text. No passwords, PATs, SSH private keys, customer names, internal URLs, or proprietary source.
• Record the GitLab host: gitlab.com.
• Decide whether the project can safely be public. If not, use a private project and substitute the supplied API response fixture for the unauthenticated API step.
• Do not change protected refs, roles, runners, CI/CD variables, or security policies in this checkpoint.

3. Prediction ledger

Before creating anything, write these predictions in a local note:

4. Create the checkpoint project

Use the current GitLab create-project flow to create platform-foundations-checkpoint in your personal namespace. Initialize with a README. Record the resulting full URL and project ID if shown. Then inspect visibility, default branch, and initial commit SHA before cloning.

Do not infer that the default branch must always be main; GitLab can inherit a configured default branch name. Record what your project actually shows.

5. Clone, change, and verify the Git plane

git clone https://gitlab.com/YOUR_NAMESPACE/platform-foundations-checkpoint.git
cd platform-foundations-checkpoint

git remote -v
git branch --show-current
git rev-parse HEAD

printf '%s\n' \
  '# GitLab Platform Boundary' \
  '' \
  'Git plane: commits, refs, local working tree.' \
  'GitLab plane: project metadata, namespace, collaboration and automation.' \
  > platform-map.md

git add platform-map.md
git commit -m "docs: map Git and GitLab state"

# Prediction checkpoint: record this SHA before pushing.
git rev-parse HEAD
git status --short --branch

git push origin HEAD

Verify the pushed SHA in the GitLab commit/branch view. Your checkpoint notes should explicitly say that git commit changed local repository state and git push transferred objects/updated the remote ref.

6. Compare UI, Git, glab, and REST

# Local Git evidence
git remote -v
git branch --show-current
git rev-parse HEAD

# Public GitLab project evidence
curl --silent --show-error \
  "https://gitlab.com/api/v4/projects/YOUR_NAMESPACE%2Fplatform-foundations-checkpoint"

# Optional read-only glab evidence if already configured
glab auth status --hostname gitlab.com
glab repo view -F json

Build a compact evidence table with: host, path_with_namespace, namespace kind, visibility, default branch, local branch, local HEAD SHA, hosted latest SHA, and clone URL. Mark which tool proved each field.

7. Draw the trust-boundary diagram

flowchart TD
USER[GitLab user / browser] --> NS[Personal namespace]
NS --> PROJ[GitLab project]
PROJ --> META[Metadata / visibility / default branch]
PROJ --> REPO[Git repository]
LOCAL[Local Git clone] <-->|clone/fetch/push| REPO
API[REST GET] --> PROJ
GLAB[glab read-only\noptional] --> PROJ
PIPE[Future pipeline control plane] -. not used in Chapter 01 .-> PROJ
RUN[Future runner/executor] -. separate execution trust boundary .-> PIPE
REG[Future registry/artifacts] -. separate data identity .-> PROJ

Add one note for each offering: on GitLab.com GitLab operates the shared SaaS platform; on Dedicated GitLab operates a managed single-tenant service; on Self-Managed your organization operates the instance infrastructure and lifecycle.

8. Controlled failure drill

Trigger one safe failure by requesting the project with the slash unencoded:

curl -i \
  "https://gitlab.com/api/v4/projects/YOUR_NAMESPACE/platform-foundations-checkpoint"

Apply the diagnostic sequence: preserve status and URL → identify REST/project-identifier scope → compare with browser path → correct the project identifier to YOUR_NAMESPACE%2Fplatform-foundations-checkpoint → verify 200 OK and path_with_namespace.

Do not change visibility or create a token to solve a URL-construction failure.

9. Final verification checklist

• The full project path names the intended GitLab.com host and personal namespace.
• The API namespace.kind matches your expected namespace type.
• The GitLab default branch is recorded rather than assumed.
• git remote -v points to the same project.
• The local branch and HEAD are known.
• The latest pushed SHA is visible in GitLab.
• The REST response identifies the same path, visibility, and default branch.
• Optional glab output identifies the same project without exposing a token.
• You can explain why the API failure was a request-identity problem, not a Git failure.
• No paid feature, runner, CI variable, cloud credential, or Self-Managed administrator action was required.

10. Cleanup / rollback

First inspect the repository one last time and confirm it contains only the synthetic README and platform-map.md. If you want to retain the project for Chapter 02, leave it clearly named as a lab. If you are finished with it, use the current project settings to archive it where appropriate or delete it only after confirming the complete namespace/project path.

Local cleanup is separate from hosted cleanup. Removing the clone directory does not archive/delete the GitLab project, and archiving/deleting the GitLab project does not automatically remove your local clone.

11. What Chapter 01 adds to a production GitLab operating model

You now have the foundational invariant for the entire course: every operation is attached to a resource, scope, authority, and trust boundary. Later chapters add merge requests, approvals, CI/CD, runners, environments, registries, security scanners/policies, APIs/hooks, Kubernetes, and administration. The same method persists: classify the object, inspect current state, make the minimum authorized change, and verify independently.

Chapter 02 adds the missing identity layer: account security, two-factor authentication, SSH keys, access tokens, service accounts, and credential hygiene. Authentication will be taught separately from authorization so that “I can sign in” never becomes “I must be allowed to do this.”

Checkpoint questions

Chapter 01 summary

GitLab is a platform around Git, not a synonym for Git. You can now distinguish GitLab.com, Dedicated, and Self-Managed; separate offerings from Free/Premium/Ultimate tiers; identify personal/group namespace boundaries; map a project to its repository; observe state through UI, Git, glab, and REST; diagnose context errors without privilege escalation; and clean up disposable resources safely.

Official references

• GitLab Docs — Choose an offering and subscription tier
• GitLab Docs — GitLab Dedicated
• GitLab Docs — Namespaces
• GitLab Docs — Projects
• GitLab Docs — Groups
• GitLab Docs — Roles and permissions
• GitLab Docs — Projects REST API
• GitLab CLI — glab auth status
• GitLab CLI — glab repo view

• GitLab CLI — Authentication overview
• GitLab Docs — Default branch