Free GitLab Certified Security Associate practice test: 30 questions with answers

The SAST excluded paths setting (SAST_EXCLUDED_PATHS) tells the analyzers to skip matching files while the rest of the project is still scanned. Disabling the template removes coverage for all code, deleting the directory on every run is fragile, and dismissing findings still runs the analysis on that code.

Dismissed is the state for findings the team has judged not to be real or not applicable, and a dismissal reason is recorded for audit. Confirmed is for real vulnerabilities, Detected is the initial state before triage, and Resolved means the finding has gone away after a fix.

Severity and confidence show how serious a finding is likely to be, and production reachability shows where the risk matters most, so high-severity findings in live code come first. Log order, lowest-first, and blanket assignment do not reflect the actual risk.

Scan execution policies enforce that defined security scans run in the pipelines of the projects they apply to, so project-level CI settings cannot simply switch them off. The other options describe approval rules, credential storage, and scheduled container scanning, which are not what scan execution policies do.

A scan execution policy defined in a security policy project and linked to the group enforces the required scans across its projects. A variable can be changed by maintainers, a pipeline requirement does not add the scans, and an approval rule does not run any scanner.

A security policy project holds policy definitions that are then linked to groups or projects, which apply them. The other options describe container image storage, branch replacement, and template sharing, none of which is the role of this project type.

The Container Scanning template analyzes a container image for known operating system package vulnerabilities, and it can be pointed at the image the build produces. DAST tests running applications, Secret Detection looks for credentials, and License Compliance reports license information rather than package vulnerabilities.

The analyzer reports known vulnerabilities in the operating system packages of the image, and those findings can be reviewed and dismissed in the vulnerability report. The analyzer does not rewrite images, and container scanning inspects the image itself, so the container does not need to be deployed first.

The Container Scanning analyzer authenticates to a private registry with the CS_REGISTRY_USER and CS_REGISTRY_PASSWORD variables, and CS_IMAGE selects which image is scanned. Making the registry public exposes images, committing tarballs bloats the repository, and DAST tests running web applications rather than registries.

Passive scanning inspects traffic and responses without sending attack payloads, so it is gentler on a target, while active scanning sends attack payloads and can change data. The other options invent run locations, authentication rules, or inputs that do not match how DAST works.

Authenticated DAST scans need an authentication configuration that logs the scanner in so it can reach pages behind the login. A longer timeout still stops at the login page, and container and dependency settings do not affect what the scanner can crawl.

A passive-only scanner profile observes responses without sending attack payloads, which suits a fragile environment. Enabling every active check is intrusive, and dependency or secret detection scans do not test a running site at all.

An SBOM lists the components, versions, and related metadata that a software product is built from, which helps teams find affected packages when a new advisory appears. The other options describe reviewer lists, approval records, and network rules rather than a component inventory.

Offline scanning depends on a local copy of the advisory data, while manifest and lock files in the repository are read locally. The other two options invent email-based input and a requirement for live internet access, which contradicts offline use.

Lock files pin the exact versions that a build installs, including indirect dependencies that a top-level manifest may not show, so matching against advisories is more precise. The other options misstate what lock files contain and how manifests work.

The token is exposed in history, so the value must be treated as compromised and rotated or revoked even though the file was cleaned. Ignoring it, excluding the file from SAST, or recreating the branch does not make the leaked value safe.

A credential that appeared in code should be assumed compromised, and deleting it from a later commit does not revoke it at the service that issued it. The other options misstate how Git history and provider access work.

Custom detection rules let a team teach the scanner a new credential format, and the scanner then applies them during scans. Comments, manual review alone, or renaming tokens to fit existing rules do not give consistent detection, and disabling the scanner removes coverage.

IaC scanning checks infrastructure-as-code files for misconfigurations, such as Terraform, CloudFormation, and Kubernetes definitions. Compiled binaries, app store packages, and backup archives are not infrastructure definitions.

A custom ruleset configuration in the repository can disable an individual rule while the remaining rules keep running, and the change is versioned and reviewable. Turning off the whole scanner or hiding files removes coverage, and dismissing repeatedly is manual work that does not change what the analyzer runs.

IaC scanning analyzes infrastructure-as-code definitions for insecure settings before they are deployed, such as publicly readable storage. Compiler versions, registry tag lengths, and reviewer membership are not infrastructure configuration problems.

License compliance identifies the licenses attached to dependencies so that restricted or unapproved licenses can be flagged. Contributor agreements, base image choice, and copyright text are separate concerns that this feature does not check.

A license policy that denies the license, combined with an approval rule, makes matching merge requests wait for review. A branch rule, an unrelated code owner entry, or a scheduled email does not block a denied license from being merged.

A denied license means the organization has decided that dependencies carrying it are not allowed, so matching dependencies are flagged. The other options describe internal-only use, automatic removal, or branch storage, which are not what a denied license means.

A security-based approval rule in a merge request approval policy is triggered by scan results, such as a severity threshold, so the extra approver is required when the condition is met. Role-based rules, blanket code owner entries, and push restrictions do not respond to the vulnerability findings in the merge request.

Role-based approvals name project roles whose members must approve, which gives a policy a reusable way to target reviewers. The other options invent clearance levels, group ownership rules, or self-approval, none of which describes this approval type.

Shift-left means running security practices such as scanning and threat review early in development, when fixes are typically cheaper. The other options move reporting or deployments to later points, and moving secrets into the repository is an unsafe practice.

Compliance frameworks and their reports give auditors a consistent view of controls across projects, which is stronger evidence than manually maintained notes. Calendar notes, wiki pages, and tag messages are manual records that are easy to omit or change.

API fuzzing can use an OpenAPI specification to discover the endpoints and parameters of the target API, then send varied inputs to it. Dependency, secret, and license scanners do not fuzz or exercise a running API.

Fuzzing thoroughness trades off against run time: more inputs and operations find more issues but lengthen the job, so quick settings fit merge requests and longer settings fit scheduled pipelines. Fuzzing can run in merge request pipelines, payload strength is not tied to shortness, and fuzzing still needs an API description or target.