Why might you need to update a license approval policy in GitLab?

Because the policy expires after a certain number of days

Because licensing requirements can change, such as when a new license is added to a dependency

Because GitLab automatically changes policies every month

Because the policy must be updated to match the latest GitLab version

A large organization has multiple groups with different licensing requirements. The security team wants to enforce a baseline policy that denies 'GPL-3.0' across all groups, but allow individual groups to add exceptions for specific projects. What is the best way to achieve this?

Use a single policy at the instance level that denies GPL-3.0 and cannot be overridden.

Create a group-level policy at the top-level group that denies GPL-3.0, and allow subgroups to add exceptions.

Create a project-level policy for every project that denies GPL-3.0.

Create a separate policy for each group that denies GPL-3.0.

What is the primary purpose of a license approval policy in GitLab?

To automatically update the licenses of all project dependencies to approved versions

To define which software licenses are allowed or denied for use in projects, and to enforce those rules during merge requests

To replace the need for a legal review of any software license before it is used in a project

To generate a list of all open-source licenses used in the organization for legal record-keeping only

A company's legal team has decided to allow the BSD-3-Clause license, which was previously denied. The license approval policy currently denies BSD-3-Clause. What is the correct way to update the policy?

Change the action of the existing policy from 'block merge' to 'warn' for BSD-3-Clause.

Delete the existing policy and create a new one that allows BSD-3-Clause.

Create a new policy that allows BSD-3-Clause, leaving the old policy in place.

Edit the existing policy to remove BSD-3-Clause from the denied list and add it to the allowed list.

In GitLab, which licenses are considered 'denied' in a license approval policy?

Licenses that are explicitly listed as not allowed for use

Licenses that are not in the allowed list

Licenses that are only used in test dependencies

Licenses that are not yet approved by the legal team

GitLabCertified Security Associate

Domain 6Objective 2

Manage License Approval Policies GITLAB-CERTIFIED-SECURITY-SPECIALIST Practice Questions (Page 2)

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

20questions here

4free pages

7concepts

Questions 6–10

6foundation · easy
Why might you need to update a license approval policy in GitLab?
Select an answer first
7expert · hard
A large organization has multiple groups with different licensing requirements. The security team wants to enforce a baseline policy that denies 'GPL-3.0' across all groups, but allow individual groups to add exceptions for specific projects. What is the best way to achieve this?
Select an answer first
8foundation · easy
What is the primary purpose of a license approval policy in GitLab?
Select an answer first
9application · medium
A company's legal team has decided to allow the BSD-3-Clause license, which was previously denied. The license approval policy currently denies BSD-3-Clause. What is the correct way to update the policy?
Select an answer first
10foundation · easy
In GitLab, which licenses are considered 'denied' in a license approval policy?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back 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.