Une entreprise déploie des fonctions AWS Lambda avec AWS CloudFormation. Les développeurs tentent de déboguer une fonction déployée, mais elle n'écrit pas de sortie dans Amazon CloudWatch Logs. Quelle combinaison d'actions un ingénieur de sécurité doit-il entreprendre pour résoudre ce problème ? (Choisissez-en deux.)

La première action correcte consiste à vérifier le rôle IAM spécifié dans le modèle CloudFormation pour la fonction Lambda. Ce rôle doit avoir une politique d'approbation qui permet au service lambda.amazonaws.com d'assumer ce rôle via l'action sts:AssumeRole. Sans cela, Lambda ne peut pas assumer le rôle et exécuter la fonction, ce qui empêcherait toute écriture de logs. La deuxième action correcte est de s'assurer que le rôle d'exécution Lambda dispose des autorisations nécessaires pour écrire dans CloudWatch Logs (par exemple, logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents). Sans ces autorisations, même si la fonction s'exécute, elle ne pourra pas envoyer ses logs à CloudWatch. Les options incorrectes sont : La configuration AWS X-Ray est pour le traçage distribué, pas pour l'écriture de logs de base dans CloudWatch Logs. La politique de ressource de la fonction Lambda contrôle qui peut invoquer la fonction, pas les autorisations de la fonction elle-même pour interagir avec d'autres services AWS. Le rôle utilisé par les développeurs pour déboguer n'est pas directement lié à la capacité de la fonction Lambda à écrire ses propres logs. C'est le rôle d'exécution de la fonction qui est pertinent.