Why Can't MyLambdaFunction Read DOC-EXAMPLE-BUCKET Objects?

Design, implement, and troubleshoot authorization for AWS resources.

Answer Correct answer: C — Change the bucket policy's Resource to arn:aws:s3:::DOC-EXAMPLE-BUCKET/* so s3:GetObject applies to the objects Lambda reads.

A security engineer is troubleshooting an AWS Lambda function that is named MyLambdaFunction. The function is encountering an error when the function attempts to read the objects in an Amazon S3 bucket that is named DOC-EXAMPLE-BUCKET. The S3 bucket has the following bucket policy: exhibit Which change should the security engineer make to the policy to ensure that the Lambda function can read the bucket objects?

Remove the Condition element. Change the Principal element to the following: [image: https://img.examtopics.com/aws-certified-security-specialty-scs-c03/image2.png]
Change the Action element to the following: [image: https://img.examtopics.com/aws-certified-security-specialty-scs-c03/image3.png]
Change the Resource element to "arn:aws:s3:::DOC-EXAMPLE- BUCKET/*''. Correct Answer
Change the Resource element to "arn:aws:lambda:::function:MyLambdaFunction". Change the Principal element to the following: [image: https://img.examtopics.com/aws-certified-security-specialty-scs-c03/image4.png]

Community Insight

This tests whether you know s3:GetObject requires the bucket/* object path; the trap is editing Principal or Condition when the Resource scope is the actual blocker.

S3 bucket policies that authorize Lambda reads must apply s3:GetObject to object-level ARNs, not just the bucket ARN. The page explains why changing Resource to arn:aws:s3:::DOC-EXAMPLE-BUCKET/* (C) fixes MyLambdaFunction's read failure.

The common wrong move is choosing A to remove the Condition and alter the Principal even though the policy already targets the Lambda function and simply lacks object-level Resource scope.

Community Discussion (7 comments)

dakarihick 👍 1 Selected: C

I’d choose C too based on the discussion. I’ve also been using examspilot for some extra AWS Security Specialty practice.

CanekSystems 👍 2 Selected: C

C is correct. The principal is ok because is following the principle of the least privilege by scoping in the condition only the Lambda's ARN.

datngxtiens 👍 1 Selected: C

Answer C is correct but is not enough. I don't think allowing the principal of Lambda service can grant the Lambda function access to S3 bucket. The principal should be the role ARN of the Lambda function, I think.

gonzales 👍 1 Selected: C

s3:GetObject → requires bucket/*

bigdata2ml 👍 2 Selected: C

Need permission to read the objects in the policy /*

Liongeek 👍 1 Selected: C

It's C

maxzhangzhihua 👍 1 Selected: C

obviuse

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

The failing operation is an object read (s3:GetObject) by MyLambdaFunction against DOC-EXAMPLE-BUCKET. In S3 bucket policies, s3:GetObject must be scoped to object ARNs such as arn:aws:s3:::DOC-EXAMPLE-BUCKET/; granting it on only arn:aws:s3:::DOC-EXAMPLE-BUCKET does not authorize reads of the objects. Option C changes Resource to that object path, so the existing Action and Principal/Condition continue to apply to the exact objects Lambda needs. Community responses such as "s3:GetObject → requires bucket/" and "Need permission to read the objects in the policy /*" point to the same ARN mismatch. This is a least-privilege fix because it broadens Resource from the bucket container to its objects, not Principal or Action.

Why the Other Options Are Wrong

A removes the Condition and swaps the Principal, but the policy already has a principal/condition intended to identify the Lambda function; deleting the condition is unnecessary and can make the grant broader than needed. It does not repair the object-level Resource mismatch that blocks GetObject. B changes Action, which does not help when the action is already the correct read permission but the Resource points to the bucket instead of objects. D changes Resource to a Lambda function ARN, which is not a valid S3 object resource for a bucket policy, and altering Principal is again aimed at the wrong part of the statement. As datngxtiens notes, the principal model can warrant separate review, but that does not make A or D the answer to this exhibit.

Community Comment Notes

CanekSystems reads the condition as least-privilege scoping to the Lambda ARN, supporting that the Principal/Condition may already be acceptable. Several commenters converge on the object path: "s3:GetObject → requires bucket/" and "Need permission to read the objects in the policy /". datngxtiens raises a useful caveat that a Lambda service principal may not be enough without the execution role, but that is a principal-design nuance rather than the specific fix for this exhibit. The consensus around C is consistent with S3's object-level ARN requirement, not merely a vote count.

Official Reference

Exam Strategy

Map the failing S3 API call to its resource type: GetObject and PutObject need object ARNs, while ListBucket needs the bucket ARN. Do not broaden Principal or drop conditions unless the policy is missing the identity/trust relationship itself.

Frequently Asked Questions

Why does s3:GetObject need DOC-EXAMPLE-BUCKET/* instead of the bucket ARN?

s3:GetObject is an object-level action, so its Resource must identify objects under the bucket; the bare bucket ARN covers bucket-level operations such as listing.

Does changing the Principal in option A fix Lambda's S3 read error?

No. The failure is the Resource path for GetObject, so changing Principal and removing the Condition does not grant access to the objects.

More SCS-C03 FAQ →

Related Analysis

Practice All SCS-C03 Questions

Access 86 questions with complete answers and detailed explanations.

View Full SCS-C03 Practice Test →

← Back to SCS-C03 Study Guide