How does GitLab integrate license compliance checks into merge request pipelines?

By analyzing the merge request description for license mentions

By adding a license scanning job to the pipeline that runs automatically

By checking the project's LICENSE file during merge request creation

By requiring manual execution of a license scan before merging

A developer wants to see which licenses are used in a merge request before merging. They want to know if any new licenses were introduced. What should they look at?

The License Compliance widget in the merge request, which shows licenses detected in the changes.

The pipeline's test report, which shows unit test results.

The merge request's Changes tab, which shows code diffs.

The project's README file, which lists dependencies.

A company's legal team requires that any merge request introducing a new license not explicitly allowed must be manually approved by a legal reviewer before merging. They want to automate the detection but keep human oversight. What should they configure?

Add a license compliance policy that allows only approved licenses, and configure a merge request approval rule requiring approval from the legal group when the license report changes.

Set the license compliance policy to 'deny all licenses' and require approval from legal for any merge request that fails the policy.

Use a license compliance policy that warns on unapproved licenses, and rely on developers to manually request legal review.

Configure the License Compliance job to fail on any license not in the allowlist, and set the project to require two approvers for all merge requests.

A team wants to enforce license compliance but also wants to allow hotfixes to be merged quickly without waiting for the full license scan. They are considering making the License Compliance job `allow_failure: true` for the main branch pipeline. What is the risk of this approach?

The license compliance job will not run at all on the main branch.

The license compliance policy will be automatically disabled for the main branch.

The license compliance check will not block the merge, so a hotfix could introduce a non-compliant license without detection.

The license compliance report will not be generated for the main branch.

GitLabCertified Security Associate

Domain 6Objective 1

Enforce License Compliance GITLAB-CERTIFIED-SECURITY-SPECIALIST Practice Questions (Page 3)

Part of the License Compliance domain, which makes up ~10% of our current practice bank.

14questions here

3free pages

4concepts

Questions 11–14

11foundation · medium
How does GitLab integrate license compliance checks into merge request pipelines?
Select an answer first
12application · medium
A developer wants to see which licenses are used in a merge request before merging. They want to know if any new licenses were introduced. What should they look at?
Select an answer first
13application · medium
A company's legal team requires that any merge request introducing a new license not explicitly allowed must be manually approved by a legal reviewer before merging. They want to automate the detection but keep human oversight. What should they configure?
Select an answer first
14expert · hard
A team wants to enforce license compliance but also wants to allow hotfixes to be merged quickly without waiting for the full license scan. They are considering making the License Compliance job `allow_failure: true` for the main branch pipeline. What is the risk of this approach?
Select an answer first

Finished these 4 questions?

Review the revealed explanations, or continue through the curriculum.

No more pagesBack to GITLAB-CERTIFIED-SECURITY-SPECIALIST

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by GitLab. “GITLAB-CERTIFIED-SECURITY-SPECIALIST” is a trademark of its owner, used for identification only.