Aplikacja używa klastra ElastiCache for Redis do buforowania. Klaster ma już włączone szyfrowanie w spoczynku (encryption at rest), ale nie szyfrowanie w tranzycie (encryption in transit), a klienci mogą uzyskiwać dostęp do pamięci podręcznej bez uwierzytelniania. Architekt rozwiązań musi wymagać uwierzytelniania klienta i włączyć kompleksowe szyfrowanie w tranzycie. Które rozwiązanie spełnia te wymagania?

Poprawna odpowiedź spełnia wszystkie wymagania. ElastiCache for Redis obsługuje uwierzytelnianie klienta za pomocą tokenów AUTH, a szyfrowanie w tranzycie można włączyć na istniejącym klastrze. AWS Secrets Manager jest odpowiednim miejscem do bezpiecznego przechowywania tokenów uwierzytelniających, a aplikacja może być zaktualizowana, aby pobierać token z Secrets Manager i używać go do uwierzytelniania. Pierwsza nieprawidłowa opcja sugeruje utworzenie nowego klastra, co jest niepotrzebne, ponieważ istniejący klaster może zostać zmodyfikowany. Druga nieprawidłowa opcja (trzecia w pytaniu) myli certyfikaty SSL z tokenami AUTH do uwierzytelniania w ElastiCache for Redis; certyfikaty SSL są używane do szyfrowania, a nie uwierzytelniania w tym kontekście. Czwarta opcja również błędnie zakłada użycie certyfikatów SSL do uwierzytelniania i nie wspomina o konfiguracji tokena AUTH.