How should a solutions architect meet this requirement?
Set up an AWS CloudTrail trail that logs data events. Use CloudTrail logs to track Amazon SQS API activities by any external principals.
Use an AWS Identity and Access Management Access Analyzer to create an analyzer with the current organization as a zone of trust. Filter by external findings on the SQS queue.
Set up an AWS CloudTrail trail that logs management events. Use CloudTrail logs to track Amazon SQS API activities by any external principals.
Use AWS Identity and Access Management Access Analyzer to create an analyzer with the current account as a zone of trust. Filter by external findings on the SQS queue.
Explanations:
Setting up an AWS CloudTrail trail to log data events would track API activities, but it won’t explicitly identify external principals since CloudTrail logs don’t categorize principals as internal or external.
Using AWS Identity and Access Management (IAM) Access Analyzer with the current organization as a zone of trust allows for filtering by external findings, which can help identify external principals that have access to the SQS queue.
Setting up an AWS CloudTrail trail to log management events does not track API activities directly and does not differentiate between internal and external principals. Management events log changes to resources rather than tracking access usage.
Creating an IAM Access Analyzer with the current account as a zone of trust limits the analysis to only the resources and permissions within that account, not allowing for a comprehensive view of external access across the SQS queue.
As I understand it, the answer is:
Use an AWS Identity and Access Management Access Analyzer to create an analyzer with the current organization as a zone of trust. Filter by external findings on the SQS queue.
From what I’ve seen, the answer is:
Use an AWS Identity and Access Management Access Analyzer to create an analyzer with the current organization as a zone of trust. Filter by external findings on the SQS queue.