The exam tests the relationship between input validation and normalization, and which comes first. The answer is normalization before validation. Attackers can encode malicious input in alternate formats to bypass a validator: the string <script> might be submitted as %3Cscript%3E (URL encoding). If the validator checks for literal characters before decoding, it sees percent-encoded characters and passes the input. After the validator, the application decodes and processes the string — and now has script tags in it.
Normalization (decode, standardize, canonicalize) must happen first so the validator sees the actual content in its canonical form. Only then can validation reliably identify whether the content is acceptable. Fuzzers specifically probe for encoding bypass gaps that manual review misses.
The most common SAST exam trap is overstating its capabilities. SAST matches code patterns against known-vulnerable patterns. It does not understand what the code is supposed to do or evaluate whether the logic is correct. This creates two important gaps.
First, cryptographic implementation errors are invisible to SAST. SAST can see that AES is called — it cannot evaluate whether the key size is appropriate, whether the IV is being reused across sessions, or whether the padding mode is secure. The code looks like valid AES usage; SAST has no way to know it is wrong. Second, false positives require human review. SAST flags code that resembles a vulnerable pattern. Some of those flags are correct; many are safe code that looks like a problem. SAST output is a starting point for human review, not a finished vulnerability report.
Code signing questions frequently test which key is used at which step. The trap is reversing the CA and developer actions, or confusing public and private key roles.
Memory device: the CA vouches for the developer's identity — it signs the developer's public key to create the certificate. The developer signs the code to prove it came from them — they use their private key (only they have it). The OS verifies by decrypting the signature with the developer's public key and comparing to a fresh hash of the file. CA signs public. Developer signs with private. OS verifies with public.
The exam may present a scenario where an application is exploited and ask which control limited the damage. The answer is sandboxing if the attacker achieved code execution but could not reach outside the application's permitted scope. The key distinction: sandboxing is not a preventive control for the initial compromise — it is a containment control for what happens after.
Input validation prevents the initial exploit. Code signing prevents installing tampered software. SAST finds vulnerabilities during development. But if all those controls fail and an attacker achieves code execution, sandboxing is what limits the blast radius: the attacker can only do what the compromised application was allowed to do.