Cloud Application Security →hardMultiple Choice

CCSP Cloud Application Security Practice Question

A company uses a serverless architecture with AWS Lambda to process user-uploaded files. The Lambda function is triggered by an S3 bucket event. While reviewing security, the architect wants to ensure that the Lambda function cannot be invoked by unauthorized S3 buckets or accounts. What is the most secure configuration?

⚠ Common exam trap

A common mix-up: candidates confuse network-level controls (like VPC placement or IP filtering) with identity-based access controls, failing to realize that S3 event notifications invoke Lambda through AWS's internal service-to-service channel, which bypasses network restrictions and requires explicit resource-based policy conditions.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Configure the Lambda function's resource-based policy to grant permission only to the specific S3 bucket ARN and its owner account.

The most secure way to restrict Lambda invocation to a specific S3 bucket is to use a resource-based policy that explicitly grants the `lambda:InvokeFunction` permission only to the trusted bucket's ARN and the owning AWS account. This ensures that even if another S3 bucket or account attempts to trigger the function, the invocation is denied by the Lambda permission model, which evaluates both the resource-based policy and the caller's identity.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use a condition in the policy that checks the source IP address.
Why it's wrong here
Lambda invocations originate from AWS service infrastructure, not fixed addresses, so an IP condition cannot identify the calling bucket or account. It is tempting because IP restrictions genuinely secure API Gateway or on-premises callers with stable egress ranges.
✗
Place the Lambda function inside a VPC with a VPC endpoint for S3.
Why it's wrong here
A VPC endpoint governs the function's outbound traffic to S3, not which buckets or accounts may invoke it; invocation authorisation lives in the resource-based policy. It is tempting because VPC placement is a real hardening step for data exfiltration paths, but it addresses egress, not ingress.
✓
Configure the Lambda function's resource-based policy to grant permission only to the specific S3 bucket ARN and its owner account.
Why this is correct
A resource-based policy naming the exact S3 bucket ARN and owner account restricts invocation to that single source, satisfying the requirement that unauthorised buckets or accounts cannot trigger the function. Broader service principals would permit other buckets.
✗
Attach a resource-based policy that allows any S3 bucket to invoke the function.
Why it's wrong here
Allowing any S3 bucket to invoke the function is precisely the cross-account exposure the architect must prevent, so it inverts the requirement. It is tempting because broad invoke permissions simplify initial event-source wiring during prototyping, before source-account restrictions are added.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

CCSP Cloud Application Security Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question