A regulated trading platform with 300 engineers and 120 services had an audit finding for excessive standing production access and inconsistent change approval. Security responded with no standing production access via a manual ticket queue (median wait 4 hours), mandatory SAST, SCA and DAST scans that block every pipeline (adding 22 minutes), and a weekly change advisory board for all production changes. Lead time for changes went from 1.2 to 3.1 days, break-glass use rose from 2 to 30 times a month, and two teams were found deploying from laptops with a shared service-account token.
The interviewer asks“After an audit finding, security rolled out a set of controls and now developers say they can't ship. Lead time has doubled and people are sharing break-glass access. How would you balance security controls against developer experience here, and how would you know you'd got it right?”
I keep the control objectives the audit cares about, least privilege, segregation of duties, known vulnerabilities caught, and change traceability, but redesign the mechanisms so the secure path is the fast path. That means risk-tiering services so strict controls land on the order path and light ones elsewhere, a paved-road pipeline with scanning, signing and approvals built in, guardrails that detect and auto-fix for low risk and hard gates only for high-confidence critical findings, fast feedback in the IDE and on the pull request, and just-in-time access that takes minutes instead of a four-hour ticket. I measure both sides, lead time, CI duration, time-to-access, bypass and break-glass rates against standing privileged accounts and time-to-remediate, and I treat a rising bypass rate as a defect in the control.
A free account unlocks the rest of it, and saves your progress across every track.