Amazon Web Services Updated DVA-C02 Exam Questions and Answers by constance

AWS Lambda allocates CPU, network throughput, and other resources proportionally to the function’s configured memory . If a Lambda function is CPU-bound (common for image manipulation such as resizing and thumbnail generation) or limited by I/O throughput, increasing the configured memory often improves performance because it also increases the amount of CPU available to the function. This is a standard Lambda optimization technique: tune memory to reduce runtime and achieve a lower latency target.

In this scenario, the thumbnail generation is taking more than 2 minutes, but the requirement is to process each image in under 30 seconds. Without changing the code, the most direct lever is to increase the function’s memory setting and retest. As memory increases, Lambda provides more compute power, which can significantly speed up CPU-intensive libraries (for example, image decoding, resizing, encoding) and reduce overall execution time. Many workloads show near-linear improvements until other bottlenecks (such as downstream service latency) dominate.

Options A and B are not applicable to Lambda in this way. Lambda does not let you directly select a fixed number of vCPUs or choose an EC2 instance type such as m6a.4xlarge for a function; those are EC2 concepts, not Lambda configuration parameters. Option D (“burstable performance”) is also not a Lambda configuration model; burstable performance applies to certain EC2 instance families, not Lambda’s managed execution environment.

Therefore, the correct action is C : increase the Lambda function’s memory allocation (which also increases available CPU and throughput). This is the AWS-supported way to improve performance for compute-intensive Lambda functions and is the most likely to bring processing time down toward the 30-second requirement without code changes.

The workload is explicitly very I/O intensive and requires reading the same file multiple times. Reading repeatedly from S3 across the network will introduce latency and repeated network I/O. For best performance, the function should download the file once to fast local storage and perform all repeated reads locally.

AWS Lambda provides ephemeral storage mounted at /tmp. AWS allows increasing this ephemeral storage beyond the default size. Because the files are at most 2 GB, the developer can configure the Lambda function’s ephemeral storage to 2 GB and copy each S3 object into /tmp before processing. This converts repeated network reads into repeated local filesystem reads, which is significantly faster and more consistent for I/O-heavy workloads.

Option D (read directly from S3) is the least optimized because each pass over the file requires additional network I/O and S3 GET requests.

Option A is not feasible: Lambda cannot directly attach and manage an EBS volume like an EC2 instance can.

Option B is not applicable: ENA is an EC2 networking feature; Lambda networking is managed by the service and does not allow attaching ENAs for performance tuning in that way.

Because the files are disposable after processing, using ephemeral /tmp storage is also cost-effective and operationally simple, and it is aligned with the “process once per file” pattern.

Therefore, increase Lambda ephemeral storage and copy the video into /tmp for repeated reads.

Amazon API Gateway provides tools for creating and documenting web APIs that route HTTP requests to Lambda functions2. You can secure access to your API with authentication and authorization controls. Your APIs can serve traffic over the internet or can be accessible only within your VPC2. You can override the cache method in the selected stage of API Gateway2. Therefore, option B is correct.

A feature branch is a branch that is created from the main branch to work on a specific feature or task1. Feature branches allow developers to isolate their work from the main branch and avoid conflicts with other changes1. Feature branches can be merged back to the main branch when the feature or task is completed and tested1.

In this scenario, the developer needs to maintain two parallel streams of work: one for fixing and updating the current version of the application that is deployed in production, and another for developing the new version of the application. The developer can use feature branches to achieve this goal.

The developer can create a feature branch from the main branch for production bug fixes. This branch will contain the code that is currently deployed in production, and any fixes or updates that need to be applied to it. The developer can push this branch to the CodeCommit repository and use it to deploy changes to the production environment.

The developer can also create a second feature branch from the main branch for development of the new version of the application. This branch will contain the code that is under development for the new version, and any changes or enhancements that are part of it. The developer can push this branch to the CodeCommit repository and use it to test and deploy the new version of the application in a separate environment.

By using feature branches, the developer can keep the main branch stable and clean, and avoid mixing code from different versions of the application. The developer can also easily switch between branches and merge them when needed.