Development with AWS Services practice questions

Increase the reserved concurrency to 10.

Why wrong: The requirement is to NOT increase reserved concurrency. Increasing reserved concurrency would allow more concurrent executions but violates the constraint.

Reduce the batch size to 1.

Why wrong: Reducing the batch size would increase the number of invocations, leading to more throttling and lower throughput.

Enable the SQS queue to use long polling.

Why wrong: Long polling helps reduce empty responses and cost, but it does not directly increase throughput or reduce throttling. The issue is throttling due to insufficient capacity per invocation.

Increase the memory allocation of the Lambda function

Why wrong: More memory increases CPU and speed per invocation but does not address the concurrency throttling limit.

Switch the SQS queue to a FIFO queue

Why wrong: FIFO queues have lower throughput and are not designed for high-volume processing; this would likely worsen performance.

Decrease the batch size back to 10

Why wrong: This would reduce throttling but also reduce the number of messages processed per invocation, thus not improving throughput.

Amazon ElastiCache for Redis

Why wrong: Incorrect. While ElastiCache can cache data, it requires custom code to manage caching logic and is not as tightly integrated with DynamoDB as DAX.

DynamoDB Global Tables

Why wrong: Incorrect. Global Tables replicate data across regions for disaster recovery and low-latency reads in multiple regions, but they do not cache data for repeated reads in a single region.

DynamoDB Streams

Why wrong: Incorrect. DynamoDB Streams capture modifications to the table, not caching, and would not reduce read latency.

Add a Retry clause in the Lambda function's configuration with a maximum retry count of 3.

Why wrong: Lambda functions do not have a built-in retry configuration; retry logic must be implemented in the caller (Step Functions).

Wrap the Lambda function invocation in a custom while loop within the function code.

Why wrong: This would require modifying the Lambda code and is not a standard pattern; it also loses the benefits of Step Functions orchestration.

Use the Amazon States Language Catch field in the Task state to redirect to a retry logic.

Why wrong: The Catch field is used to handle errors after retries are exhausted or to transition to a different state, not to implement retry logic.

Enable SNS delivery retries for HTTP endpoints

Why wrong: SNS retries are for HTTP subscriptions; SQS subscriptions do not use delivery retries from SNS.

Set the SQS queue's visibility timeout to a value greater than the Lambda function's processing time

Why wrong: Visibility timeout prevents duplicate processing but does not ensure reliability if processing fails permanently.

Configure the SNS topic to use server-side encryption

Why wrong: Encryption protects data at rest, not the reliability of message delivery.

Configure a usage plan with a quota and throttle settings to limit requests per client ID.

Why wrong: Usage plans limit the number of requests but do not cache responses. They would still invoke the Lambda function for each request, just limiting the rate.

Use request validation to reject requests that have the same client ID within 5 minutes.

Why wrong: Request validation checks the structure of the request but cannot detect duplicate payloads or cache responses. It is not designed for this purpose.

Reduce the Lambda function's batch size to 1 and implement caching logic inside the function using an external cache like ElastiCache.

Why wrong: While this could work, it requires custom caching logic and adds complexity. The question asks for an API Gateway feature; the correct answer uses a built-in API Gateway capability.

Enable request validation to reject duplicate requests.

Why wrong: Request validation only validates the request body and parameters against a model. It does not deduplicate requests or cache responses.

Configure a usage plan with a throttle rate to limit requests from each client.

Why wrong: Throttling limits the number of requests but does not provide caching. Duplicate requests would still be processed by Lambda until the throttle limit is reached, and they would not reuse previous responses.

Enable stage variables to store the previous response.

Why wrong: Stage variables are for storing configuration values, not for caching responses. They cannot be used to return cached responses.

The certificate was not issued by a trusted certificate authority.

Why wrong: AWS Certificate Manager (ACM) uses Amazon's trusted CA, so the certificate is valid and trusted by browsers.

The API Gateway API is not deployed to a stage that is mapped to the custom domain name.

Why wrong: If the stage mapping is missing, the user would get a 404 or 'Missing Authentication Token' error, not an SSL error.

The certificate is in the wrong region relative to the API Gateway regional endpoint.

Why wrong: The developer uploaded the certificate to ACM in the same region as the API Gateway endpoint, which is correct. Region mismatch would cause validation errors during setup.

Amazon Simple Workflow Service (SWF)

Why wrong: SWF is a legacy service for orchestrating tasks. It requires more manual management and is not the modern recommended serverless orchestration service; Step Functions is preferred.

AWS Glue

Why wrong: AWS Glue is an ETL (extract, transform, load) service primarily for data preparation for analytics. It is not designed for real-time message processing orchestration.

Amazon MQ

Why wrong: Amazon MQ is a managed message broker service that supports ActiveMQ and RabbitMQ. It does not provide orchestration capabilities.

Lambda custom integration

Why wrong: Custom integration requires mapping templates to transform the request/response, which adds complexity. Proxy integration is simpler for multi-method APIs.

AWS service integration

Why wrong: AWS service integration is used for directly calling other AWS services from API Gateway, not for routing to a Lambda function based on the request.

HTTP integration

Why wrong: HTTP integration is for proxying to an HTTP backend, not for invoking a Lambda function directly.

Enable S3 event notifications with a suffix filter.

Why wrong: A suffix filter only reduces the types of objects that trigger events, but does not prevent duplicate events for the same object.

Use an SQS queue to decouple S3 events.

Why wrong: While an SQS queue can buffer events, it does not guarantee deduplication. Standard queues still deliver at-least-once, and FIFO queues would require a deduplication ID but still may deliver duplicates if the ID is the same.

Increase the Lambda function's timeout.

Why wrong: Increasing the timeout does not affect invocation frequency. Duplicate invocations will still occur.

The Lambda function is configured with a batch size greater than 1, causing multiple messages to be processed at once and some to be duplicated.

Why wrong: Batch processing is supported but does not cause duplicates. All messages in a batch must be deleted individually. If one message fails, the entire batch is not deleted, but duplicates are not inherent.

The SQS queue has a message retention period set too low, causing messages to be deleted automatically and re-queued.

Why wrong: Message retention period only controls how long a message stays in the queue before being deleted permanently. It does not cause duplicates.

The Lambda function's execution role does not have permission to delete messages from the queue.

Why wrong: If the role lacks delete permission, the function will fail but will not cause duplicates; the message would become visible again after visibility timeout. However, this is less likely than the function simply not calling DeleteMessage for other reasons.

The developer must use DynamoDB Streams to capture changes and replicate them separately.

Why wrong: Global tables automatically replicate using the same technology; adding custom replication is unnecessary and does not explain the behavior.

The developer must enable strong consistency reads on the replica table.

Why wrong: Strong consistency reads are not available for global table replicas; they are only supported for the table in the region where the read is performed and only for that table's own data.

The global table must be configured with write forwarding.

Why wrong: Write forwarding ensures writes are applied to the primary region but does not affect read consistency across regions.

Create a single RDS instance with a separate database per microservice.

Why wrong: Separate databases provide logical isolation but do not enforce table-level access; grant privileges at database level, not table.

Use RDS in a VPC and restrict network access per microservice using security groups.

Why wrong: Security groups control network-level access only; they do not restrict which tables can be accessed within the database.

Use Amazon RDS Proxy to control access.

Why wrong: RDS Proxy manages connections and can enforce some access control, but it is not designed for table-level permissions; it primarily handles connection pooling.

Store session state in the /tmp directory of each EC2 instance

Why wrong: The /tmp directory is local to each instance and is lost when the instance is terminated. It cannot be shared across instances, so session will not persist if a user hits a different instance.

Use an Amazon SQS queue to persist session data

Why wrong: SQS is a message queuing service, not designed for low-latency session storage. Retrieving and updating session data on every request via SQS would be inefficient and incorrectly modeled.

Store session state in an Amazon S3 bucket

Why wrong: S3 can store session data, but it introduces higher latency compared to in-memory stores like ElastiCache. Additionally, frequent updates might exceed S3 request limits and incur costs.

Use provisioned capacity with 1 RCU per item, since eventually consistent reads consume half the RCUs.

Why wrong: The RCU consumption depends on item size, not a fixed '1 RCU per item'. Eventual consistency reads use 0.5 RCU per 4KB item, but this option inaccurately describes the cost.

Use provisioned capacity with sufficient RCUs to handle strongly consistent reads, as they consume the same as eventually consistent.

Why wrong: Strongly consistent reads consume twice the RCUs of eventually consistent reads (1 RCU per 4KB item vs. 0.5 RCU).

Use provisioned capacity with enough RCUs for peak traffic, and use DynamoDB Accelerator (DAX) for caching.

Why wrong: Adding DAX incurs additional costs, making it more expensive. The goal is to minimize costs, so on-demand is a better option.

Create two separate SAM templates, one for dev with caching and one for prod without.

Why wrong: Maintaining two templates is more work and error-prone. The same template can handle both environments with conditions.

Enable caching in the API Gateway console after each deployment for the dev stage.

Why wrong: Manual intervention is inefficient and not part of an automated CI/CD pipeline.

Use a custom CloudFormation resource to toggle caching based on a parameter.

Why wrong: This adds unnecessary complexity. The built-in CacheClusterEnabled property with conditions achieves the goal more simply.

Enable DynamoDB Accelerator (DAX) to cache the large items.

Why wrong: DAX caches items but does not bypass the 400 KB item size limit.

Use DynamoDB Transactions to atomically update the items.

Why wrong: Transactions provide ACID guarantees but do not change the item size limit.

Enable DynamoDB Streams to capture changes to the items.

Why wrong: Streams capture item modifications but do not help with large item storage.

Standard Workflow

Why wrong: Standard Workflows provide exactly-once execution and can handle long-running processes, but they have lower throughput (max thousands per region) and are not cost-effective for high-volume, short-duration tasks.

AWS Lambda function with synchronous invocation

Why wrong: Using Lambda alone would require building complex orchestration logic, retries, and error handling. Step Functions provides built-in state management and parallelism.

Amazon Simple Workflow Service (SWF)

Why wrong: Amazon SWF is a legacy service for orchestrating background jobs. Step Functions is the modern, recommended orchestration service on AWS.

Deploy two separate SAM templates, one for each stage.

Why wrong: Maintaining multiple templates is inefficient and error-prone compared to a single parameterized template.

Use a custom resource to toggle caching after deployment.

Why wrong: A custom resource adds unnecessary complexity and latency; the built-in SAM parameter support is simpler.

Enable caching globally and configure a usage plan with a quota for production.

Why wrong: Usage plans control throttling and quotas, not caching behavior.