Development with AWS Services practice questions

Enable SNS delivery retries for HTTP endpoints

Why it fails: Enabling SNS delivery retries for HTTP endpoints is irrelevant when an SQS queue is subscribed to an SNS topic. SNS delivery retries are specifically designed for HTTP/S or other non-queue endpoints where SNS directly attempts to deliver messages to an external service. When SQS is the subscriber, SNS reliably delivers the message to the SQS queue, and the queue itself, along with its consumers like Lambda, manages the subsequent processing and retry logic, not SNS's endpoint-specific retry mechanism.

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

Why it fails: Setting the SQS queue's visibility timeout to a value greater than the Lambda function's processing time primarily prevents duplicate processing of a message by multiple consumers during a single processing attempt. While a longer timeout allows the Lambda function sufficient time to complete its work and can facilitate retries for transient failures (as the message reappears if not deleted), it does not inherently ensure reliability if a message consistently fails processing due to persistent errors or malformed data, which would still lead to message loss without a DLQ.

Configure the SNS topic to use server-side encryption

Why it fails: Configuring the SNS topic to use server-side encryption (SSE) with AWS KMS protects the confidentiality of messages by encrypting them at rest within the SNS topic and during delivery to encrypted SQS queues. This is a crucial security measure for sensitive data, ensuring that unauthorized parties cannot access message content. However, encryption does not address the operational reliability of message delivery or the ability to recover messages that fail processing, which are distinct concerns from data security.

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 it fails: Configuring an Amazon SQS FIFO queue with a Lambda function using a batch size greater than 1 does not inherently cause message duplication. While Lambda invokes the function with multiple messages, successful processing of all messages in the batch typically results in their automatic deletion by Lambda. Duplication occurs if messages are not successfully processed and deleted, causing them to become visible again after the visibility timeout, regardless of whether they were part of a batch or processed individually.

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

Why it fails: The SQS message retention period determines how long SQS stores a message in the queue before it is permanently deleted by the service. If a message's retention period expires, it is removed from the queue and is not re-queued or made visible again. This setting prevents messages from accumulating indefinitely but does not cause messages to reappear or be duplicated; it leads to permanent data loss if not processed in time.

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

Why it fails: 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.

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

Why it fails: DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache designed to significantly improve read performance for DynamoDB tables, especially for read-heavy workloads. While DAX can drastically reduce response times for frequently accessed data by caching it, it operates on the existing DynamoDB items and does not alter or bypass the fundamental 400 KB maximum item size limit. Therefore, it cannot solve the problem of storing individual items larger than this threshold.

Use DynamoDB Transactions to atomically update the items.

Why it fails: DynamoDB Transactions provide atomicity, consistency, isolation, and durability (ACID) guarantees for operations across multiple items within a single table or even across multiple tables. This feature ensures that a set of operations either all succeed or all fail, maintaining data integrity during complex updates. However, transactions specifically address multi-item operations and do not extend the maximum size limit for any single item involved in those operations, making them irrelevant to the large item storage problem.

Enable DynamoDB Streams to capture changes to the items.

Why it fails: DynamoDB Streams capture a time-ordered sequence of item-level modifications (creations, updates, deletions) in a DynamoDB table, publishing them as stream records. This capability is primarily used for change data capture, enabling real-time analytics, cross-region replication, or triggering other AWS services like Lambda functions based on data changes. DynamoDB Streams are an event-driven mechanism for reacting to data changes and do not provide any means to store items larger than the 400 KB limit within the DynamoDB table itself.

Add a suffix filter to the S3 event notification that includes .jpg and .png.

Why it fails: This is the correct and most efficient solution. S3 event notifications natively support filtering based on object key prefixes and suffixes. By configuring a suffix filter for '.jpg' and '.png', S3 itself will only publish notifications for objects matching these patterns, ensuring the Lambda function is never invoked for other file types, thereby preventing unnecessary invocations and associated costs.

Set the S3 bucket policy to deny PutObject requests that do not have a .jpg or .png suffix.

Why it fails: This option fundamentally alters the S3 bucket's upload behavior, which is not the stated requirement. A bucket policy denying `s3:PutObject` requests for non-image files would prevent users from uploading any files without a .jpg or .png suffix. The goal is to selectively invoke Lambda for images, not to restrict what can be stored in the bucket, implying other file types should still be allowed but simply not trigger the Lambda function.

Create two separate S3 buckets: one for images and one for other files, and configure the event notification only on the image bucket.

Why it fails: Creating separate buckets for images and other files does not filter invocations by file extension within a single bucket; it merely shifts the filtering to bucket-level routing, which still requires the developer to manage two buckets and does not solve the original requirement of filtering by object key suffix. This option is tempting because separating file types into dedicated buckets is a common pattern for organising storage and applying bucket-specific policies, and it would be correct if the goal were to isolate processing environments or apply different lifecycle rules per file type, rather than filtering event notifications by file extension.

Amazon ElastiCache with Redis

Why it fails: ElastiCache with Redis is ideal for session state storage. It provides in-memory caching with low latency, supports TTL for automatic expiration, and can be accessed from any Lambda function via a VPC. It is a common pattern for serverless session management.

Amazon S3

Why it fails: Amazon S3 is an object storage service optimized for large, immutable objects and high durability, not for the rapid, frequent read/write operations of small, mutable session data. Its latency characteristics, typically in milliseconds, are too high for interactive user sessions requiring sub-millisecond access. Furthermore, the cost model for S3 involves charges per PUT/GET request, which would quickly become prohibitive for a high-traffic application frequently updating session state.

Local storage (Lambda ephemeral storage /tmp)

Why it fails: The Lambda `/tmp` directory provides ephemeral storage that is isolated to a single function invocation and not shared across concurrent or subsequent invocations. Any data written to `/tmp` is lost once the invocation completes or the execution environment is recycled. This makes it unsuitable for storing persistent session data that needs to be accessible across multiple user requests or different Lambda function executions within a user's session.

Delete the stack and recreate it with the updated visibility timeout.

Why it fails: Deleting an AWS CloudFormation stack that includes an Amazon SQS queue will result in the complete removal of the SQS queue resource. This action is destructive, leading to the irreversible loss of all messages currently stored within that queue. Recreating the stack afterwards would provision a brand new, empty queue, making this approach unsuitable for updating an existing queue without incurring significant data loss and service disruption.

Change the visibility timeout using the UpdateStack API; messages will be unaffected as long as the new timeout is longer than the current one.

Why it fails: Utilizing the UpdateStack API to modify the VisibilityTimeout property of an SQS queue resource is the correct and recommended approach. This operation changes the queue's configuration in place without deleting or recreating the queue, thus preserving all existing messages. Specifically, increasing the visibility timeout ensures that messages currently being processed by consumers remain invisible for a longer duration, preventing them from becoming available to other consumers prematurely and avoiding duplicate processing.

Stop the queue, update the visibility timeout, then resume the queue.

Why it fails: Amazon SQS queues are designed as highly available, continuously operating services and do not expose "stop" or "resume" functionalities. There is no API or mechanism to pause message delivery or processing for an SQS queue. Attempting to implement such a concept would involve either deleting the queue (losing messages) or preventing producers from sending messages and consumers from receiving them, which would effectively halt the application and cause significant message backlog or loss.

AWS WAF

Why it fails: AWS WAF functions as a web application firewall, primarily designed to protect web applications and APIs from common web exploits and bot attacks, such as SQL injection, cross-site scripting (XSS), and DDoS attacks. While it can filter requests based on patterns, IP addresses, or geographic locations, it does not perform schema-based structural validation of API request payloads. Its role is security against known threats, not enforcing API contract adherence.

Amazon Cognito

Why it fails: Amazon Cognito is a comprehensive service for user authentication, authorization, and management, providing User Pools for sign-up/sign-in and Identity Pools for granting AWS resource access. Its core function revolves around managing user identities and controlling access permissions to API Gateway endpoints or other AWS services. Cognito does not, however, inspect or validate the structural integrity or content of the API request body against a defined schema; it focuses solely on the identity and permissions of the requesting user.

AWS AppSync

Why it fails: AWS AppSync is a fully managed service for building data-driven applications using GraphQL, providing real-time data synchronization and offline capabilities. While AppSync inherently validates incoming GraphQL requests against its defined GraphQL schema, ensuring type correctness and query structure, it is specifically tailored for GraphQL APIs. It is not designed to perform schema-based validation for traditional RESTful API requests, which is the primary domain of Amazon API Gateway.

Amazon RDS

Why it fails: Amazon RDS is a managed relational database service designed for persistent, structured data requiring transactional integrity and durability. While it can store session data, its disk-based nature and overhead for ACID compliance introduce higher latency compared to in-memory solutions, making it inefficient for frequently accessed, ephemeral session state. Storing transient session data in a persistent relational database is an over-provisioning of resources and an unnecessary cost for data that should expire.

Amazon DynamoDB

Why it fails: Amazon DynamoDB is a fully managed NoSQL database service offering single-digit millisecond performance at any scale for various data models. However, it is fundamentally a persistent database, providing high durability and availability for long-term data storage. Session state is typically ephemeral and does not require the strong persistence guarantees of DynamoDB, leading to unnecessary operational overhead and cost for data that is intended to be short-lived and frequently invalidated.

Amazon S3

Why it fails: Amazon S3 is an object storage service designed for storing large, unstructured data objects with high durability and availability, optimized for cost-effective storage rather than low-latency transactional access. Its typical access patterns involve larger file transfers or less frequent retrievals, resulting in significantly higher latency compared to in-memory or even dedicated database solutions. Therefore, S3 is unsuitable for the high-frequency, low-latency read/write operations characteristic of managing interactive user session state.

Configure an S3 event notification with a prefix filter 'images/'

Why it fails: An S3 event notification configured with a prefix filter like 'images/' will trigger for any object whose key begins with 'images/'. While this helps organize objects within a virtual folder structure, it does not provide granular filtering based on file extension. Consequently, objects such as 'images/document.pdf' or 'images/report.txt' would still invoke the Lambda function, failing to meet the requirement of processing only specific image types.

Create a Lambda resource-based policy that denies invocation from S3 for .pdf objects

Why it fails: A Lambda resource-based policy defines permissions for other AWS services or accounts to invoke the function. While it can specify the S3 bucket as an allowed source, it lacks the capability to inspect the specific object key or file extension within the S3 event payload itself to conditionally deny invocation. The filtering logic for object attributes must reside within the S3 event notification configuration, not the Lambda function's permission policy.

Add an S3 bucket policy that denies PutObject for any object that is not a .jpg or .png

Why it fails: An S3 bucket policy can indeed restrict `s3:PutObject` operations based on object metadata or key patterns, effectively preventing non-image files from being uploaded. However, the question asks to *process* specific image types, implying other file types might still be stored but not trigger the Lambda. Denying upload outright prevents storage, which might not be the desired outcome, and more importantly, a bucket policy does not control which events are *sent* to a Lambda function, only what can be *stored*.

Use DynamoDB Streams to capture expired items and trigger a Lambda function for deletion.

Why it fails: DynamoDB Streams capture all item-level modifications, including creations, updates, and deletions, *after* they happen. They do not possess the capability to *automatically delete* items based on a Time-to-Live (TTL) attribute, which is the core requirement here. Streams are primarily designed for real-time processing of data changes, such as updating a search index or triggering downstream analytics, making them useful for reacting to data events rather than initiating data lifecycle management.

Use DynamoDB Global Tables to replicate data to another region and then set a TTL on the replica.

Why it fails: DynamoDB Global Tables are designed for multi-region active-active replication, providing high availability and disaster recovery across geographical regions. While TTL can be enabled on tables participating in a Global Table setup, the primary purpose of Global Tables is data redundancy and low-latency access, not automatic item deletion. Utilizing Global Tables solely for an item expiration mechanism is a significant over-engineering, introduces unnecessary operational complexity, and incurs substantial additional costs associated with cross-region data transfer and storage, making it unsuitable for this specific requirement.

Use DynamoDB Accelerator (DAX) to cache the data and expire it based on a cache TTL.

Why it fails: DynamoDB Accelerator (DAX) is an in-memory cache service engineered to provide microsecond-level response times for read-heavy workloads on DynamoDB. Although DAX allows configuring a Time-to-Live (TTL) for cached items, this TTL only dictates how long an item remains in the DAX cache before being invalidated or refreshed. It does not affect the underlying DynamoDB table; items would persist indefinitely in the primary database, failing to meet the core requirement for automatic deletion from the persistent data store itself.

On-demand

Why it fails: DynamoDB On-Demand capacity mode charges per request for reads and writes, making it ideal for unpredictable workloads with highly variable traffic patterns. However, for application configuration data that experiences consistent and predictable read patterns, On-Demand becomes significantly more expensive than Provisioned capacity because it lacks the cost benefits of reserving throughput, leading to higher operational costs over time.

Provisioned with auto scaling

Why it fails: Provisioned capacity with auto scaling automatically adjusts read and write capacity units (RCUs/WCUs) based on actual usage, aiming to optimize cost and performance for fluctuating workloads. For application configuration data with consistently predictable traffic, auto scaling introduces unnecessary operational complexity and potential for minor cost overhead from scaling events, as the capacity requirements are already known and stable, making dynamic adjustments redundant.

Provisioned with fixed capacity

Why it fails: Provisioned capacity with a fixed configuration allows you to specify a consistent number of Read Capacity Units (RCUs) and Write Capacity Units (WCUs) that DynamoDB will maintain. For application configuration data with consistent and predictable access patterns, this mode is the most cost-effective because you pay a predictable, lower hourly rate for exactly the throughput capacity you know you need, avoiding the higher per-request costs of On-Demand or the overhead of auto scaling.

Amazon RDS

Why it fails: Amazon RDS is a managed relational database service designed for persistent, structured data storage that requires transactional integrity and durability. While it could technically store session data, its disk-based nature introduces significantly higher latency compared to in-memory solutions, making it inefficient for frequently accessed, ephemeral session state. Furthermore, session data typically does not require the complex transactional guarantees or long-term persistence that RDS provides, making it an overly complex and expensive choice.

Amazon S3

Why it fails: Amazon S3 is an object storage service optimized for storing large, static files and is not designed for the high-frequency, low-latency read/write operations required for dynamic session state. Accessing individual session attributes as distinct objects would incur significant latency and operational costs, making it highly inefficient for a web application's session management. Moreover, S3 lacks built-in mechanisms for automatic expiration or cleanup of ephemeral data, necessitating manual or complex lifecycle management for session data.

Amazon EFS

Why it fails: Incorrect. EFS provides persistent file storage that can be mounted on multiple instances. While it can be used for session state, it is not ephemeral; data persists after instance termination, which is not desired in this scenario.

Reduce the number of stream shards

Why it fails: Reducing the number of stream shards would consolidate the data volume onto fewer shards, thereby increasing the data rate that each remaining shard must handle. This action would directly exacerbate an increasing iteratorAge, as the consumer would struggle even more to process the higher throughput per shard, causing it to fall further behind the stream head instead of catching up.

Disable checkpointing

Why it fails: Disabling checkpointing would prevent the Kinesis consumer from reliably tracking its progress by persisting the last processed sequence number. While it might remove a minor I/O operation, this action fundamentally compromises the consumer's ability to maintain its position in the stream, potentially leading to reprocessing of old records or data loss upon restarts. Consequently, it would not sustainably reduce iteratorAge and could introduce significant data integrity issues, making it an inappropriate solution.

Generate a new random primary key for every retry

Why it fails: Generating a new random primary key for every retry fundamentally undermines the goal of idempotency, which is to ensure a single logical operation has a single effect. Each retry would create a distinct new record in DynamoDB, identified by a unique primary key, rather than ensuring the original operation's effect is applied only once. This approach would lead to an accumulation of multiple, separate records for what should be a single order, failing to prevent the unintended side effects of repeated processing.

Disable API Gateway request validation

Why it fails: Disabling API Gateway request validation is entirely unrelated to achieving idempotency for backend operations and would not address the problem of duplicate writes. Request validation primarily focuses on ensuring that incoming client requests conform to a predefined schema before being forwarded to the Lambda function, preventing malformed data from reaching the application logic. While important for input hygiene and security, it does not address the problem of preventing duplicate processing of *valid* requests that might occur due to client retries or transient network issues.

Put all routing logic in a single Lambda that invokes every target

Why it fails: Centralizing all event routing logic within a single AWS Lambda function completely negates the primary benefits of EventBridge's built-in filtering and routing capabilities. This approach creates a highly coupled, monolithic component that becomes a single point of failure, a performance bottleneck, and significantly complicates maintenance and scaling. EventBridge is specifically designed to decouple producers from consumers, allowing rules to directly invoke targets based on event patterns, thereby eliminating the need for custom, complex routing code.

Hardcode account root credentials in targets

Why it fails: Hardcoding AWS account root credentials in any application component, including EventBridge targets, represents a severe security anti-pattern and is never an acceptable practice. Root credentials possess unrestricted administrative access to the entire AWS account and should never be used for programmatic access or stored anywhere. Instead, EventBridge rules should leverage IAM roles with the principle of least privilege, granting only the specific permissions required for the target action, ensuring secure and auditable access.

EC2: Database

Why it fails: This pairing is wrong because EC2 has no built-in relational engine, query optimizer, or transaction manager; it merely runs an operating system on virtual hardware. Database functionality on EC2 would require you to self-install and manage software like MySQL, whereas AWS classifies that managed capability under RDS, not EC2.

S3: Messaging

Why it fails: This pairing is wrong because S3 has no queuing mechanism, no message visibility timeout, and no consumer polling model; it only stores and serves objects by key. Asynchronous decoupled communication between application components is the defining role of SQS, which S3 can complement via event notifications but cannot replace.

Increase the Lambda function timeout.

Why it fails: Increasing the Lambda function timeout only extends the maximum duration a single invocation can run before being terminated by the Lambda service. It does not affect the number of concurrent invocations that can execute simultaneously. Throttling occurs when the total number of concurrent executions exceeds the account's or function's concurrency limit, regardless of how long each individual function is configured to run.

Increase the DynamoDB read capacity units.

Why it fails: Increasing DynamoDB read capacity units (RCUs) addresses potential performance bottlenecks or throttling on the database side, ensuring the Lambda function can read data efficiently. However, this action does not influence the number of concurrent Lambda function invocations allowed by the AWS Lambda service itself. Lambda throttling is a function-level or account-level concurrency control, entirely separate from backend database provisioning and performance.

Configure reserved concurrency on the Lambda function.

Why it fails: Configuring reserved concurrency on a Lambda function dedicates a specific portion of your account's total concurrency limit exclusively to that function. This guarantees that the function will always have a minimum number of concurrent executions available, preventing it from being throttled due to other functions consuming the shared account concurrency pool. By reserving concurrency, you protect critical functions from general account-level throttling, ensuring consistent availability.

Use Amazon CloudWatch Events to trigger the Lambda function on a schedule.

Why it fails: Using Amazon CloudWatch Events (now Amazon EventBridge) to trigger a Lambda function on a schedule is inappropriate for processing S3 events as they occur. This approach would only execute the Lambda at predefined intervals, completely missing the real-time, event-driven nature of S3 object creation or modification. It would require the Lambda to then scan S3 for changes since its last run, which is inefficient and not truly reactive to individual S3 events.

Configure S3 event notifications to directly invoke the Lambda function.

Why it fails: Configuring S3 event notifications to directly invoke the Lambda function is the most efficient and lowest-latency solution for processing S3 events. When an S3 event, such as an object creation or deletion, occurs, S3 immediately sends a notification payload directly to the Lambda function. This direct integration eliminates intermediaries, ensuring the Lambda is triggered instantaneously and reactively, which is ideal for real-time data processing pipelines.

Publish S3 events to an SNS topic and subscribe the Lambda function to that topic.

Why it fails: Publishing S3 events to an SNS topic and then subscribing the Lambda function to that topic introduces an additional intermediary step compared to direct invocation. While SNS is excellent for fan-out scenarios where multiple subscribers need the same notification, for a single Lambda function, it adds an extra hop in the event delivery path. This increases overall latency and complexity without providing a significant benefit when direct S3-to-Lambda integration is available and preferred for minimal delay.

Configure the Lambda function to be invoked asynchronously.

Why it fails: Configuring asynchronous invocation means the invoker does not wait for the Lambda function's response, and the function is retried automatically by Lambda's internal queue if it fails or times out. However, this change in invocation model does not inherently reduce the actual execution duration of the Lambda function itself. The function will still attempt to run for its configured timeout period, and if it consistently exceeds that, asynchronous invocation merely defers the problem or retries a failing operation without addressing the root cause of the timeout.

Enable provisioned concurrency on the Lambda function.

Why it fails: Enabling provisioned concurrency pre-initializes a specified number of execution environments, ensuring that invocations land on warm containers and eliminating cold start latency. While this significantly improves response times for latency-sensitive applications by reducing the initial setup overhead, it does not address issues where the function's actual business logic or external calls take too long to complete. Provisioned concurrency prevents cold starts but has no impact on the execution duration of the function's core runtime once it has started.

Increase the Lambda function timeout to 5 minutes.

Why it fails: Increasing the Lambda function's timeout to 5 minutes would simply allow the function more time to execute before being terminated by the Lambda service. While this might prevent immediate timeouts, it does not address the underlying performance issues or external dependency problems causing the function to run long. This approach merely postpones the failure and incurs higher costs without actually solving the root cause of the prolonged execution, which contradicts the implicit goal of optimizing or troubleshooting without simply extending the timeout.

Store secrets in AWS Systems Manager Parameter Store with a secure string parameter encrypted using AWS KMS.

Why it fails: AWS Systems Manager Parameter Store with a secure string parameter encrypted using AWS KMS does not natively support automatic rotation. It would require custom automation to rotate the secret, which does not satisfy the automatic rotation requirement.

Store secrets in an encrypted S3 bucket and retrieve them in the task definition.

Why it fails: Storing secrets in an encrypted S3 bucket is not recommended for secrets management. It lacks built-in rotation and introduces complexity in access control and encryption key management. It does not meet the requirements for automatic rotation and secure secrets management.

Store secrets in AWS Secrets Manager and use a Lambda function to rotate the secrets.

Why it fails: Correct. AWS Secrets Manager supports automatic rotation of secrets by integrating with a Lambda function. The Lambda function can be custom or AWS-managed (e.g., for RDS). Secrets Manager encrypts secrets at rest using AWS KMS and transmits them over TLS, meeting the encryption and rotation requirements.