PS Product SecurityKnowledge Base

GitLab Mock Interview Pack

GitLab Mock Interview Pack Figure: GitLab security interview map.

Intro: This pack treats GitLab as a trusted delivery plane that can also become a privileged attack path. The scenarios are designed to test whether the candidate can explain runner trust, pipeline-definition control, secret hygiene, and release assurance without falling back on vague “best practices” language.

What this page includes

  • five scenario-based technical tasks for GitLab security
  • step-by-step solutions, common mistakes, and interviewer cues
  • emphasis on real tradeoffs rather than trivia

Working assumptions

  • strong answers connect remote code execution risk to branch protection, runner isolation, and artifact provenance

Task 1 - Shared non-ephemeral runners across trust boundaries

Scenario

A GitLab instance uses a shared self-managed runner pool for many projects. The runners are long-lived VMs. Some projects accept external contributions and some build internal release artifacts with non-production secrets.

Prompt

Explain the main risks and propose a safer target model.

Reveal the worked answer

What a strong candidate should notice

  • GitLab jobs execute user-controlled code.
  • Long-lived shared runners create cross-project persistence and secret-exposure risk.
  • External contributions and internal release jobs should not share the same execution lane.

Step-by-step solution

  1. Separate untrusted validation jobs from internal build and release jobs.
  2. Move sensitive jobs to isolated or ephemeral runners.
  3. Prevent untrusted merge requests from reaching privileged runner pools.
  4. Reduce runner network reach and protect metadata and internal services.
  5. Clean workspaces aggressively and review host persistence risks.

Detailed explanation

The candidate should be able to say plainly that GitLab is a remote code execution service. Once that is accepted, the runner host becomes part of the trusted computing base. Shared, non-ephemeral execution across trust boundaries is therefore a structural risk, not just a minor hardening issue.

Common mistakes

  • recommending only antivirus or VM patching;
  • assuming secrets are safe because they are masked in logs;
  • leaving external contributions on the same runner tier as internal deployment jobs.

Interviewer notes

A strong answer combines runner isolation, secret scope, and network segmentation.

Task 2 - Pipeline-definition bypass through weak review controls

Scenario

Developers must get approval for application code changes, but .gitlab-ci.yml and included CI templates are not treated as review-sensitive. A developer can merge pipeline changes after only minimal review.

Prompt

Why is this dangerous, and how would you fix the control model?

Reveal the worked answer

Step-by-step solution

  1. Explain that pipeline definitions control execution, secrets, artifacts, and deploy paths.
  2. Protect default and release branches.
  3. Make CI definitions and includes review-sensitive files.
  4. Separate who may approve application changes from who may approve production-deploy logic when needed.
  5. Capture release traceability from reviewed commit to reviewed pipeline to resulting artifact.

Explanation

The risk is not just “someone edits a YAML file.” The risk is that the YAML file defines what code runs, what secrets it can touch, and what environment it can change. That makes it part of the security boundary.

Common mistakes

  • relying only on branch protection without protecting the CI configuration itself;
  • treating included remote templates as implicitly trusted forever;
  • focusing on developer intent instead of blast radius.

Evaluation points

Look for candidates who understand that CI configuration is code with privileged consequences.

Task 3 - Protected variables still leak through poor job design

Scenario

A production deploy job uses protected variables, but the same pipeline also uploads debug artifacts and verbose logs. Teams are unsure whether protected variables alone solve the problem.

Prompt

Assess the risk and propose a safer design.

Reveal the worked answer

Step-by-step solution

  1. Confirm which jobs can access the variables and under what refs.
  2. Review artifact, log, and downstream-trigger behavior for accidental exposure.
  3. Minimize secret distribution to the smallest set of jobs possible.
  4. Prefer external secrets providers where practical.
  5. Redesign jobs so deploy credentials are consumed only in a narrow, approval-controlled lane.

Detailed explanation

Protected variables reduce exposure but do not make insecure job design safe. Secrets can still leak through scripts, artifacts, child pipelines, or mis-scoped jobs. The real question is how many execution paths can touch the secret at all.

Common mistakes

  • saying “masked means secure”;
  • ignoring downstream pipeline forwarding and artifact retention;
  • keeping the same secret available to build, test, and deploy jobs.

Interviewer notes

The best answers reduce both secret scope and the number of jobs that can interact with the secret.

Task 4 - Third-party includes and remote templates

Scenario

A team includes CI templates from an external repository maintained by another group. Updates are pulled automatically. There is no pinning to a reviewed commit or tag.

Prompt

What is the supply-chain risk, and how would you govern it?

Reveal the worked answer

Step-by-step solution

  1. Treat included templates as supply-chain dependencies with execution authority.
  2. Pin to reviewed versions or commits instead of floating references.
  3. Define ownership and change review expectations for shared templates.
  4. Test template updates in a lower-trust lane before broad rollout.
  5. Keep a rollback path and clear inventory of which projects inherit which template version.

Explanation

Remote CI includes can change what a project runs without any application-code diff in the target repository. That is powerful and useful, but it also means an upstream change may silently alter execution behavior across many projects.

Common mistakes

  • focusing only on package dependencies while ignoring CI templates;
  • assuming an internal upstream automatically means low risk;
  • failing to inventory inheritance relationships.

Task 5 - Release artifacts cannot be traced to a reviewed path

Scenario

Artifacts are published from a GitLab pipeline, but the organization cannot reliably show which commit, runner trust tier, approvals, and job definitions produced a release candidate.

Prompt

How would you improve release assurance?

Reveal the worked answer

Step-by-step solution

  1. Define what provenance evidence is required for a release.
  2. Restrict release jobs to protected refs and trusted runners.
  3. Preserve metadata linking artifact to commit, pipeline, runner class, and approvals.
  4. Require signed or otherwise verifiable handoff where the ecosystem supports it.
  5. Make the release lane small, explicit, and operationally different from general CI.

Why it matters

Without release traceability, teams struggle to prove that a release came from reviewed code and an approved delivery path. That weakens incident response, compliance evidence, and trust in the pipeline itself.

Common mistakes

  • treating artifact storage alone as provenance;
  • allowing many projects or branches to publish to the same trusted registry path;
  • mixing release and experimentation jobs in the same runner tier.