Free Practice Questions for Amazon Web Services DVA-C02 Exam

AWS Lambda layers are specifically designed to share common code and dependencies across multiple Lambda functions. A layer is a ZIP archive that contains libraries, a custom runtime, or other function dependencies. Layers are versioned, so the developer can publish a new layer version when libraries change and then update functions to reference the new version. This directly meets the requirements to centralize libraries, update conveniently, and keep libraries versioned—while requiring minimal development work.

Using a single shared layer significantly reduces duplication across function deployment packages. It also simplifies CI/CD because the developer can build and publish the layer independently and reuse it across many functions.

Option A (CodeArtifact) is useful for dependency management, but it still requires each Lambda deployment to package dependencies or download them during build. It’s more moving parts than a layer for this use case.

Option B (container images) can centralize dependencies but typically requires more effort: building, scanning, versioning container images, and updating function image URIs. It’s heavier operationally than layers for “shared custom libraries.”

Option D (EFS) can be mounted by Lambda, but introduces networking considerations (VPC config), EFS lifecycle/permissions, and is unnecessary for simply sharing libraries. Also, cold start and operational overhead can increase.

Therefore, creating a Lambda layer for the shared libraries is the least-effort, most standard approach.

The standard best practice for Elastic Beanstalk is to externalize configuration using Environment Variables. By storing sensitive API keys in SSM Parameter Store as a SecureString , you gain encryption and rotation capabilities. You then reference the parameter in the Elastic Beanstalk environment. The application can retrieve the value at runtime, and if the key is updated in Parameter Store, the application can pick up the change without needing a full code redeployment.

The best answer is to request a public certificate in AWS Certificate Manager and validate it with DNS. ACM manages public certificate renewal automatically when validation remains in place, which minimizes operational overhead. DNS validation is preferable to email validation because it does not require manual approval emails during renewal workflows. IAM server certificates are legacy-style certificate storage and do not provide the same managed lifecycle experience as ACM. Imported certificates are not automatically renewed by ACM because ACM does not control their issuance lifecycle. For CloudFront, AWS recommends ACM certificates, and CloudFront certificates must be requested or imported in the US East (N. Virginia) Region, although the option’s key point is ACM public certificate with DNS validation. ( AWS Documentation )

===============

Amazon Cognito User Pools: A managed user directory service, simplifying user registration and login.

Social Identity Providers: Cognito supports integration with external providers (e.g., Google, Facebook), reducing development effort.

IAM Roles for Authorization: Cognito-managed IAM roles grant fine-grained access to AWS resources (like Lambda functions).

Operational Overhead: Cognito minimizes the need to manage user identities and credentials independently.

Comprehensive and Detailed Step-by-Step Explanation:

To confirm that the HTTP headers, body, and responses meet expectations, you need to test the specific HTTP Task state in isolation and inspect the details.

Option A: TestState API with TRACE:

The TestState API allows developers to test individual states in a state machine without executing the entire workflow.

Setting the inspection level to TRACE provides detailed information about the HTTP request and response, including headers, body, and status codes.

This option provides the precise and granular testing required to verify the HTTP Task functionality.

Why Other Options Are Incorrect:

Option B: The DEBUG inspection level provides less detailed information than TRACE and focuses on general debugging, not a detailed view of HTTP interactions.

Option C: Step Functions does not have a " data flow simulator " to test individual tasks; this option is not valid.

Option D: Changing the state machine’s log level to ALL increases logging granularity for the entire state machine but does not allow isolated testing of a specific HTTP Task.

The requirement is to test a new Lambda version without impacting the production API, and to do so with the least operational overhead. In API Gateway (REST API), the simplest pattern is to create a separate stage (for example, test) and use a stage variable to control which Lambda function version (or alias) the integration invokes.

With option B, the developer creates a new stage and defines a stage variable (commonly something like lambdaAlias or lambdaVersion). The API method integration URI can reference this stage variable so that each stage points to a different Lambda alias/version. The production stage (for example, prod) continues to call the stable version, while the test stage calls the new version. This cleanly isolates testing traffic and prevents any effect on the production REST API because stages have distinct invoke URLs and deployments.

This approach is operationally efficient because it avoids duplicating the API definition (new REST API) and avoids creating extra resources/methods that must be maintained. It also provides a repeatable process: future versions can be tested by updating only stage variables or alias routing rather than restructuring the API.

Why not the others:

A adds additional resources/methods and increases API surface area and maintenance.

C duplicates the entire API, increasing overhead and configuration drift risk.

D would impact production because it changes the integration used by the existing method.

Therefore, using a new stage + stage variables to route to the updated Lambda version meets the requirements with minimal overhead.

The correct policy condition ensures that:

The LeadingKeys condition restricts operations to the authenticated user ' s user_id.

The Attributes condition limits the updatable attributes to user_name.

Explanation of Choices:

Option A: Correctly enforces both the key restriction (dynamodb:LeadingKeys) and ensures only the user_name attribute can be updated.

Option B, C, D: Use incorrect conditions, such as referencing user_name in the LeadingKeys or including other attributes like user_id in updatable fields.

AWS CodeBuild supports parallel test execution through batch builds and multiple compute environments. This feature allows a single CodeBuild project to divide test workloads across multiple isolated environments that run concurrently. Each environment executes a subset of the test suite, significantly reducing total build time.

AWS documentation emphasizes using native CodeBuild capabilities to minimize operational complexity. Parallel execution eliminates the need to manually manage infrastructure, test orchestration logic, or EC2 fleets. CodeBuild automatically provisions and terminates build environments, scales as needed, and integrates seamlessly with CI/CD pipelines.

Options A and D require manual coordination and infrastructure management, increasing operational overhead. Option C does not address the performance problem.

Therefore, using CodeBuild’s parallel compute environments is the most efficient and AWS-recommended approach.

“Encryption in transit” means the connection between the client (EC2 instances) and Amazon S3 must use TLS/HTTPS , not plain HTTP. The most direct way to enforce this at the bucket level is an S3 bucket policy that denies any request that is not using secure transport. AWS provides the global condition key aws:SecureTransport , which evaluates to true when a request is made over HTTPS and false when made over HTTP.

By adding an explicit Deny statement conditioned on aws:SecureTransport = false, the bucket rejects any insecure requests regardless of who makes them. This ensures that even if an application is misconfigured (or a user tries to access the bucket over HTTP), S3 will refuse the request. This is a strong enforcement mechanism because explicit denies in IAM policies override allows.

Option C (SSE-KMS) provides encryption at rest , not in transit. It protects objects while stored in S3 but does not force clients to use TLS for transport. Option B (VPC endpoint) can keep traffic on the AWS network path and can be combined with endpoint policies, but it does not inherently guarantee TLS usage unless you also enforce HTTPS. Option A (installing certificates) is not the mechanism for controlling whether the application uses HTTPS to S3; the S3 client uses AWS-managed TLS endpoints, and enforcement should happen through policy.

Therefore, the correct solution is D : create an S3 bucket policy that denies requests when aws:SecureTransport is false, ensuring all access uses encrypted transport (HTTPS/TLS).

Comprehensive and Detailed 250 to 300 words of Explanation From AWS Developer Documents:

The key requirement in this scenario is that the data must be encrypted before it is uploaded to Amazon S3 , and the data is generated outside of AWS . This explicitly points to a client-side encryption requirement.

AWS documentation distinguishes clearly between server-side encryption and client-side encryption . Server-side encryption options for Amazon S3—including enabling default bucket encryption or specifying the x-amz-server-side-encryption request header—encrypt the data after it is received by Amazon S3. Therefore, options B and D do not satisfy the requirement because the plaintext data is transmitted to AWS before encryption occurs.

Option A, using the AWS KMS encrypt command, is not suitable for large binary objects. AWS KMS is designed to encrypt small pieces of data (up to 4 KB). AWS documentation explicitly states that for large payloads, customers should use envelope encryption instead of directly encrypting data with AWS KMS.

The AWS Encryption SDK is specifically designed for client-side encryption of large data objects. It implements envelope encryption , where a data encryption key (DEK) is generated locally to encrypt the data, and the DEK is then encrypted with an AWS KMS key. This approach allows efficient encryption of large binary files while maintaining strong key management and security controls.

AWS documentation recommends the AWS Encryption SDK for applications that need to encrypt data before sending it to AWS services , including Amazon S3. It supports multiple programming languages, handles key management automatically, and ensures data confidentiality even before transmission.

Therefore, using the AWS Encryption SDK for client-side encryption is the only solution that fully satisfies all requirements.

The requirement is to automatically delete objects for basic users after 90 days with the least development effort. Amazon S3 provides a built-in, fully managed feature for this: S3 Lifecycle configuration rules . Lifecycle rules can filter objects by prefix (and/or tags) and then perform actions such as expiring (deleting) objects after a specified number of days since creation. Because the bucket does not have versioning enabled, the relevant action is to expire the current object after the retention period.

Option C matches this exactly: create an S3 Lifecycle rule that applies only to objects under the basic/ prefix and configure the rule to expire current versions after 90 days . S3 then automatically and continuously enforces the policy without any code, scheduling, or operational maintenance. This is typically the lowest-effort and most reliable approach because it is handled by S3 itself.

Option A requires writing and operating a Lambda function plus a scheduler, handling pagination, permissions, error handling, retries, and potential costs and throttling when scanning large buckets. That is more development and operational effort than a lifecycle rule. Option B is incorrect because it targets the premium/ prefix, but premium objects must be retained indefinitely. Option D refers to delete markers and unfinished multipart uploads; delete markers are relevant primarily for versioned buckets , and cleaning up multipart uploads does not implement the required “delete basic objects after 90 days” behavior.

Therefore, the correct solution is C : use an S3 Lifecycle rule scoped to the basic/ prefix to expire objects after 90 days, achieving automated retention with minimal development effort.

The correct answer is D because the current DynamoDB table design is causing a hot partition problem. The table uses order_date as the partition key, which means that during peak ordering periods, a very large number of writes are likely targeting the same partition key value for the current date. In DynamoDB, write throttling often occurs when traffic is not evenly distributed across partition keys, even when the table uses on-demand mode . On-demand capacity can automatically scale, but it still depends on proper key distribution to avoid concentrated activity on a small number of partitions.

By changing the partition key to customer_id and using order_id as the sort key, writes will be spread across many customers instead of being concentrated on a small number of date values. This creates a more balanced write pattern and better aligns with DynamoDB best practices for high-scale workloads. DynamoDB documentation emphasizes choosing partition keys with high cardinality and even request distribution to avoid throttling and improve performance.

Option A is not a good design because a sequential partition key can still create uneven access patterns and usually does not support meaningful access requirements. Option B is not the best answer because simply increasing capacity does not fix a poor partition key design; hot partitions can still throttle. Option C is unnecessary because the issue is not that DynamoDB is the wrong service, but that the table schema needs redesign.

Therefore, the best solution is to refactor the key schema so that writes distribute more evenly across partitions, which is exactly what D achieves.

Lambda Layers: These are designed to package dependencies that you can share across functions.

How to Use:

Create a layer, upload your 100MB library as a zip.

Attach the layer to your function.

In your function code, import the library from the standard layer path.