An agile team ships a cloud application every two weeks and has no security stage in its process. Leadership asks how to integrate security without returning to a waterfall-style security gate at the end of each release. Which approach best fits?

Agile delivery depends on small increments, so security has to be expressed in the same units the team already works with. Security requirements become user stories, abuse cases or acceptance criteria in the definition of done, and automated checks such as static analysis, dependency scanning and configuration checks run in the pipeline for every change, giving feedback within the sprint. Threat modeling is revisited when a story changes the architecture, and deeper manual testing is scheduled on a risk basis rather than for every iteration. A full manual penetration test before every two-week release recreates the heavyweight end gate that leadership wants to avoid; it slows delivery and tends to be skipped under pressure, though periodic testing remains valuable. A yearly hardening sprint leaves a year of releases unexamined and accumulates security debt that is expensive to fix later. Handing security to the provider's managed services misreads shared responsibility: the customer still owns its code, identities, data and configuration, so sprints always have security work. Exam caveat: the exam favors integrating security continuously into the existing process over bolting a separate stage onto it. Operational check: look at the backlog for security stories with acceptance criteria and confirm pipeline security checks run and fail builds on high-severity findings.