A payments startup runs a PCI card processor with DynamoDB, a marketing blog on S3, and dev sandboxes that change daily. Budget is tight and alert fatigue is high. Which workload analysis method should the detection engineer use to define right-sized monitoring and alerting requirements?

The correct method uses risk-based tiering because the DynamoDB processor is PCI in-scope and needs deep data-plane logging and high-severity routing, while the S3 blog needs baseline integrity monitoring and daily sandboxes need lightweight ephemeral coverage, which right-sizes spend and suppresses fatigue without losing compliance. The volatility-based method correctly handles churn and ephemeral noise, a common dynamic-environment practice, but fails risk proportionality by ranking change rate above sensitivity and under-protecting stable PCI data. The full-retention method reflects valid forensic readiness, but fails cost proportionality by applying year-long data-plane retention and manual review to low-value blog and transient sandbox data, violating the tight budget and inflating storage and triage. The classification-aware method with fixed sensitive thresholds sets logging well but fails detection tuning by keeping static high sensitivity across varying baselines, which sustains high alert fatigue and noisy paging. For exams, when mixed compliance scope appears with budget and fatigue constraints, choose tiered logging and severity by risk rather than single-factor or maximum-visibility designs. As a practical check, tag PCI in-scope assets, enable CloudTrail data events only there, use short retention for others, and review cost and alert volume per tier weekly.