For a complex city case-management application, testers want runtime insight combined with code-level analysis during functional tests. Which approach matches?
Select an answer to reveal the explanation.
Short Explanation
IAST sits in the middle—watching the app while real test traffic runs, with enough insides to explain why something broke. For complex municipal apps, that combo of runtime and analysis is gold. It is not "skip testing"; it is smarter testing.
Full Explanation
Interactive application security testing (IAST) instruments a running application—often via agents or sensors—while functional or automated tests execute, correlating runtime behavior with code-level context. For a complex city case-management application, IAST can reveal how tainted input flows through real modules during tests, combining strengths of dynamic observation with insight closer to static analysis. That hybrid fits environments where pure black-box scans lack depth and pure static scans lack runtime certainty.
Paper-only checklist audits with no tooling miss automated detection at the scale and complexity of modern case-management stacks; checklists help process maturity but do not instrument runtime paths.
Network ACLs as a substitute for application testing confuse perimeter filtering with finding logic flaws inside the app. ACLs do not replace IAST/DAST/SAST for application defects.
Deleting unit tests to accelerate release cadence reduces quality signal and removes the very exercise traffic IAST often relies on; speed gained by deleting tests increases escaped-defect risk.
Exam caveat: IAST is the method that instruments the running app during tests—know the SAST/DAST/IAST/SCA quartet. Operational check: deploy IAST agents in non-production case-management test lanes, drive realistic functional suites, triage findings with developers who own the modules, and avoid treating IAST as a reason to skip SCA or threat modeling for integrations with courts and social-service data.