The 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.

Amazon 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

option 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

Option C

SQS Access Policy for secure, fine-grained Cross-account access

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-overview-of-managing-access.html

AnswerC Creating Access policy in SQS which will allow other company to acess SQS queue seems to be the only solution which is RIGHT here

A - 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.

https://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" } ] }

Option B