Use a target tracking scaling policy that follows a backlog-per-instance custom Amazon SQS metric is correct because it lets the Auto Scaling group continuously adjust capacity to hold a desired backlog per instance and so quickly match capacity to sudden SQS spikes during flash promotions.

Use a target tracking scaling policy that follows a backlog-per-instance custom Amazon SQS metric works by defining a target backlog per instance derived from SQS ApproximateNumberOfMessagesVisible divided by the number of in service instances. The Auto Scaling group then increases or decreases instances automatically to move the actual backlog toward that target which provides fast and stable scaling for bursty, asynchronous workloads.

Use a simple scaling policy that triggers from a custom Amazon SQS queue metric is weaker because simple policies rely on single alarm actions and cooldown periods and that delay can make response to rapid bursts too slow and cause underprovisioning.

Use a step scaling policy that adjusts from a custom Amazon SQS queue metric can react to varying queue sizes but it depends on discrete alarm thresholds and step sizes and that often causes overshoot or slower convergence compared with continuous target tracking.

Use a scheduled scaling policy keyed to a custom Amazon SQS queue metric is inappropriate for unpredictable flash traffic because scheduled actions assume known patterns and they cannot react in real time to sudden spikes.

Full AWS Practitioner Certification Question