Development with AWS Services practice questions

Enable SNS delivery retries for HTTP endpoints

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Lambda custom integration

Why wrong: Lambda custom integration, also known as non-proxy integration, requires extensive configuration of request and response mapping templates within API Gateway. Developers must manually define how incoming request data is transformed into the Lambda event object and how the Lambda function's output is transformed back into an HTTP response. This approach introduces significant complexity and maintenance overhead, making it less desirable than proxy integration for most typical RESTful API scenarios.

HTTP integration

Why wrong: HTTP integration is designed to forward API Gateway requests to any publicly accessible HTTP/HTTPS endpoint, such as a web server, an EC2 instance, or another API. It does not directly invoke an AWS Lambda function. While a Lambda function *could* expose an HTTP endpoint, this integration type bypasses the direct Lambda invocation mechanism provided by API Gateway, making it an inefficient and incorrect choice for directly integrating with a Lambda backend for a RESTful API.

Mock integration

Why wrong: Mock integration is specifically designed for testing and development purposes, allowing API Gateway to return a predefined response without invoking any backend endpoint. It's useful for frontend developers to proceed with integration testing even when the backend Lambda function is not yet fully implemented or available. However, it does not connect to a live backend service and is therefore entirely unsuitable for a production-ready RESTful API that needs to execute business logic via a Lambda function.

Amazon RDS

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Standard queue delay seconds

Why wrong: Standard queue delay seconds merely postpones when a message becomes available for consumption, typically used to give producers time to complete related tasks before a message is processed. It offers no inherent mechanism to prevent duplicate messages from being sent to the queue or to ensure that a message is processed only once if a consumer fails and the message reappears, thus failing to meet exactly-once processing requirements.

Dead-letter queue redrive policy

Why wrong: A dead-letter queue (DLQ) redrive policy is designed to capture messages that fail to be processed successfully after a specified number of retries, preventing them from blocking the main queue. While crucial for robust error handling and preventing message loss, it does not prevent duplicate messages from being initially sent to the queue or guarantee that a command is processed exactly once if a consumer successfully processes it but then fails to delete it before the visibility timeout expires.

Visibility timeout extension

Why wrong: Extending the visibility timeout allows a consumer more time to process a message before it becomes visible to other consumers, preventing multiple consumers from processing the same message concurrently. While essential for preventing unintended duplicate processing due to long-running tasks, it does not prevent duplicate messages from being initially sent to the queue by a producer. Furthermore, it doesn't guarantee exactly-once processing if a consumer fails after processing but before deleting the message, as the message would eventually become visible again.

Generate a new random primary key for every retry

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Amazon S3

Why wrong: Amazon S3 is an object storage service designed for highly durable, available, and scalable storage of static files and large objects. It operates with eventual consistency for some operations and does not provide the low-latency, in-memory access patterns required for real-time session state management. Using S3 for session state would introduce significant latency and complexity, making it unsuitable for interactive web applications that demand quick data retrieval.

Amazon ElastiCache

Why wrong: Amazon ElastiCache is a fully managed, in-memory caching service that supports Redis and Memcached engines. It provides extremely low-latency data retrieval and high throughput, which is crucial for quickly accessing and updating user session data without impacting application responsiveness. By externalizing session state to ElastiCache, web servers remain stateless, significantly improving scalability, fault tolerance, and simplifying horizontal scaling for web applications.

Amazon RDS

Why wrong: Amazon RDS is a managed relational database service designed for structured data storage, complex querying, and strong transactional consistency and durability. While it can technically store session data, using a full relational database for this purpose introduces unnecessary overhead, higher latency due to disk-based operations, and increased cost compared to an in-memory cache. Its primary design is not optimized for the high-volume, low-latency key-value access patterns typical of session state management.

Increase the Lambda function timeout.

Why wrong: 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 wrong: 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 wrong: 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.