A bank is moving 120 workloads with PCI card data, customer PII, and public marketing sites to AWS. Security must decide what to log, alarm depth, and retention before enabling tools. Which analysis best determines monitoring requirements for these varied workloads?

Effective monitoring requirements must be derived from what each workload protects and what rules apply to it, so classifying data sensitivity and compliance scope per workload is the necessary upfront step because PCI card data demands detailed audit trails, tamper-evident storage and extended retention, customer PII requires strict access logging and breach-detection alarms, while public marketing sites need only baseline operational logging, which then directly determines which log sources to enable, how deep alarms must go, and how long to retain each type. Applying uniform threat modeling to all workloads is a sound security practice but fails here because it imposes identical controls and ignores the stated variation, over-logging low-risk sites while potentially under-protecting regulated data. Inventorying owners, regions and dependencies is valuable for centralized collection and routing but misses the core driver, since ownership and topology do not define legal retention or sensitivity-based alarm depth. Analyzing performance and capacity baselines is commonly used for cost and operational tuning but addresses availability rather than confidentiality and compliance, so it cannot decide PCI audit needs or PII alarm thresholds. For the exam, remember that questions asking what to log and how long before tools are enabled are testing analysis and classification, not deployment of a logging service. As a practical check, map each of the 120 workloads to data class and compliance regime in a matrix, then derive log, alarm and retention requirements from that row before configuring any AWS service.