Implement Container Scanning GITLAB-CERTIFIED-SECURITY-SPECIALIST Practice Questions (Page 3)

Questions 11–15

1. 11application · medium

   A container scanning job fails with a timeout after 10 minutes. The image is large, and the scan takes longer than the job timeout. What is the best solution?

   • AReduce the image size by removing unnecessary packages.
   • BUse a larger GitLab Runner with more memory.
   • CDisable the container scanning job.
   • DIncrease the `timeout` for the container scanning job in the CI/CD configuration.
   Reveal Solution Discussion Select an answer first
2. 12foundation · easy

   Which of the following is a common cause of container scanning job timeouts?

   • AThe vulnerability database is outdated
   • BThe container image is very large, causing the scan to take longer than the job timeout
   • CThe container scanning report is too large to display
   • DThe GitLab Runner is not registered with the project
   Reveal Solution Discussion Select an answer first
4. 13application · medium

   A container scan reports a vulnerability in a base image that the team has already patched in a newer version. The team wants to track this issue but does not want it to block future merge requests. What should they do?

   • AChange the severity threshold to 'high' so critical vulnerabilities are ignored.
   • BCreate an issue for the vulnerability and assign it to the team.
   • CDismiss the vulnerability with a comment explaining that the base image has been updated.
   • DDelete the container image from the registry.
   Reveal Solution Discussion Select an answer first
5. 14expert · hard

   A team wants to run container scanning on merge requests but only for changes that affect the Dockerfile or the `src/` directory. They also want to fail the merge request if a high-severity vulnerability is found. What is the best way to configure this?

   • AUse `rules:if` to check the merge request title for keywords.
   • BUse `rules:changes` to include the container scanning job only when the Dockerfile or `src/` files are modified, and set `allow_failure: false`.
   • CRun the scan on every merge request and use a script to skip it if no relevant files changed.
   • DSet the scan frequency to 'on merge request' in the Security Configuration UI.
   Reveal Solution Discussion Select an answer first
6. 15expert · hard

   A team wants to run container scanning on merge requests but only when the merge request is from a forked project. They also want to fail the merge request if a high-severity vulnerability is found. What is the best way to configure this?

   • ARun the scan on every merge request and use a script to skip it if the MR is not from a fork.
   • BSet the scan frequency to 'on merge request' in the Security Configuration UI.
   • CUse `rules:changes` to include the job only when the Dockerfile is modified.
   • DUse `rules:if` with `$CI_MERGE_REQUEST_SOURCE_PROJECT_ID != $CI_PROJECT_ID` to include the job only for fork merge requests, and set `allow_failure: false`.
   Reveal Solution Discussion Select an answer first