Sample questions
Ds Pipeline Security GatesDifficulty 1
In a typical CI/CD security-gate pipeline, why is SAST usually placed before SCA and DAST rather than after them?
- aSAST requires a fully deployed running instance, so it must come after every other gate
- bSAST is always the slowest gate, so teams schedule it last to avoid blocking fast checks
- cSAST only needs the source code, so it can run right after build, before an artifact exists✓
- dSAST replaces SCA and DAST entirely, so the other gates become optional
Explanation:SAST analyzes source code or compiled artifacts directly, so it can execute right after the build step, well before an artifact is packaged for dependency scanning (SCA) or deployed for dynamic testing (DAST). Placing it early gives developers the fastest possible feedback.
Ds Pipeline Security GatesDifficulty 1
Why does SCA (software composition analysis) typically run against a resolved dependency manifest (e.g. a lockfile) rather than against raw source code?
- aLockfiles are always smaller, so they scan faster than any other pipeline artifact
- bThe exact resolved versions of transitive dependencies are only known once the lockfile exists✓
- cRaw source code cannot be read by any automated tool without manual annotation
- dSCA tools are only compatible with binary artifacts, never with text files
Explanation:SCA needs to know precisely which versions of direct and transitive dependencies will actually be pulled in, and that resolution only exists in the lockfile or manifest produced after dependency resolution, not in the raw import statements of the source.
Ds Pipeline Security GatesDifficulty 2
A team runs DAST as the very last gate before production deploy, against a staging environment that mirrors production. A critical SQL injection is found at this stage. What is the main drawback of catching it only here, compared to catching it via SAST earlier in the pipeline?
- aThe fix now needs a full rebuild, re-running every earlier gate, and a fresh staging deploy✓
- bDAST findings are considered less reliable than SAST findings, so it might not be real
- cStaging environments are not permitted to run DAST scans under most frameworks
- dSQL injection cannot be detected by SAST tools under any circumstances
Explanation:Because DAST sits at the end of the pipeline, a finding there forces the change to loop all the way back through build, SAST, and SCA again before a new staging deploy can be tested, whereas the same vulnerable pattern is often visible to SAST directly in the source right after the build gate, catching it far cheaper and earlier.
Ds Pipeline Security GatesDifficulty 1
In a pipeline gate sequence of build -> SAST -> SCA -> DAST -> deploy, what is the primary reason DAST is placed after SCA rather than before it?
- aDAST always produces more findings than SCA, so it runs second to balance report size
- bSCA needs internet access and DAST does not, so ordering follows network availability
- cRegulatory standards mandate dependency scanning before dynamic scanning everywhere
- dDAST needs a deployed artifact, so it makes sense to screen dependencies with SCA first✓
Explanation:DAST requires an actual running instance of the application, which typically means packaging and deploying it to a test environment. It is more efficient to screen dependencies with SCA first, since finding a critical vulnerable library can fail the build before the team spends time and infrastructure deploying a DAST target.
Ds Pipeline Security GatesDifficulty 2
What is a key limitation of running every security gate strictly sequentially (build -> SAST -> SCA -> DAST -> deploy) rather than parallelizing independent gates where possible?
- aSequential gates are always cheaper to run in compute cost than parallel gates
- bTotal feedback time is the sum of every gate's duration, even when SAST and SCA are independent✓
- cSequential execution is required by every SAST and SCA vendor's licensing terms
- dParallel gates cannot share a single build artifact, so each needs its own compile step
Explanation:SAST and SCA are typically independent of each other's results (one analyzes source, the other analyzes the dependency manifest), so running them in parallel after the build step can cut total gate time roughly in half compared to running them one after another, without weakening the security coverage.
Ds Pipeline Security GatesDifficulty 3
A pipeline currently runs build -> SAST -> SCA -> DAST -> deploy fully sequentially, taking 40 minutes total. The team notices SAST and SCA are independent and each takes 8 minutes, while DAST depends on a deployed artifact and takes 20 minutes. What is the most sensible first change to reduce feedback time without weakening any gate?
- aRemove SCA entirely, since SAST already covers first-party source code
- bMove DAST before SAST and SCA so the longest gate finishes first
- cRun SAST and SCA in parallel right after build, keeping DAST after both finish✓
- dSkip the build step for pull requests since only main needs a real build
Explanation:Since SAST and SCA are independent, running them in parallel cuts roughly 8 minutes off the pipeline without removing any check or reordering DAST, which genuinely needs a deployed artifact and must still come after the source/dependency gates in this design.