Free DVA-C02 Practice Test

Amazon S3 is an object storage service designed for high availability and 99.999999999% (11 nines) of durability by redundantly storing data across multiple Availability Zones. This makes it an ideal, highly available repository for configuration files. By updating the application to use the AWS SDK, the EC2 instances can directly and concurrently access the configuration files from the S3 bucket. This serverless approach is the most cost-effective as it eliminates the need to provision and manage dedicated EC2 instances or block storage for a file server, and you only pay for the S3 storage and requests made.

A. This solution creates a single point of failure. If the EC2 instance hosting the EBS share fails, the entire application loses access to its configuration, violating the high availability requirement.
B. Instance store is ephemeral and not persistent. Any data on an instance store volume is lost if the instance is stopped or terminated, making it unsuitable for a configuration repository.
D. Mounting an S3 bucket as a local volume adds a layer of abstraction (e.g., using s3fs-fuse) that can introduce performance and consistency complexities compared to native SDK calls, making it a less optimal solution.

1. Amazon S3 Features: The official documentation states

"Amazon S3 is designed for 99.999999999% (11 9's) of durability

and stores data for millions of applications for companies all around the world... S3 Standard is designed for 99.99% availability over a given year." This supports its use for a highly available repository.

Source: AWS Documentation

"Amazon S3 Features

" section on "Durability and data protection."

2. Amazon EC2 Instance Store: The documentation clarifies the non-persistent nature of instance stores: "The data in an instance store persists only during the life of its associated instance. If an instance reboots (intentionally or unintentionally)

data in the instance store persists. However

data in the instance store is lost under any of the following circumstances: The underlying drive fails

The instance stops

The instance hibernates

The instance terminates."

Source: AWS Documentation

"Amazon EC2 User Guide for Linux Instances

" section "Amazon EC2 instance store."

3. Amazon EBS Volumes: The documentation explains that a standard EBS volume is attached to a single instance within a specific Availability Zone. "An Amazon EBS volume is a durable

block-level storage device that you can attach to a single EC2 instance." This confirms that sharing it from one instance (as described in option A) makes that instance a single point of failure.

Source: AWS Documentation

"Amazon EC2 User Guide for Linux Instances

" section "Amazon EBS volumes."

4. Accessing S3: The AWS SDK Developer Guides provide the canonical method for applications to interact with S3. "The AWS SDK for [Language] provides an API for the Amazon S3 bucket and object operations." This confirms that using the SDK is the intended and direct method for programmatic access.

Source: AWS Documentation

"AWS SDK for .NET Developer Guide

" section "Amazon S3 examples."

AWS Step Functions is the ideal service for orchestrating long-running, stateful, and resilient serverless workflows. The scenario describes a process that may now take multiple days, exceeding the 15-minute AWS Lambda execution limit. A Step Functions state machine can manage the overall process state for up to a year. It can invoke the Lambda function to make API calls, use its built-in Catch mechanism to handle specific throttling errors returned by the third-party service, and then transition to a Wait state to pause execution. This creates a robust loop that respects the API rate limits (both per-minute and daily) without losing progress, making it the most operationally efficient solution.

B: Amazon SQS is for decoupling components, not for orchestrating a multi-day stateful workflow. Managing the overall process state and daily limits would require complex custom logic. C: This is a destructive and reactive approach. Abruptly stopping a Lambda function via a CloudWatch alarm would cause the loss of any in-progress work and state. D: Amazon Kinesis Data Firehose is a service for ingesting and delivering streaming data. It is not designed for making outbound API calls or managing workflow orchestration.

1. AWS Step Functions Developer Guide, "What is AWS Step Functions?": This document introduces Step Functions as a serverless orchestration service for coordinating components of distributed applications, including AWS Lambda functions, which is the core requirement of the question.

2. AWS Step Functions Developer Guide, "Error handling in Step Functions": This section details the use of Retry and Catch fields within a state definition. This directly supports the solution of catching API throttling errors and taking corrective action, such as waiting.

3. AWS Step Functions Developer Guide, "Wait state": This page describes the Wait state, which "delays the state machine from continuing for a specified time." This is the mechanism used to pause the workflow to comply with the third-party service's rate limits.

4. AWS Lambda Developer Guide, "Lambda quotas": Under the "Lambda function configuration, deployment, and execution quotas" table, the Timeout is listed with a maximum value of 900 seconds (15 minutes). This confirms that a single Lambda function cannot handle a process that runs for multiple days, necessitating an orchestrator like Step Functions.

The core issue identified is the latency caused by Lambda "cold starts," which is the time it takes to initialize a new execution environment. Provisioned Concurrency is a feature specifically designed to solve this problem for latency-sensitive applications. It works by initializing a specified number of execution environments and keeping them "warm" and ready to respond instantly to incoming requests. By routing invocations to these pre-initialized environments, the cold start latency is completely eliminated for those requests, directly addressing the performance issue.

A. Reserved concurrency guarantees that a certain number of concurrent executions are available for a function, preventing it from being throttled, but it does not keep execution environments pre-initialized or "warm."
B. Increasing the function's timeout allows it to run for a longer duration before being terminated. It has no impact on the initial startup time or cold start latency.
C. Increasing memory allocation also increases CPU power, which can reduce the duration of a cold start. However, it does not prevent the cold start from occurring in the first place.

1. AWS Lambda Developer Guide, "Configuring provisioned concurrency": "For latency-sensitive applications, you can use provisioned concurrency to keep your functions initialized and warm, ready to respond in double-digit milliseconds. Provisioned concurrency is the number of pre-initialized execution environments that you allocate to your function."

2. AWS Lambda Developer Guide, "Lambda function scaling": This section contrasts the different concurrency controls. It explains that on-demand functions scale from zero, incurring a cold start, while "for functions with provisioned concurrency, Lambda pre-initializes the requested number of execution environments."

3. AWS Lambda Operator Guide, "Performance optimization - Function initialization": "To reduce the duration of initialization, we recommend that you... configure provisioned concurrency for any function that has strict cold start latency requirements." This explicitly recommends provisioned concurrency as the solution for the problem described.

This solution is the most cost-effective and scalable for handling a large and unpredictable number of image variants. A Lambda@Edge function, triggered by an origin request in CloudFront, can process images on-the-fly based on the GET parameters. The crucial step for cost-effectiveness is storing the newly created image variant back into an Amazon S3 bucket. This ensures that the computationally expensive optimization process runs only once for each unique image size. Subsequent requests for the same variant, even after the CloudFront cache expires or from a different edge location, can be served directly from S3 without invoking the image processing logic again, thus saving significant compute costs over time.

A. Pre-processing all possible variants with S3 Batch Operations is not cost-effective. It generates high compute and storage costs for many variants that may never be requested.
B. This option also relies on pre-processing with S3 Batch Operations, which is inefficient and costly for hundreds of potential device dimensions for every single photo stored.
C. This approach is inefficient because the Lambda@Edge function would re-process the original image on every cache miss, leading to redundant compute operations and higher costs.

1. AWS Solutions Library

"Serverless Image Handler": This official AWS solution implements the exact pattern described in the correct answer. The documentation states

"The solution generates resized

optimized images on demand... It uses Amazon CloudFront to cache the generated images and serve them from the cache on subsequent requests." This confirms the on-demand processing and caching approach.

Source: AWS Solutions Library

Serverless Image Handler

Solution overview.

2. AWS Compute Blog

"Image resizing at scale with AWS Lambda and Amazon EFS": This blog post discusses on-the-fly image processing. While it uses a different trigger

it highlights the core principle: "The main benefit of this approach is that you only generate the image sizes that you need

when you need them. This saves on storage costs and processing time." This supports the on-demand model over pre-processing.

Source: AWS Compute Blog

May 18

2022

"Image resizing at scale with AWS Lambda and Amazon EFS".

3. Amazon CloudFront Developer Guide

"Example: Resizing an image": The official documentation provides an example of using a Lambda@Edge function triggered on an origin request to resize images. The logic involves checking if a resized image already exists in S3 before attempting to create it

which is the pattern in the correct answer.

Source: Amazon CloudFront Developer Guide

Section: "Lambda@Edge example functions"

Subsection: "Example: Resizing an image".

The primary query requirement is to find reviews for a specific Product ID and sort them by Product Rating. The base table's partition key is Review ID, which cannot be used to efficiently query by Product ID. A Global Secondary Index (GSI) is required to support a query pattern on attributes different from the base table's primary key. By creating a GSI with Product ID as the partition key, you can efficiently query for all reviews associated with a single product. Adding Product Rating as the sort key allows DynamoDB to store and retrieve the items for that product pre-sorted by rating. This combination directly and most efficiently addresses the query "find the 10 reviews with the highest rating for a given product."

B. This GSI would sort results by Review ID, not Product Rating, forcing the application to fetch all reviews for a product and perform inefficient client-side sorting.
C. A Local Secondary Index (LSI) is invalid here because it must share the same partition key as the base table (Review ID), but this option proposes Product ID.
D. This LSI uses the correct partition key (Review ID) for an LSI but does not help the query, which needs to filter by Product ID, not Review ID.

1. AWS DynamoDB Developer Guide, "Core components of Amazon DynamoDB": Under the "Primary Key" section, it explains that a composite primary key (partition key and sort key) allows for efficient querying and sorting. The query pattern in the question requires filtering on one attribute (Product ID) and sorting on another (Product Rating), which maps directly to a composite key structure.

2. AWS DynamoDB Developer Guide, "Improving data access with secondary indexes": This section states, "If you want to query a table using an attribute that is not part of the table's primary key, you can create a global secondary index." This justifies the need for a GSI since the query is on Product ID, not the base table's key (Review ID).

3. AWS DynamoDB Developer Guide, "Global secondary indexes": This page clarifies that a GSI's key "can be a simple primary key (partition key) or a composite primary key (partition key and sort key)," and crucially, "The primary key of a global secondary index can be different from the primary key of its base table." This supports using Product ID and Product Rating as the GSI's key.

4. AWS DynamoDB Developer Guide, "Local secondary indexes": This page states, "Every local secondary index must have the same partition key as its base table." This directly invalidates option C, which proposes a different partition key (Product ID) for the LSI than the base table's key (Review ID).

The requirement for users to upload data already encrypted with a public key dictates a client-side encryption strategy. Server-side encryption options (SSE-S3, SSE-C, SSE-KMS) encrypt data after it arrives at S3. The scenario describes asymmetric encryption, where a public key encrypts and a private key decrypts. To ensure only the company can decrypt, it must control the private key. This is achieved using a customer-managed key, specifically an asymmetric key pair managed in a service like AWS Key Management Service (KMS). The company distributes the public key to users for encryption, while the corresponding private key remains securely under the company's control within KMS for decryption.

A. SSE-S3 is server-side encryption and uses symmetric keys managed by S3, not an asymmetric key pair controlled by the company.
B. SSE-C is also server-side encryption and uses a symmetric key that the client provides with each request, not an asymmetric key pair.
C. This option is less precise. While a symmetric data key is often used in client-side encryption (envelope encryption), the critical component enabling the required access control is the customer-managed asymmetric key.

1. AWS Key Management Service Developer Guide, "Asymmetric keys in AWS KMS": This guide explains the use case for asymmetric keys: "You can use the public key of an asymmetric KMS key to encrypt data outside of AWS KMS... To decrypt the ciphertext, you must call the Decrypt operation with the same KMS key." This directly maps to the scenario where users encrypt client-side and the company decrypts.

2. Amazon Simple Storage Service User Guide, "Protecting data using client-side encryption": This document defines the method: "Client-side encryption is the act of encrypting data before sending it to Amazon S3." This aligns with the requirement that users upload data that is already encrypted.

3. AWS Key Management Service Developer Guide, "AWS KMS concepts - AWS KMS keys": This section clarifies the nature of customer-managed keys as KMS keys in an AWS account that the customer creates, owns, and manages, which is necessary for the company to control the decryption capability.

Amazon DynamoDB encrypts all tables at rest by default using server-side encryption. The default encryption type is an AWS owned key. This key is owned and managed by the DynamoDB service for use in multiple AWS accounts. Users do not need to create or manage this key, and its use incurs no additional charge. When creating a DynamoDB table using the AWS CLI, omitting any server-side encryption specifications (--sse-specification) results in the table being created with this default encryption setting, thereby fulfilling the requirement.

A. This describes using a customer managed key, which is created and managed by the user, not the required AWS owned key.
B. This describes using an AWS managed key, which is a specific type of KMS key visible in the customer's account, distinct from the default AWS owned key.
C. Users cannot create an AWS owned key or provide its ARN. These keys are managed entirely by the AWS service and are not user-configurable.

1. AWS DynamoDB Developer Guide, "Amazon DynamoDB encryption at rest": This document states, "By default, all DynamoDB tables are encrypted under an AWS owned key. AWS owned keys are a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts. AWS services can use AWS owned keys to protect your data."

2. AWS DynamoDB Developer Guide, "Managing encrypted tables in Amazon DynamoDB": Under the section "Creating an encrypted table," the guide explains that if you do not specify encryption settings, DynamoDB enables encryption using the AWS owned key by default.

3. AWS CLI Command Reference, dynamodb create-table: The documentation for the create-table command shows the optional --sse-specification parameter. If this parameter is not included in the command, the table is created with the default encryption settings (an AWS owned key). The KMSMasterKeyId is only used when SSEType is set to KMS, which corresponds to AWS managed or customer managed keys.

You cannot directly encrypt an existing unencrypted Amazon Machine Image (AMI). To meet the security requirement, a new, encrypted AMI must be created. The correct procedure is to use the CopyImage operation to create a new AMI from the unencrypted source. During this copy process, encryption parameters can be specified, resulting in a new, encrypted AMI in the destination region. This can be done in a single cross-region copy action. Deleting the original unencrypted AMIs is a necessary subsequent step to fully comply with the policy of having only encrypted AMIs.

B: AWS Key Management Service (AWS KMS) provides the encryption keys, but it cannot be used to modify an existing unencrypted AMI. A new, encrypted copy must be created. C: AWS Certificate Manager (ACM) is unrelated to AMI or EBS encryption; it is used for managing SSL/TLS certificates for services like Application Load Balancers and Amazon CloudFront. D: The order of operations is incorrect. Enabling encryption by default after copying the AMI would not encrypt the already-copied resource. The setting must be active before the copy begins.

1. AWS EC2 User Guide for Linux Instances, "Copy an AMI": In the section "Cross-Region copy and encryption," the documentation states, "You can copy an AMI with an unencrypted root device volume to the same or a different Region and encrypt the root device volume of the new AMI in the process." This directly supports the method described in option A.

2. AWS EC2 User Guide for Linux Instances, "Amazon EBS encryption": In the section "Encryption by default," the documentation explains, "If you enable encryption by default, Amazon EBS and snapshot encryption is enabled for your account on a per-Region basis... When you copy an unencrypted AMI and encryption by default is enabled, the new AMI is encrypted." This explains the mechanism that option D attempts to use but gets the order wrong. It also reinforces that a new encrypted resource is created.

3. AWS CLI Command Reference, ec2 copy-image: The documentation for the copy-image command includes the --encrypted parameter, which "specifies whether to encrypt the new AMI." This confirms that encryption is specified during the creation of the new copy.

To grant an AWS Lambda function access to resources within a Virtual Private Cloud (VPC), you must configure it to connect to that VPC. This process involves creating an Elastic Network Interface (ENI) within the specified private subnets of the VPC. By placing the function in private subnets, it can communicate with other resources, such as databases or EC2 instances, using their private IP addresses. A security group must be associated with the Lambda function's ENI to act as a virtual firewall, with rules that explicitly allow traffic to and from the target private resources. This is the standard and most direct method for this use case.

B: A VPN connection is primarily for connecting an on-premises network or another VPC to your VPC, not for a Lambda function to access resources within the same VPC. C: A VPC endpoint is used for private access to supported AWS services (like S3 or DynamoDB) from within a VPC, not for a Lambda function to access general private resources like an RDS database. D: AWS PrivateLink is a more complex solution designed to expose a service in one VPC to consumers in another VPC securely, which is unnecessary for intra-VPC communication.

1. AWS Lambda Developer Guide

Configuring a Lambda function to access resources in a VPC: "When you connect a function to a VPC

Lambda creates an elastic network interface (ENI) for each combination of security group and subnet in your function's VPC configuration... To connect to private resources

connect your function to private subnets."

2. AWS VPC User Guide

Security groups: "A security group acts as a virtual firewall for your instance to control inbound and outbound traffic... When you associate a security group with an ENI that's attached to a Lambda function

you can control the inbound and outbound traffic for the function." (Section: Security group basics).

3. AWS VPC User Guide

What is a VPC endpoint?: "A VPC endpoint enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by AWS PrivateLink without requiring an internet gateway

NAT device

VPN connection

or AWS Direct Connect connection." (This clarifies the purpose of VPC endpoints is for AWS services

not general resources within the VPC).

The most cost-effective approach for a proof of concept with minimal, intermittent traffic is a serverless architecture. AWS Lambda functions are billed based on the number of requests and execution duration, meaning there are no costs when the application is idle. This aligns perfectly with the "small amount of traffic only during testing" requirement. Amazon API Gateway provides the necessary REST endpoint and has built-in caching capabilities to limit requests to the backend Lambda function, fulfilling another key requirement. AWS Serverless Application Model (SAM) is the standard framework for efficiently defining and deploying such serverless applications, making this the optimal solution.

A. Amazon EKS has a control plane cost and requires running worker nodes, making it expensive and overly complex for a simple, low-traffic proof of concept.
C. Amazon ECS, even with AWS Fargate, is less cost-effective than Lambda for very low traffic, as it provisions resources for longer durations than a single Lambda invocation.
D. AWS Elastic Beanstalk provisions underlying resources like EC2 instances and an Application Load Balancer, which incur continuous costs regardless of traffic, making it unsuitable for this use case.

1. AWS Lambda Pricing: "With AWS Lambda

you pay only for what you use. You are charged based on the number of requests for your functions and the duration... The Lambda free tier includes 1M free requests per month." This supports the cost-effectiveness for low traffic.

Source: AWS Lambda Pricing

aws.amazon.com/lambda/pricing/.

2. Amazon API Gateway Caching: "You can enable API caching in Amazon API Gateway to cache your endpoint's responses. With caching

you can reduce the number of calls made to your endpoint and also improve the latency of requests to your API."

Source: AWS API Gateway Developer Guide

"Enabling API caching to enhance responsiveness".

3. AWS Serverless Application Model (SAM): "The AWS Serverless Application Model (AWS SAM) is an open-source framework for building serverless applications. It provides shorthand syntax to express functions

APIs

databases

and event source mappings."

Source: AWS SAM Developer Guide

"What is the AWS Serverless Application Model (AWS SAM)?".

4. AWS Compute Services Overview: The official documentation often presents Lambda as the ideal choice for event-driven workloads with infrequent or unpredictable traffic

contrasting it with container services (ECS/EKS) for long-running applications and Elastic Beanstalk for traditional web applications.

Source: AWS Whitepaper

"AWS Well-Architected Framework - Serverless Applications Lens"

Page 5

"When to choose a serverless approach".