Cloud Technology and Services practice questions

Amazon S3 Standard

Why wrong: S3 Standard is designed for frequently accessed data and lacks any automatic mechanism to transition objects to lower-cost tiers. Even if product images become rarely accessed after the initial upload, they continue to incur the full Standard storage cost indefinitely, so you would need to manually implement lifecycle policies to move them elsewhere, which is exactly what Intelligent-Tiering does automatically.

Amazon S3 One Zone-Infrequent Access

Why wrong: Incorrect. S3 One Zone-IA is suitable for infrequently accessed data but lacks automatic tiering. Objects must be explicitly moved using lifecycle policies. Additionally, it stores data in a single Availability Zone, which may not meet durability requirements for product images.

Amazon S3 Glacier Deep Archive

Why wrong: Incorrect. S3 Glacier Deep Archive is the lowest-cost storage class for long-term archival data with retrieval times of 12 hours or more. It is not designed for data that may be accessed frequently or for automatic tiering based on changing access patterns.

Amazon CloudFront

Why wrong: Amazon CloudFront is a content delivery network (CDN) that caches static and dynamic web content at edge locations. It can accelerate delivery of web pages and media files, but it cannot be used as an in-memory data cache for database query results that are generated by the backend application. CloudFront does not integrate directly with RDS and requires the application to set Cache-Control headers; it does not provide a transparent caching layer for database reads.

Amazon DynamoDB Accelerator (DAX)

Why wrong: Amazon DynamoDB Accelerator (DAX) is an in-memory cache specifically designed for Amazon DynamoDB. It cannot be used to cache data from an Amazon RDS database. DAX only works with tables in DynamoDB and does not support caching relational database queries.

Amazon Simple Queue Service (SQS)

Why wrong: Amazon SQS is a fully managed message queuing service used to decouple and buffer requests between application components. It does not provide in-memory caching capabilities and will not reduce the read load on a database. Using SQS would change the architecture to asynchronous processing, not improve read performance.

Amazon S3 Standard

Why wrong: Amazon S3 Standard is engineered for frequently accessed 'hot' data, offering millisecond retrieval and high durability, but its storage cost per GB is noticeably higher than S3 Standard-IA. The sensor data is rarely accessed, and the requirement is simply to be retrievable within 24 hours—there is no need for the premium performance of S3 Standard. Choosing this class would inflate storage costs unnecessarily, whereas S3 Standard-IA provides the same low-latency access at a reduced storage price, making it the cost-efficient option.

Amazon S3 Standard-Infrequent Access (S3 Standard-IA)

Why wrong: S3 Standard-IA is ideal for data that is accessed less frequently but requires rapid access when needed. It provides the same low-latency retrieval as S3 Standard at a lower storage cost, perfectly matching the requirement of retrievability within 24 hours while minimizing cost.

Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA)

Why wrong: S3 One Zone-IA stores data in a single Availability Zone, meaning data becomes unavailable or is lost if that AZ experiences an outage. This lack of multi-AZ resilience makes it unsuitable for critical compliance data that "must be retrievable" within 24 hours, as the risk of data loss or prolonged inaccessibility is higher than with multi-AZ options. It is tempting because it offers the lowest storage cost for infrequently accessed data, making it ideal for secondary backups or easily recreatable data where the cost saving outweighs the risk of an Availability Zone event.

Use an Amazon SQS queue between the ALB and the EC2 instances to decouple the request flow and buffer excess requests.

Why wrong: Amazon SQS is a fully managed message queuing service that can decouple application components. By placing an SQS queue between the ALB and the EC2 instances, incoming requests are stored as messages. The instances process messages at their own pace, buffering the excess during spikes. This ensures no requests are lost even when the spike exceeds the Auto Scaling group's maximum capacity.

Enable Amazon EC2 Auto Scaling with predictive scaling to forecast and pre-provision capacity for the spikes.

Why wrong: Predictive scaling uses historical data to forecast future traffic and proactively adjust capacity. However, the spikes in this scenario are described as unpredictable, making accurate forecasting unreliable. Moreover, predictive scaling cannot provision capacity beyond the Auto Scaling group's maximum limit (2,000 instances), so it would still be insufficient during extreme spikes.

Register additional EC2 instances in an on-premises data center as targets for the ALB and use manual failover.

Why wrong: This hybrid approach requires maintaining on-premises infrastructure and manual failover processes, which contradicts the requirement for no manual intervention. Additionally, integrating on-premises instances with an ALB typically involves a VPN or Direct Connect, adding complexity and latency. It does not provide the automatic buffering needed for unpredictable spikes.

AWS DataSync

Why wrong: DataSync is a managed online transfer service that uses software agents to automate data movement from on-premises to S3 over the internet or Direct Connect. Its throughput is still bounded by your WAN connection — on a 100 Mbps link, an 80 TB dataset would take roughly 74 days even if the agents push data as fast as possible. It cannot bypass bandwidth limits because it never leaves the network; it simply adds scheduling, validation, and retry logic.

AWS Direct Connect

Why wrong: Direct Connect gives you a private, dedicated fiber connection to AWS, offering more predictable performance than the public internet and eliminating issues like ISP throttling. But a 1 Gbps Direct Connect link still provides only 125 MB/s of theoretical throughput, meaning 80 TB would take more than seven days to upload, assuming full utilization. For a one-time large migration, the cost of provisioning and maintaining that connection for the duration makes it less practical than shipping a physical device.

Amazon S3 Transfer Acceleration

Why wrong: S3 Transfer Acceleration routes your uploads through AWS's globally distributed CloudFront edge locations, which can reduce latency and packet loss over long distances. However, it does nothing to increase the actual bandwidth available to your office; your 100 Mbps connection still caps throughput at roughly 12.5 MB/s. Moving 80 TB over that link would take over 70 days, so acceleration only helps when the problem is network distance, not raw capacity.

Amazon SNS

Why wrong: Amazon SNS is a publish/subscribe notification service that broadcasts messages to subscribed endpoints such as HTTP, email, or Lambda functions, rather than storing them for downstream retrieval. It lacks the durable, persistent queue semantics of SQS—if a subscriber is unavailable at publication time, the message is typically lost unless a retry policy or dead-letter queue is configured. Hence, SNS is the wrong choice for a system that needs reliable message queuing with at-least-once delivery.

Amazon Kinesis Data Streams

Why wrong: Amazon Kinesis Data Streams is built for real-time processing of streaming data, such as clickstreams or telemetry, ingesting records into ordered shards that are consumed by applications via a fixed retention window (default 24 hours, up to 365 days). It is not a general-purpose message queue because it assumes multiple consumers read each shard in order with exclusive iteration, and it lacks SQS-style visibility timeouts and per-message deletion. Thus, while it can temporarily store data, it is architecturally optimized for streaming analytics, not durable point-to-point messaging.

AWS Step Functions

Why wrong: AWS Step Functions is a workflow orchestration service that coordinates discrete tasks—such as Lambda invocations, API calls, or human approvals—into a state machine execution, with each execution tracking step-specific input and output. It does not expose a queue API for producers to enqueue and consumers to dequeue independent messages; instead, it processes a single execution's workflow and holds state, not messages awaiting retrieval. Therefore, Step Functions cannot substitute for a message queue in a decoupled architecture.

AWS AppRunner

Why wrong: AWS AppRunner is a managed container service that deploys containerized web applications and APIs. It handles scaling, load balancing, and TLS certificates, but it offers no built-in authentication, storage, or API backend categories. It is a hosting/runtime platform, not a full-stack application development framework with integrated frontend libraries and backend logic.

AWS Amplify

Why wrong: AWS Amplify is a full-stack development platform specifically designed for building web and mobile applications. It provides frontend libraries, UI components, and a CLI that provisions backend categories such as Auth (Amazon Cognito), Storage (Amazon S3), API (AppSync/GraphQL), Analytics, and Functions. Amplify integrates these services into a single workflow, enabling developers to rapidly build feature-complete applications without manually configuring each AWS service.

AWS Elastic Beanstalk

Why wrong: AWS Elastic Beanstalk is a Platform-as-a-Service for deploying and scaling web applications, but it does not provide pre-built backend categories for authentication, storage, or APIs. With Elastic Beanstalk, you must build your own application logic and integrate services like Cognito or S3 manually. It focuses on infrastructure management and application deployment rather than offering a cohesive full-stack development framework for mobile and web clients.

Amazon Pinpoint

Why wrong: Amazon Pinpoint is a marketing communication service for sending targeted emails, SMS, and push notifications. It is not a CRM platform.

Amazon QuickSight

Why wrong: Amazon QuickSight is a business analytics service for visualizing data. It does not function as a CRM.

AWS AppFlow

Why wrong: AWS AppFlow is a data integration service for transferring data between SaaS applications and AWS services. It is not a CRM.

Step 1: Create volume from snapshot, Step 2: Stop instance, Step 3: Detach old volume, Step 4: Attach new volume, Step 5: Start instance

Why wrong: Attaching the new volume before detaching the old one will cause a device-name conflict. On a stopped EC2 instance, the root device (e.g., /dev/xvda or /dev/sda1) is still reserved by the existing volume, so AWS will reject the attachment of a second volume to the same device name. Even if you attached the new volume to a different device name, it would not replace the root volume—the instance would still boot from the old, corrupted volume when started. You must first detach the old volume to free the root device name, then attach the new volume to that same device slot.

Step 1: Detach old volume, Step 2: Stop instance, Step 3: Create volume from snapshot, Step 4: Attach new volume, Step 5: Start instance

Why wrong: Detaching the old root volume before creating the replacement volume from the snapshot is risky and unnecessary. Once the old volume is detached, the stopped instance has no root volume at all, and if the snapshot restore fails—due to a corrupted snapshot, an AWS outage, or an API error—you are left with a non-bootable instance and may have lost your original boot volume. By creating the new volume from the snapshot first, you validate that the snapshot is restorable and have the replacement ready to attach immediately, minimizing downtime and preserving the original volume as a fallback until the swap is ready to be completed.

Step 1: Create volume from snapshot, Step 2: Attach new volume, Step 3: Detach old volume, Step 4: Stop instance, Step 5: Start instance

Why wrong: This is incorrect because starting the instance before detaching and attaching volumes will boot with the old (corrupted) volume, and you cannot detach the root volume while the instance is running without stopping it first.

S3 Standard

Why wrong: S3 Standard is designed for frequently accessed data and provides low latency and high throughput. It is not cost-effective for data that is rarely accessed over a decade, as the storage costs are much higher than archival classes.

S3 Intelligent-Tiering

Why wrong: S3 Intelligent-Tiering automatically moves objects between access tiers based on usage patterns. While it can optimize costs for unknown or changing access patterns, it includes a monitoring and automation fee that makes it less economical for data that is known to be rarely accessed for long periods.

S3 One Zone-IA

Why wrong: S3 One Zone-IA stores data in a single Availability Zone and is designed for infrequently accessed data. It has lower storage costs than Standard, but it does not provide the high durability (99.999999999%) needed for critical compliance records, and the retrieval costs are higher than Glacier Deep Archive for rare access.

AWS Direct Connect

Why wrong: AWS Direct Connect provides a dedicated, private network connection from an on-premises data center or office to AWS for hybrid workloads requiring consistent bandwidth and lower network cost. It does not cache content, operate edge locations for end-user delivery, or accelerate web requests from arbitrary internet users; its benefit is between your network and AWS, not between AWS and website visitors. For a static S3 website the bottleneck is global viewer latency, which Direct Connect cannot address.

Amazon Route 53

Why wrong: Amazon Route 53 is a managed DNS and domain registrar service that translates names like example.com into IP addresses and can route users using latency, geoproximity, or weighted policies. It only returns the best answer, such as a CloudFront distribution domain name; it never holds or caches the website's files, so it does not reduce the transfer time for static objects. DNS caching does lower resolution time, but it has no effect on how quickly S3 content reaches the browser.

AWS Global Accelerator

Why wrong: AWS Global Accelerator uses static anycast IP addresses and AWS edge locations to route TCP/UDP traffic over optimized paths on the AWS backbone, improving jitter and latency for dynamic applications like gaming or UDP streaming. It does not store or cache objects, and S3 is not a supported endpoint for Global Accelerator, so it cannot offload repeated downloads of static assets. Since a static S3 website mainly benefits from edge caching, Global Accelerator is the wrong layer for this scenario.

Amazon ElastiCache

Why wrong: Amazon ElastiCache is an in-memory caching engine compatible with Redis or Memcached, used to accelerate data access by storing frequent reads in memory. It does not provide durable message storage or a queue-based handoff between the front-end and backend workers. Cache entries can expire or be evicted, so it cannot guarantee delivery of a request for asynchronous processing, making it unsuitable for decoupling microservices.

Amazon Route 53

Why wrong: Amazon Route 53 is a highly available DNS and domain management service that resolves human-readable names to AWS resources or external endpoints. Its traffic flow, latency-based routing, and health checks are designed for routing user traffic, not for moving application messages between components. It has no message persistence or consumer-polling model, so it cannot act as a buffer or queue for backend processing.

Amazon CloudWatch

Why wrong: Amazon CloudWatch collects and tracks metrics, logs, and events to give operational visibility into AWS resources and applications. It can trigger alarms or invoke actions based on thresholds, but it does not hold application payloads for eventual consumption. Since there is no durable queue to store requests while workers process them, CloudWatch cannot decouple a front-end from backend microservices.

Amazon EC2 Auto Scaling group

Why wrong: Amazon EC2 Auto Scaling is not a compute service itself but a capacity management layer that adjusts the number of EC2 instances in a group. It requires underlying instances that are billed continuously (per-second or per-hour) even when idle, and it cannot directly execute code in response to S3 object-created events without additional components like SNS or SQS and custom scripts. Its scaling triggers are typically based on metrics (e.g., CPU, memory) or scheduled times, not on per-event invocation, so it provides no pay-per-execution model and would leave servers running between events.

Amazon ECS with Fargate

Why wrong: Amazon ECS with Fargate runs containers without managing servers, but it is not designed for event-driven invocation in the same way as Lambda. Typically, an intermediary service (like Lambda) would be needed to trigger a container task, and you pay for running containers even while waiting for work.

Amazon Elastic Beanstalk

Why wrong: Elastic Beanstalk is a PaaS service that automates deployment and scaling of applications, but it requires running environments (EC2 instances) that incur costs even when idle. It is not an event-driven compute service and does not provide pay-per-execution billing.

AWS Elastic Load Balancing

Why wrong: Elastic Load Balancing distributes incoming traffic across multiple targets, such as EC2 instances, but it does not automatically launch new instances to replace failed ones. It can perform health checks and route traffic away from unhealthy instances, but replacement is not its function.

AWS Lambda

Why wrong: AWS Lambda is a serverless compute service that executes code in response to events such as S3 object uploads, API Gateway requests, or SNS messages, abstracting away all underlying servers. It has no built-in capability to monitor EC2 instance health, maintain a desired instance count, or launch replacement instances, because it never manages EC2 infrastructure at all. Therefore, Lambda cannot replace failed EC2 instances and is fundamentally unrelated to the lifecycle management and automatic replenishment provided by Amazon EC2 Auto Scaling.

AWS Auto Scaling

Why wrong: AWS Auto Scaling is a service that helps you scale multiple AWS resources, including EC2 instances, DynamoDB tables, and Aurora replicas, using scaling plans. However, the specific service that directly manages EC2 instance replacement and desired capacity is Amazon EC2 Auto Scaling. AWS Auto Scaling provides a unified interface for scaling across resources, but for the described scenario, Amazon EC2 Auto Scaling is the appropriate service.

Amazon CloudFront

Why wrong: Amazon CloudFront is a content delivery network (CDN) for fast delivery of static and dynamic web content over HTTP/HTTPS. It does not natively support UDP traffic, which is required by this application. CloudFront is best for caching and accelerating web-based content, not real-time UDP-based game traffic.

Amazon Route 53 latency routing

Why wrong: Amazon Route 53 latency routing is a DNS-based routing policy that directs users to the AWS region with the lowest latency based on DNS resolution. While it can help route players to a nearby region, it does not provide edge-based acceleration or improve the performance of traffic routed to a single region. It also does not reduce latency over the last mile or through ISP networks.

AWS Site-to-Site VPN

Why wrong: AWS Site-to-Site VPN is used to create a secure connection between an on-premises network and AWS VPC. It is not designed to accelerate end-user traffic from the internet or to improve performance for global users accessing a cloud application.

Deploy a Read Replica in another Availability Zone and configure the application to use it as a failover target

Why wrong: Read Replicas are designed for scaling read traffic and do not provide automatic failover. Promoting a Read Replica to become a primary instance requires manual intervention, which does not meet the requirement for automatic failover and minimal downtime.

Enable automated backups with point-in-time recovery

Why wrong: Automated backups and point-in-time recovery allow you to restore your database to a specific point in time, but the restore process is not automatic and can take significant time. This does not provide the active high availability or automatic failover required.

Manually provision a standby database instance in another Availability Zone and configure a custom failover script

Why wrong: While this approach could theoretically provide failover, it requires significant manual effort to manage synchronization, monitor health, and trigger failover. Amazon RDS Multi-AZ automates all these steps, including updating the DNS endpoint, so the application connection string remains unchanged. A manual solution does not meet the requirement for minimal downtime and simplicity.

AWS Global Accelerator

Why wrong: Global Accelerator improves the availability and performance of applications by directing traffic to optimal endpoints over the AWS global network, but it does not cache static content. It is used for TCP/UDP traffic, not for caching objects.

Amazon Route 53

Why wrong: Amazon Route 53 is primarily a DNS web service that translates human-readable domain names into IP addresses. While it can route traffic globally using policies like latency-based routing and geolocation, it does not cache or serve web content itself. DNS responses are cached by resolvers, but that is not equivalent to caching HTTP assets, so it cannot reduce the load on EC2 instances for content delivery.

AWS Direct Connect

Why wrong: AWS Direct Connect provides a dedicated, private network connection from an on-premises data center to AWS, bypassing the public internet for consistent and lower-latency connectivity. However, it does not cache content at edge locations or serve static assets to end users globally. It is intended for hybrid cloud workloads and high-bandwidth data transfer, not for offloading web requests or improving the experience of geographically distributed customers.

Amazon ECS with Amazon EC2 launch type

Why wrong: With the Amazon EC2 launch type, ECS orchestrates your containers, but the worker nodes are EC2 instances that you own and operate. Someone on the team must manage AMI updates, OS security patching, the ECS agent, and the cluster's desired capacity, and you manually scale instances using Auto Scaling or an Auto Scaling group. This operational burden directly conflicts with the requirement to avoid managing servers, so it is not the most appropriate fit.

AWS Lambda

Why wrong: AWS Lambda runs code only in response to invocations, on a model built for short, event-driven work—the hard cap is 15 minutes and container images are limited to 10 GB. Microservices that accept long-lived connections or run continuous background jobs would time out, and the stateless, invocation-centric model makes it awkward for a traditional autoscaled HTTP service with persistent pool connections to RDS. It can package container images, but at best it is a functions layer; it is not a general-purpose, long-running container compute platform like Fargate.

Amazon EC2 instances with Docker installed

Why wrong: This is the highest-touch path: you must launch EC2 instances, install and update the Docker engine, patch the OS, restart failed containers, and wire up service discovery, load balancing, and autoscaling yourself. There is no orchestration layer for rolling deployments or health checks unless you build one, and the team is accountable for the entire container host lifecycle. That manual management makes it incompatible with the requirement to minimize server management.

Amazon EC2 with an Auto Scaling group configured to launch instances based on S3 events

Why wrong: Configuring an Auto Scaling group to react to S3 events is neither direct nor efficient. Auto Scaling groups primarily scale based on metrics such as CPU utilization or on a defined schedule, so you would need to route S3 notifications through SNS/SQS and then trigger scaling — and newly launched instances can require minutes to boot and initialize before running the job. For a short, 10-second Python script, this approach introduces significant latency, requires ongoing management of AMIs, patching, and instance state, and bills for the entire time each instance runs, making it far more complex and costly than using AWS Lambda.

AWS Elastic Beanstalk configured with a worker environment

Why wrong: AWS Elastic Beanstalk worker environments provision and run EC2 instances continuously to poll an SQS queue, failing the requirement for a solution that executes *only* when new files are uploaded and does not require provisioning servers. While it offers managed scaling for background tasks, it isn't truly serverless. This option is tempting as it manages infrastructure and scales for asynchronous processing, making it suitable for long-running, message-driven applications requiring a persistent server environment.

Amazon EMR with a scheduled step to process new files

Why wrong: Amazon EMR is designed for big data processing using frameworks like Apache Spark and Hadoop. It is overkill for a simple Python script that runs in 10 seconds and would require manual scheduling or custom logic to trigger based on S3 events, adding unnecessary cost and complexity.

Amazon Simple Workflow Service (Amazon SWF)

Why wrong: Amazon SWF is designed for human-in-the-loop workflows and long-running processes that require explicit coordination of activities by deciders and workers, not for orchestrating stateless AWS Lambda functions in a sequential pipeline. The scenario demands a managed service that automatically handles retry logic and step sequencing without custom decider logic, which SWF would require you to implement yourself. SWF would be correct if the workflow involved manual tasks, external human approvals, or stateful processes lasting days or weeks.

Amazon Simple Queue Service (Amazon SQS)

Why wrong: Amazon SQS is a message queuing service for decoupling components. It does not provide workflow orchestration, retry logic, or state management across multiple steps. It can be part of a workflow but does not coordinate it.

AWS AppSync

Why wrong: AWS AppSync is a managed GraphQL service that enables clients to query and mutate data in real time through subscriptions, caching, and fine-grained authorization. While AppSync resolvers can invoke Lambda functions, it lacks the workflow constructs—states, transitions, retry policies, and compensations—needed to orchestrate a multi-step order processing pipeline. AppSync is designed for API access and data synchronization, not for coordinating the sequence of business logic steps across services.