Firma organizuje swoje konta AWS w jednostki organizacyjne (OU) w ramach AWS Organizations. Interfejsy API wdrożone na jednym koncie są powiązane z VPC tego konta i obecnie nie mają uwierzytelniania. Tylko podmioty z określonej jednostki organizacyjnej powinny mieć możliwość wywoływania interfejsów API. Firma zastosowała politykę do punktu końcowego VPC interfejsu API Gateway i zaktualizowała polityki zasobów API Gateway, aby blokować wywołania, które nie pochodzą z punktu końcowego interfejsu. Po tym, wywołanie API za pośrednictwem adresu URL punktu końcowego interfejsu kończy się niepowodzeniem z błędem: „User: anonymous is not authorized.” Która kombinacja działań rozwiązuje ten problem? (Wybierz dwie.)

Problem "User: anonymous is not authorized" wskazuje, że żądania API nie są uwierzytelniane. Aby zezwolić na wywołania API tylko z określonej OU, należy zastosować uwierzytelnianie, które pozwoli na identyfikację podmiotu wywołującego i zastosowanie odpowiednich zasad autoryzacji. Włączenie autoryzacji opartej na IAM dla każdej metody API i skonfigurowanie AWS IAM jako autoryzatora pozwala na użycie polityk IAM do kontrolowania dostępu. Można wtedy utworzyć polityki IAM, które zezwalają na wywołania API tylko z ról lub użytkowników IAM należących do określonej OU. Uwierzytelnienie i weryfikacja wywołujących poprzez podpisanie żądań klienta za pomocą poświadczeń AWS przy użyciu Signature Version 4 jest standardową metodą uwierzytelniania żądań do usług AWS. W połączeniu z autoryzacją IAM, pozwala to na precyzyjne kontrolowanie, które podmioty mogą wywoływać API. Autoryzatory AWS Lambda (oparte na tokenach lub parametrach żądania) oraz pule użytkowników Amazon Cognito są opcjami autoryzacji, ale nie rozwiązują bezpośrednio problemu "anonymous" w kontekście polityk VPC Endpoint i Organizations bez dodatkowej konfiguracji polityk IAM, które są podstawą kontroli dostępu w AWS Organizations.