TL;DR: SAST reads your source, SCA reads your dependencies, secret scanning reads the diff, and image scanning reads the built layers. Run all four on every pull request rather than at the release gate, and fail the build only on the classes you have decided are non-negotiable.
How to approach it
Name what each one looks at, because candidates blur them and the differences decide where each runs and who fixes the finding. Then make the point about placement, which is the part with real consequences: shifting these left is what turns security from a blocker into a normal build failure.
A strong answer
SAST analyses your own source code without running it, looking for patterns: a SQL query built by string concatenation, user input reaching a shell command, a disabled certificate check. It is fast, it runs on every pull request, and its weakness is false positives, which is why an unmanaged SAST tool becomes a wall of findings nobody reads. Tune it to the rules you will actually act on and let the rest be informational.
SCA looks at your dependency tree and matches it against known vulnerability databases. Most of your code is not yours, so this finds more real exposure than SAST does. The detail worth knowing: it covers transitive dependencies, the ones you never chose, which is where most of the findings live. The useful refinement is reachability analysis, which asks whether the vulnerable function is actually called from your code, because a critical CVE in a code path you never execute is a very different priority from one on your request path.
Secret scanning looks at the diff for credential shapes: API keys, private keys, tokens. Two placements and you want both. A pre-commit hook catches it before it exists, and a CI check catches what the hook missed because someone skipped it. One thing to be clear about in an interview: once a secret has been pushed, removing it from the code does not help. It is in the history and possibly in a fork, so the only correct response is to rotate it.
Image scanning runs on the built container and finds vulnerable OS packages in the base image plus anything installed into it. This is usually the noisiest by volume, and the largest single lever is the base image: moving from a full distribution to a slim or distroless one removes most findings by removing the packages, without triaging a single one.
Placement is the part that matters. Run everything on the pull request, in parallel with the tests, since none of them depends on a test result. A developer who sees a dependency finding while the change is fresh bumps the version in ten minutes. The same finding at a release gate on the last day of the sprint becomes a negotiation with the security team about whether it is really exploitable, and that conversation is the one nobody wants.
For what fails the build: be selective and write it down. Secrets always fail. Critical and high severity with a fix available fail. Everything else reports without blocking, and there is a dated exception process for the ones that genuinely cannot be fixed now. A pipeline that fails on every medium finding gets its threshold quietly raised within a month, and then it is enforcing nothing.
What interviewers probe next
"What about DAST?" It tests a running application from the outside, so it catches configuration and runtime issues the static tools cannot see. It is slower and needs a deployed environment, so it runs against staging on a schedule rather than on every pull request.
"How do you handle a finding with no fix available?" A dated exception with a named owner, plus a compensating control if one exists. Not a permanent waiver, and not an ignore file nobody revisits.
"What is an SBOM for?" A list of what is actually in the artifact, generated at build time and stored with it. When the next widely-exploited library lands, it answers "are we affected" in minutes rather than days.
Common mistakes
Running scans only at the release gate, which converts every finding into an argument under time pressure.
Failing the build on every severity, which trains people to raise the threshold until it means nothing.
Deleting a committed secret and not rotating it, when the value is already in the history.
Triaging hundreds of image findings individually rather than changing the base image, which removes most of them at once.