Cross-Account SQS Access via Resource Policy
Short answer
C Create an SQS access policy that provides the other company access to the SQS queue.
Question
Key Takeaways
The core trap is confusing IAM Identity-Based Policies with SQS Resource-Based Policies; only the latter allows a resource owner to grant permissions to external principals directly on the resource.
This question tests how to grant cross-account access to an Amazon SQS queue without modifying the external account's permissions. The correct approach is using an SQS resource-based policy (access policy).
Common mistake: Candidates often choose Option B (IAM policy) because they are accustomed to managing permissions via IAM roles. However, IAM policies attached to entities in Account A cannot directly authorize actions on resources in Account A for principals in Account B unless the principal assumes a role, which contradicts the 'no permission changes' constraint for the other company.
Expert Analysis
Why the Answer Is Correct
Option C is correct because Amazon SQS supports resource-based policies (also known as access policies or bucket policies in S3 terms) that can be attached directly to the queue. This policy defines who (Principal) can do what (Action) on the specific resource (Queue ARN). By specifying the other company's AWS Account ID or IAM User/Role ARN as the Principal, the development team grants access directly from the SQS resource side. This satisfies the requirement that the other company does not need to modify its own account permissions.
Why the Other Options Are Wrong
Option A is incorrect because instance profiles are used to grant permissions to EC2 instances, not for cross-service or cross-account API access. Option B is incorrect because IAM policies are identity-based and attached to IAM users, groups, or roles within the same account. While you can create an IAM Role in your account for them to assume, the prompt states they don't want to give up their own account permissions, implying a simpler direct access method is preferred, and IAM policies alone don't grant cross-account access without a trust relationship setup which is more complex than a simple resource policy. Option D is irrelevant because SNS is a notification service, not a mechanism for granting SQS access.
Community Comment Notes
The community overwhelmingly agrees on Option C. Users note that SQS access policies allow for fine-grained, cross-account control. As one commenter paraphrased, "SQS Access Policy for secure, fine-grained Cross-account access" is the key concept. Another user provided a JSON example showing the Principal structure, confirming that specifying the external account ID in the SQS policy is the standard solution.
Official Reference
This link opens the official vendor documentation in a new tab.
Exam Strategy
Always look for keywords like 'resource-based' vs 'identity-based'. If the question asks to grant access to a resource (like S3 bucket, SQS queue, DynamoDB table) to an external entity without changing the external entity's IAM config, think Resource Policy first.
Frequently Asked Questions
Why can't I use an IAM policy for the other company?
What is an SQS access policy?
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 10 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 10
-
iczcezar 👍 8The correct option to provide access to the SQS queue without giving up the other company's account permissions is: C. Create an SQS access policy that provides the other company access to the SQS queue. By creating an SQS access policy, you can define specific permissions for the other company to access the SQS queue without requiring them to modify their own account permissions. This allows for fine-grained control over access to the queue while maintaining security and isolation between accounts. Options A, B, and D are not appropriate for granting access to the SQS queue in this scenario.
-
7fb06b3 👍 5 Answered CAmazon SQS policy system lets you grant permission to other Amazon Accounts. https://docs.amazonaws.cn/en_us/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-using-identity-based-policies.html
-
hajra313 👍 4option A: Instance profiles are used to grant permissions to EC2 instances, not for granting access to other AWS services like SQS queues. Option B.:AM policies are applied to IAM users, groups, or roles within the same AWS account. They are not directly applicable to granting access to resources in other AWS accounts. option C:SQS access policies allow you to grant cross-account access to SQS resources. You can specify the necessary permissions in the policy and attach it directly to the SQS queue. This way, you can give the other company's AWS account the necessary permissions to poll the queue without compromising their account permissions. option D. Amazon SNS access policies are used to manage access to SNS topics, not SQS queues
-
sandordini 👍 3 Answered CSQS Access Policy for secure, fine-grained Cross-account access
-
LeonSauveterre 👍 2 Answered CA - Instance profiles are attached to Amazon EC2 instances. This is irrelevant. B - While you could create an IAM role in your account for the other company to assume, it is explicitly stated that the other company does not want to give up its own permissions, meaning cross-account access must be configured, but IAM policies alone do not provide cross-account access. C - SQS supports resource-based policies, which allow you to grant access to specific AWS principals (users, roles, or accounts) across accounts. D - No idea what it would achieve. SNS policies don't even apply to SQS queues.
Show 5 more comments
-
Scheldon 👍 2 Answered CAnswerC Creating Access policy in SQS which will allow other company to acess SQS queue seems to be the only solution which is RIGHT here
-
NayeraB 👍 2 Answered Chttps://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-overview-of-managing-access.html
-
FlyingHawk 👍 1 Answered Chttps://repost.aws/knowledge-center/sqs-queue-access-permissions Here is the example: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::OtherCompanyAccountID:root" }, "Action": [ "sqs:ReceiveMessage", "sqs:DeleteMessage" ], "Resource": "arn:aws:sqs:region:YourAccountID:YourQueueName" } ] }
-
kempes 👍 4 Answered COption C
-
Andy_09 👍 1Option B
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →