Aplikacja pobiera wiadomości z tysięcy systemów alarmowych. Wiadomości obejmują alarmy o wysokim priorytecie oraz wiadomości informacyjne o niższym priorytecie (uzbrajanie/rozbrajanie, stany czujników). Wszystkie wiadomości są przechowywane w pojedynczej kolejce Amazon SQS i przetwarzane przez instancje robocze EC2 w grupie Auto Scaling. Administrator musi zapewnić, że alarmy są przetwarzane przed wiadomościami informacyjnymi. Które rozwiązanie spełnia ten wymóg?

Poprawna odpowiedź to utworzenie dwóch kolejek SQS. Oddzielenie wiadomości o wysokim priorytecie (alarmy) od wiadomości o niższym priorytecie (informacyjne) pozwala aplikacji konsumenckiej na priorytetowe pobieranie i przetwarzanie alarmów z dedykowanej kolejki, zanim zajmie się wiadomościami informacyjnymi. To zapewnia, że krytyczne zdarzenia są obsługiwane bezzwłocznie. Pozostałe opcje są nieprawidłowe, ponieważ: Dostosowanie grupy Auto Scaling do szybszego skalowania nie rozwiązuje problemu priorytetyzacji, a jedynie zwiększa ogólną przepustowość, co może nadal prowadzić do opóźnień w przetwarzaniu alarmów, jeśli są one zmieszane z wiadomościami o niższym priorytecie. Użycie Amazon SNS fanout z SQS rozsyła powiadomienia równolegle, ale nie wprowadza mechanizmu priorytetyzacji między różnymi typami wiadomości. Wprowadzenie strumienia Amazon DynamoDB nie jest odpowiednim rozwiązaniem dla priorytetyzacji wiadomości w kolejce SQS; DynamoDB jest bazą danych, a nie usługą kolejkowania wiadomości.