SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a VPC endpoint for DynamoDB and attach it to the Lambda function.

  Why it's wrong here

  A VPC endpoint is a networking component that provides private connectivity between a VPC and DynamoDB, but Lambda functions are not 'attached' to endpoints; you would need to configure the function to run inside a VPC that has the endpoint. More importantly, even with private network connectivity, DynamoDB still requires IAM authentication and authorization for every request. The endpoint only solves the network path—it does not grant any identity-based permissions to the Lambda function.

• ✗

  Configure a network ACL to allow traffic from Lambda to DynamoDB.

  Why it's wrong here

  Network ACLs are stateless filters applied at the subnet boundary, and they can only allow or deny traffic by IP address, port, and protocol; they are not evaluated for whether a Lambda function has permission to call DynamoDB. Even if you add outbound rules to permit HTTPS traffic to DynamoDB's IP ranges, the DynamoDB API will reject requests from an unauthenticated identity. Lambda's ability to access DynamoDB is governed entirely by the IAM role attached to the function, not by network rules.

• ✗

  Add the Lambda function as a principal in the DynamoDB table's resource-based policy.

  Why it's wrong here

  DynamoDB does not support resource-based policies in the way that services like S3 or SNS do; you cannot attach a statement to a table that lists the Lambda function as a principal. The DynamoDB authorization model is identity-based only: all permissions must be attached to the IAM principal that is calling the API. Therefore, even if such a policy were syntactically possible, it would not be enforced, and the Lambda function would still need an IAM role.

• ✓

  Assign an IAM role to the Lambda function with DynamoDB permissions.

  Why this is correct

  The correct and only supported mechanism is to attach an IAM execution role to the Lambda function. When the function runs, the Lambda service assumes this role using the service principal `lambda.amazonaws.com`, and the temporary credentials obtained from STS are used to sign all DynamoDB API requests. The role's managed or inline policies must explicitly allow the desired actions (e.g., `GetItem`, `PutItem`) on the target table, and DynamoDB evaluates these permissions for each request, making the role the sole source of access control.

Go deeper

Related to this question