Authentic Amazon Web Services Certification Exam DVA-C02 Questions Answers

The requirement is to keep profile pictures private in S3 while allowing the browser to display them each time an employee logs in. The standard AWS pattern is to store objects in a private bucket and provide time-limited access through S3 presigned URLs. A presigned URL grants temporary permission to perform a specific operation (such as GET) on a specific object, and it expires automatically after a configured duration. This prevents public access while still allowing simple browser retrieval.

Option D is the viable long-term solution because it stores only the S3 object key (a stable identifier) in DynamoDB and generates a fresh presigned URL at login time. This is important because presigned URLs expire; storing a presigned URL (option A) would eventually store an expired URL and force extra complexity to refresh records. Generating a new presigned URL when needed ensures the link is always valid and keeps the expiration window tight, which improves security.

Option B is not appropriate for employee browsers in general: a VPC endpoint is for traffic from resources inside a VPC (EC2, Lambda in VPC, etc.). Employee browsers on the public internet cannot use a private VPC endpoint to reach S3. Option C is not viable for “no size limit” images: DynamoDB has strict item size limits, base64 inflates data size, and storing large binary blobs in DynamoDB is inefficient and expensive compared to S3.

Therefore, D best meets the requirement: keep images private in S3, store the S3 key in DynamoDB, and generate a presigned URL on each login to provide secure, temporary access for display.

When using AWS SAM local (sam local invoke, sam local start-api), the Lambda code runs in a local container on the developer’s machine. If that code uses the AWS SDK to call AWS services, it needs AWS credentials available in the local environment. The recommended way is to rely on the AWS SDK’s standard credential provider chain, which includes credentials stored by the AWS CLI in ~/.aws/credentials and selected via a named profile.

By running aws configure --profile , the developer creates a dedicated set of access keys (and optionally a session token/region) for the test account. Then, running SAM with sam local invoke --profile causes SAM to supply those credentials to the local container so the function can authenticate to AWS and make real API calls in the intended test account. This approach is clean, repeatable, and avoids hardcoding secrets into templates or source code.

Option A is insecure and not the intended use of SAM templates; templates are infrastructure definitions, not secret stores. Option C sets the Lambda execution role for deployed functions in AWS, but it does not automatically grant credentials to code running locally on a laptop. Option D misuses --parameter-overrides, which is meant for overriding template parameters at deployment/build time, not for securely injecting AWS access keys into local execution.

Therefore, the correct approach is B: configure an AWS CLI profile and run SAM local with the --profile option so the Lambda code can call AWS APIs in the test account using standard credential handling.