A retail platform runs on an Azure Virtual Machine Scale Set (VMSS) for its API tier, an App Service for the web front end, and Azure SQL Database. You must: 1) Alert when the VMSS average CPU exceeds 80% for 5 minutes (notify on-call via SMS) and when it exceeds 95% for 5 minutes (page SRE via PagerDuty). 2) Stream App Service and SQL diagnostic logs to a Log Analytics workspace and archive them to Azure Storage for 365 days. 3) Trigger an alert when the App Service logs contain 'OrderTimeoutException' more than 10 times in 5 minutes. What should you implement?

The correct option directly addresses all requirements. Two separate metric alert rules on the VMSS CPU allow for distinct thresholds (80% and 95%) and different action groups (SMS and PagerDuty), fulfilling the tiered notification requirement. Diagnostic settings are the standard way to send App Service and SQL logs to both a Log Analytics workspace for analysis and a Storage account for long-term archiving. A Log Analytics scheduled query alert is the appropriate method to detect specific log patterns like 'OrderTimeoutException' within a defined timeframe. Incorrect options fail to meet specific requirements. For instance, using a single dynamic metric alert or alert processing rules for CPU might not provide the distinct notification channels needed for different thresholds. Activity Log diagnostics or Azure Policy are not the primary mechanisms for collecting detailed application logs. Azure Monitor Autoscale is for scaling, not primarily for diverse alerting notifications. Smart Alerts or Defender for Cloud alerts do not precisely match the granular control required for all specified conditions.