# 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.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.product-security.expert/learning-labs-interview-and-templates/index-1/gitlab-mock-interview.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.