Four Audit Findings, Two Sprints, One Security Engineer
A 250-person healthcare-adjacent SaaS company stores marketing analytics events in Amazon S3 and patient-identifiable records in an encrypted Amazon RDS for PostgreSQL database. A pre-audit review turns up four findings: (1) the CI/CD pipeline stores a long-lived IAM access key with AdministratorAccess in an environment variable; (2) one S3 bucket holding ad-creative assets allows public read via a bucket ACL; (3) the root account has no MFA and is used monthly to rotate a vendor key; (4) RDS automated backups are retained 7 days, though the written retention policy says 35. The auditor gives 30 days to remediate. Engineering has two sprints of capacity and a single security engineer who is also on call this month.
1. Order the four findings by risk and justify the ordering, distinguishing urgency from effort.
Read the worked answer
Rank by blast radius × likelihood, then sequence work by effort so cheap fixes are not queued behind expensive ones.
- Root account without MFA (and used monthly). A single phishing email yields total, unrecoverable account control - including the ability to delete the backups that would let you recover. Highest blast radius in the list. Effort is near zero, so it is day-one work, not sprint work.
- Long-lived admin key in CI. Admin rights, no expiry, sits in an environment variable that anyone with pipeline read access can extract, and unattended credentials can be used at 3am with nobody watching. High blast radius, moderate effort (replace with short-lived federated/role-based credentials).
- Public-readable ad-creative bucket. The content is non-sensitive, so the practical exposure is reputational and cost (scraping, egress), not patient data - resist the urge to rank it first because it is the most alarming-sounding. The real finding is the systemic one: public access is possible at account level at all.
- Backup retention 7 vs 35 days. No active exposure, but it is a documented-control failure the auditor will re-test. Cheap to change; run it in parallel.
State the reasoning out loud: findings 1 and 4 need hours, not sprints, so heading into the 30 days with them open is indefensible.
2. Classify the remediations as preventive or detective, and name one detective control that would have surfaced all four classes of problem.
Read the worked answer
Preventive (stop it happening):
- Root: hardware MFA on root, plus an organizational policy denying root usage so 'monthly vendor key rotation by root' becomes impossible by design - replace it with a federated identity and a scoped role.
- CI key: remove long-lived keys, use short-lived credentials issued to the pipeline's workload identity, add permission boundaries and a deny on privilege escalation.
- Public bucket: account-level block-public-access, and bucket policies that make ACL-based public access ineffective.
- Backups: policy-as-code on the backup plan, so retention is defined centrally rather than per-resource.
Detective (catch it after the fact):
- CloudTrail for API activity, IAM Access Analyzer for externally reachable resources, GuardDuty for anomalous credential use, Security Hub to aggregate findings.
The single control: CloudTrail feeding an alerting pipeline, plus AWS Config rules evaluating account and resource configuration continuously. CloudTrail alone catches root logins and admin-key usage; Config rules catch the public bucket and the retention drift. Together they cover all four, and they generate the evidence the auditor asks for next time.
3. The team asks whether any of the four findings are AWS's responsibility under the shared responsibility model. Answer precisely.
Read the worked answer
None of the four. Every finding is a customer-side configuration or process gap.
- RDS is a useful test case because it is managed: AWS owns the physical hosts, the hypervisor, the managed service layer, patching of the underlying operating system, and the engine patching it performs on your behalf. The customer owns data classification, encryption choices, network exposure, IAM and database access control - and the retention period of the automated backups, which is a console/API setting you configure. Retention drift is squarely yours.
- S3 public access, bucket ACLs and IAM policy are customer configuration; AWS operates the storage layer.
- Root MFA and IAM access keys are account-security settings owned entirely by the customer.
The judgement: 'managed service' is not 'managed security', and teams routinely misread the shared responsibility boundary as covering configuration. If the team wants an explicit split, write a one-page RACI per service - control ownership confusion is what turns a one-hour fix into a 30-day audit failure.