Visit here for our full Amazon AWS Certified Solutions Architect – Associate SAA-C03 exam dumps and practice test questions.
Question 16:
A company plans to run a large-scale analytics platform on AWS that processes streaming data from thousands of IoT devices. They require a solution that can ingest high-throughput streams, scale automatically, store data durably for real-time and near real-time processing, and integrate with downstream consumers such as Lambda, S3, and Redshift. Which service should the solutions architect recommend?
A) Amazon Kinesis Data Streams
B) Amazon SNS
C) Amazon SQS Standard Queue
D) Amazon MQ
Answer:
A)
Explanation:
The architecture required for this scenario must handle massive ingestion, durable data storage, automatic scaling, and support for multiple types of downstream consumers. Amazon Kinesis Data Streams meets every requirement. When analyzing this question from the perspective of an AWS Certified Solutions Architect Associate SAA-C03 exam candidate, it is important to break down the needs of high-throughput, real-time streaming architectures and understand the differences among the messaging and streaming tools AWS provides.
Kinesis Data Streams is designed for large-scale real-time data ingestion. It supports millions of events per second, and its architecture is built around shards that allow horizontal scaling. When IoT devices continuously generate readings, telemetry, logs, sensor outputs, or metrics, the platform needs to support both bursty and constant high-throughput patterns. Kinesis Data Streams scales elastically by increasing the number of shards, allowing ingestion to scale proportionally with throughput requirements. Additionally, Kinesis ensures durability by replicating data across three Availability Zones in a Region, ensuring fault tolerance and high availability.
Another important feature for SAA-C03 candidates is integration. Kinesis integrates natively with AWS Lambda, Amazon S3, Amazon Redshift, Amazon OpenSearch Service, Kinesis Data Analytics, Kinesis Firehose, and custom consumer applications through the Kinesis Client Library. This aligns with the requirement that the data must be available for real-time and near-real-time processing. For example, Lambda can process each incoming record as it arrives, while Firehose can batch and deliver data into S3 or Redshift. These integrations make Kinesis an end-to-end streaming data platform.
In contrast, option B, Amazon SNS, is a pub/sub notification service designed for messages that require fan-out distribution to subscribers. It does not persist data for real-time analytics, does not support replaying messages, and cannot handle high-throughput IoT-scale data ingestion. SNS delivers messages but does not store them durably for extended processing.
Option C, Amazon SQS Standard Queue, is a distributed message queuing service. While SQS is scalable and highly reliable, it is meant for decoupling microservices and job queues rather than for continuous analytics pipelines. SQS does not allow multiple consumers to independently process the same message stream. Messages are deleted once consumed, and SQS provides at-least-once delivery with potential duplicates. This behavior is unsuitable for analytic systems requiring ordered event processing or multi-consumer delivery.
Option D, Amazon MQ, is a managed broker service that supports protocols like AMQP, MQTT, and STOMP. It is typically used for migrating from on-premises message brokers such as ActiveMQ and RabbitMQ, but it is not optimized for large-scale IoT streaming or analytics pipelines. Amazon MQ brokers cannot scale to millions of events per second and lack native integration with analytics services like Kinesis Data Analytics or Firehose.
Kinesis Data Streams is specifically optimized for real-time streaming workloads. Its ability to retain data for long periods—up to seven days or more with extended retention—allows multiple consumers to read data independently at their own pace. This solves a common challenge in analytics architectures and is a core topic in SAA-C03 around decoupled, scalable design patterns.
The question also highlights multi-service integration, including Lambda, S3, and Redshift. Kinesis interacts seamlessly with all of these. IoT-generated data can be processed in micro-batches or event-by-event using Lambda, stored in S3 for long-term data lake use, or loaded into Redshift for analytics. These patterns are commonly tested in exam questions involving real-time pipelines.
Additionally, Kinesis supports enhanced fan-out, enabling multiple consumers to read from the same stream simultaneously without interfering. This addresses scenarios where real-time processing and near-real-time analytics occur simultaneously.
For durability, Kinesis replicates data across Availability Zones. This ensures the ingestion pipeline remains operational even if an Availability Zone experiences outages. SNS and SQS provide durability in their domains, but they do not replicate across AZs in a way that optimizes real-time data ingestion and analytics compatibility.
Therefore, Kinesis Data Streams is the correct answer because it meets every requirement: high-throughput ingestion, scalability, multi-AZ durability, retention for replay, and deep integration with analytics services.
Question 17:
A company wants to migrate its monolithic application to AWS and break it into microservices. They want asynchronous communication between microservices, message persistence, automatic scaling, and the ability for each message to be processed at least once without loss. Which AWS service best fits this requirement?
A) Amazon SQS Standard Queue
B) Amazon SNS Topic
C) Amazon EventBridge
D) AWS Step Functions Standard Workflow
Answer:
A)
Explanation:
Asynchronous communication, message durability, reliable at-least-once delivery, and the ability for microservices to operate independently are fundamental principles in distributed application design and are deeply emphasized in the AWS Certified Solutions Architect Associate SAA-C03 exam. When companies migrate from monolithic architectures to microservices, one of the first challenges is designing a messaging layer that supports decoupling. Microservices should not be directly dependent on each other’s availability. Instead, messages should be passed through a reliable intermediary that ensures they are delivered even when consumers are temporarily offline. Amazon SQS Standard Queue fits this requirement perfectly.
When evaluating SQS Standard Queue, it is important to understand its behavior. SQS is a fully managed distributed message queuing service designed for decoupling application components at scale. A key requirement in the question is asynchronous communication. With SQS, producers send messages to a queue, and consumers poll the queue when they are ready to handle messages. This means microservices never need to wait for each other or call each other synchronously. The queue acts as a shock absorber, smoothing out traffic spikes. When one microservice experiences a heavy load, it can temporarily slow down without losing messages because SQS stores them durably.
Another requirement in the question is message persistence. SQS stores messages redundantly across multiple Availability Zones in a Region. This ensures that messages are never lost due to failures in a single component or Availability Zone. Durability is critical for microservice architectures where messages represent business transactions, orders, or system signals. Losing such messages could disrupt the entire workflow.
The question also states that messages must be processed at least once. SQS Standard Queue guarantees at least once delivery. This means a message may occasionally be delivered more than once, but it will never be lost. Consumer microservices must therefore be idempotent, meaning they can handle duplicate messages gracefully. This is a commonly tested concept in the SAA-C03 exam because it ensures system reliability even under distributed failures.
SQS also offers automatic scaling. This means the queue can store nearly unlimited numbers of messages without manual provisioning. When traffic spikes occur, SQS can hold millions of messages until consumers catch up. This characteristic makes it ideal for microservices that experience unpredictable loads. Consumers can scale out automatically using EC2 Auto Scaling or serverless services such as AWS Lambda, triggered by SQS events.
Option B, Amazon SNS, is intended for pub/sub messaging rather than queueing. SNS pushes messages to subscribers instantly, but it does not persist messages for future processing. If a subscriber is offline, the message is lost unless SNS is used with an SQS subscription. SNS alone does not solve the durability and decoupling requirements of microservices.
Option C, Amazon EventBridge, is an event bus system designed for event-driven architectures. While EventBridge can route events between services, it does not provide message persistence or queue-based storage for long periods. EventBridge is excellent for event routing, but does not replace SQS for asynchronous job processing. It also does not guarantee the same level of at-least-once delivery behavior for microservices that require durable queues.
Option D, AWS Step Functions, provides orchestration of workflows, not message queuing. Step Functions are designed for coordinating microservice tasks in sequence or parallel. It is not intended for high-throughput asynchronous communication. Step Functions have execution limits and state machine costs that make them unsuitable as an ingestion-based queueing solution. They also do not provide message persistence in the same sense as SQS.
SQS Standard Queue supports visibility timeouts, message retention configuration, dead-letter queues, and decoupled scaling. These characteristics are essential for microservices that need reliable communication. The visibility timeout prevents another consumer from processing the same message simultaneously. Dead-letter queues help isolate messages that repeatedly fail processing. Message retention can be tuned for application needs. This flexibility is exactly why SQS Standard Queue is the best fit.
Therefore, SQS Standard Queue meets all the company’s requirements: asynchronous processing, message durability, resilience to consumer failures, automatic scaling, and at-least-once message delivery. These are core exam concepts and align with AWS best-practice microservice design patterns.
Question 18:
A security team requires that all data stored in Amazon S3 be encrypted using keys fully controlled and managed by the company. They also require audit logging, key rotation policies, granular permissions, and the ability to disable or delete keys to prevent future decryption. Which encryption approach satisfies these requirements?
A) SSE-KMS with customer-managed CMKs
B) SSE-S3
C) SSE-KMS with AWS-managed keys
D) Client-side encryption with S3-managed keys
Answer:
A)
Explanation:
Encryption in Amazon S3 is a major security topic in the SAA-C03 exam. The question states that the company requires encryption keys that are fully controlled and managed by the organization. This means the company must be able to define and enforce policies on who can use the key, monitor key usage, rotate keys, disable them, or delete them entirely. These requirements directly point toward using AWS Key Management Service with customer-managed keys, also known as CMKs.
When Amazon S3 uses SSE-KMS, it encrypts objects with keys stored in AWS KMS. If the company chooses customer-managed keys, they have complete administrative control of the key. This includes creating the key policy, enabling key rotation, monitoring all usage through CloudTrail, disabling the key, or deleting it. This level of control is required by the question’s conditions.
A major reason SSE-KMS with customer-managed CMKs is preferred is auditing. Every request that uses a CMK generates a record in CloudTrail. Compliance teams can analyze which user or service accessed the key, when, and for what purpose. This traceability is essential for organizations with strong regulatory requirements, such as finance, healthcare, or global security standards.
The requirement also mentions key rotation. Customer-managed keys can be configured for automatic yearly rotation or manually rotated whenever needed. AWS-managed keys, by comparison, rotate automatically but do not allow user-controlled rotation schedules.
Granular permissions are another critical factor. With customer-managed CMKs, the company can create fine-grained key policies and IAM policies that control exactly who can encrypt, decrypt, or manage the key. Different departments may require different levels of access. For example, one team may need to upload encrypted files, another may need access to decrypt them, and a security administrator might require permissions to modify key policies. Customer-managed keys enable this level of control.
The ability to disable or delete keys is important for data protection. If a company needs to ensure certain data can never be decrypted in the future, disabling the CMK immediately blocks any attempted decrypt operations. Deleting the CMK makes all data encrypted with it permanently unrecoverable. This fulfills the company’s requirement of preventing future decryption.
Option B, SSE-S3, uses keys fully managed by Amazon and offers no customer control over key management. The company cannot rotate, disable, or inspect key usage with SSE-S3. This breaks multiple requirements.
Option C, SSE-KMS with AWS-managed keys, provides KMS encryption but still lacks customer-level control. AWS-managed keys rotate automatically but cannot be disabled or managed with granular permissions by the customer. Key policies cannot be customized. This option fails the requirement for strict control.
Option D, client-side encryption with S3-managed keys, is contradictory because client-side encryption means the customer encrypts data before sending it to S3. S3 never sees the plaintext or keys. Meanw, hile S3-managed keys only apply to server-side encryption. This inconsistency shows that option D cannot meet the requirement.
Therefore, SSE-KMS with customer-managed CMKs is the only solution that fulfills all security, compliance, and operational requirements stated in the question. This approach aligns strongly with security best practices tested in SAA-C03.
Question 19:
A company runs a multi-tier application in a VPC and wants to ensure that the database layer is not publicly accessible. The database should only be reachable by the application servers. What is the BEST design?
A) Place application servers in public subnets and the database in private subnets with security groups limiting access
B) Place both application and database servers in public subnets
C) Place the database in private subnets but allow 0.0.0.0/0 inbound rules
D) Place all tiers in a single public subnet
Answer:
A)
Explanation:
Network design is one of the most important domains in the SAA-C03 exam, particularly the use of public and private subnets and the correct use of security groups. The question describes a multi-tier application that requires the database layer to be private. The best practice in AWS architecture is to place the application servers in public subnets and the database in private subnets. Public subnets contain resources that require internet access or direct communication from users, such as load balancers or application servers. Private subnets contain resources that should not be exposed to the internet, such as databases or internal services.
Placing the database in a private subnet ensures it has no route to the internet. The only access route is via other components in the VPC. Security groups then provide another layer of protection by restricting which application servers can connect. For example, the database security group might allow inbound traffic only on port 3306 (for MySQL) from the application server security group. This ensures only the application layer communicates with the database.
Option B, placing both tiers in public subnets, violates the principle of least privilege. Databases in public subnets have a direct route to the internet via the internet gateway. Even if the security group is configured securely, this design is risky and not recommended.
Option C, placing the database in private subnets but allowing 0.0.0.0/0 inbound rules, is insecure. Allowing open access defeats the purpose of a private subnet. Even if the subnet is private, an overly permissive security group exposes the database to all VPC resources.
Option D, placing all tiers in a single public subnet, is the worst option because it breaks segmentation entirely. A multi-tier architecture must separate layers to isolate risks.
Option A meets all AWS architectural best practices, providing least privilege, segmentation, and proper security group scoping. This approach is exactly what the SAA-C03 exam expects candidates to recognize.
Question 20:
A company needs a storage service that can host millions of large media files accessed globally. They require low latency, very high durability, versioning support, lifecycle policies, analytics integration, and the ability to serve as the origin for a CDN. Which AWS service is the best choice?
A) Amazon S3
B) Amazon EFS
C) Amazon EBS
D) AWS Storage Gateway
Answer:
A)
Explanation:
Amazon S3 is the ideal choice for hosting millions of large media files. S3 provides virtually unlimited storage, high durability of eleven nines, global accessibility, and seamless integration with Amazon CloudFront for a global CDN. Media workloads often involve storing video, audio, images, and large binary objects. S3 supports multipart uploads for huge files, lifecycle policies to transition objects to Glacier or Intelligent-Tiering, and versioning to track changes.
S3 also integrates with analytics tools such as Athena, Glue, and Redshift Spectrum, enabling large-scale querying without copying the data. This is extremely valuable for companies that need insights into content usage or run metadata analytics.
Option B, Amazon EFS, is a network file system designed for Linux workloads and shared POSIX-compliant file access. It is not optimized for global media distribution or low-cost long-term storage.
Option C, Amazon EBS, is block storage for EC2 instances and cannot scale for millions of media files. It is not shared or globally accessible.
Option D, Storage Gateway, is for hybrid environments and does not replace scalable object storage.
Therefore, S3 remains the only service that meets every requirement: unlimited scalability, durability, CDN integration, lifecycle policies, analytics support, and global low-latency access.
Question 21:
A company is designing a scalable data ingestion pipeline where multiple application servers send log files every second. The architects want to ensure the system can automatically scale to handle sudden spikes of hundreds of thousands of events per second, while also allowing real-time processing and long-term storage. Which service combination provides the best fit for this requirement?
A) Amazon Kinesis Data Streams with AWS Lambda for processing
B) Amazon SQS Standard Queue with EC2 Auto Scaling group
C) Amazon SNS with Amazon S3 for log uploads
D) Amazon DynamoDB Streams with Amazon Athena
Answer:
A) Amazon Kinesis Data Streams with AWS Lambda for processing
Explanation:
When building a highly scalable log ingestion architecture specifically designed for high throughput, near real-time streaming, durability of incoming data records, and event-driven downstream processing, Amazon Kinesis Data Streams becomes one of the most suitable and flexible analytics-focused services available within AWS. The scenario clearly mentions that the organization expects multiple systems to continuously generate logs each second, and these logs may surge to hundreds of thousands of events during peak periods. This requirement for rapid elasticity, seamless burst handling, real-time availability, and automatic horizontal scaling aligns perfectly with the capabilities of Kinesis Data Streams.
Kinesis Data Streams can ingest data from thousands of producers simultaneously, and its sharded architecture means that throughput can be adjusted by increasing or decreasing shard counts. Each shard offers a defined read and write capacity, and the system can scale nearly linearly when additional shards are added. This characteristic supports the requirement of handling unpredictable spikes, because the company does not need to manage servers or manually tune compute resources. Instead, the streaming service absorbs the load and ensures that all records are durably captured for processing.
The second half of the requirement stresses real-time processing. AWS Lambda integrates natively with Kinesis Data Streams and can process batches of data with sub-second latency. Because Lambda is serverless and automatically scales, it allows the company to build a lightweight, cost-efficient pipeline without managing any infrastructure. Whenever the stream receives large amounts of data, Lambda increases parallelization to process multiple batches across multiple shards. This creates a true event-driven architecture that is simple to maintain, highly responsive, and inherently elastic.
Long-term storage is also a typical extension of streaming systems, and Lambda can easily route data into Amazon S3, Amazon OpenSearch Service, DynamoDB, or other services for archival, indexing, or query execution. The design becomes end-to-end serverless, ensuring minimal operational burden and maximum resilience without requiring patching or EC2-based ingestion servers.
The other options fall short compared to the characteristics required:
Option B, using Amazon SQS with an EC2 Auto Scaling group, is not ideal for real-time analytics or continuous log streaming. SQS is best suited for message decoupling, but it does not offer the same streaming semantics, ordering guarantees, or consumer-shard-based parallelism. Additionally, EC2 Auto Scaling adds operational overhead, including AMI management, instance warm-up time, patching, and scaling management, all of which contradict the stated need for an automatically scaling, highly resilient, serverless pattern.
Option C, using SNS with S3, is also unsuitable because SNS does not store messages for long and cannot support hundreds of thousands of logs per second in a guaranteed delivery pattern for real-time processing. SNS is a pub-sub service, not a streaming ingestion platform, and lacks the capabilities needed for continuous log ingestion workloads.
Option D, using DynamoDB Streams, is completely wrong for this use case because DynamoDB Streams is triggered only by table item changes and is not designed for collecting large-scale log files. It also does not support high-volume, real-time ingestion from multiple distributed application servers.
In the context of the AWS Certified Solutions Architect Associate exam, one key takeaway is understanding how to differentiate streaming ingestion services from message queues and eventing technologies. The exam often tests the candidate’s ability to identify when Kinesis Data Streams is necessary versus when SQS, SNS, or EventBridge would be sufficient. In this case, the real-time requirement and extremely high throughput volume directly point toward Kinesis Data Streams.
Question 22:
A company runs a microservices architecture using Amazon ECS with Fargate. They want to store shared configuration values and credentials securely while allowing each microservice to retrieve only the parameters it is authorized to access. Which service best fulfills this requirement?
A) AWS Secrets Manager
B) Amazon RDS Parameter Groups
C) Amazon EC2 Instance Metadata
D) Amazon EFS
Answer:
A) AWS Secrets Manager
Explanation:
For microservices running inside Amazon ECS Fa, where sensitive configuration values such as credentials, API keys, and connection strings must be centrally stored, versioned, encrypted, and tightly controlled through role-based access, AWS Secrets Manager is the most appropriate and secure choice. Secrets Manager is specifically designed for secure storage, automated rotation, granular IAM permissions, encryption, and auditing, all of which match the scenario’s requirements.
One of the biggest advantages of Secrets Manager is its native integration with AWS Identity and Access Management. Each ECS task can assume a task execution role or task role that precisely defines which secrets the microservice is authorized to access. With this granular control, microservices cannot view or modify secrets belonging to other services, which enforces strict least-privilege security boundaries. Additionally, Secrets Manager uses AWS Key Management Service for encryption, ensuring that secrets remain protected both at rest and in transit.
Because Fargate is a serverless container platform, it cannot rely on instance-level metadata or file-based credential storage, which is why an external managed secrets store is crucial. Secrets Manager offers automatic rotation for database credentials, KMS keys, and other sensitive values, reducing operational overhead and minimizing credential attack surfaces. ECS tasks can retrieve secrets programmatically using the AWS SDK without needing to bake credentials into container images or environment variables.
Option B, Amazon RDS Parameter Groups, is used to configure database engine settings—not to store cross-service secrets. It cannot enforce granular microservice-level access, nor is it intended for API keys or credentials.
Option C, EC2 Instance Metadata, is not available on Fargate because there is no underlying instance exposed to the user. Additionally, metadata is never meant for storing sensitive application secrets.
Option D, Amazon EFS, is a shared file system, not a secure secrets store. It cannot provide encryption, versioning, rotation, or fine-grained IAM restrictions on individual secrets.
Therefore, the best secure, scalable, microservice-aligned solution is AWS Secrets Manager.
Question 23:
A company wants to migrate its on-premises MySQL database to AWS with minimal downtime. The database receives constant writes, and the company wants to switch over to the cloud version as soon as both databases remain synchronized. Which AWS service is most appropriate?
A) AWS Database Migration Service
B) AWS DataSync
C) AWS Snowball Edge
D) AWS Glue
Answer:
A) AWS Database Migration Service
Explanation:
When migrating a production relational database that remains active and continues receiving continuous write operations, the challenge is ensuring that the migration achieves near-zero downtime while maintaining synchronous replication between the on-premises database and AWS. AWS Database Migration Service is specifically engineered for this use case, offering both full-load migration capabilities as well as ongoing change data capture, which allows the cloud target database to remain updated with all new inserts, updates, and deletes. This is important since the organization cannot afford to stop writes while performing migration; instead, they need an approach that transfers initial data and keeps changes synchronized until the final switchover.
DMS works with numerous database engines, including MySQL, PostgreSQL, Oracle, SQL Server, and MariaDB, and the exam frequently tests scenarios where a company must migrate databases without application downtime, making it crucial to understand DMS functionality. In this scenario, the company originally uses an on-premises MySQL database and wants to migrate to Amazon RDS for MySQL or Amazon Aurora MySQL. DMS can perform this seamlessly by first conducting a bulk load of all existing tables, indexes, and rows. Following this bulk load, it automatically enters ongoing replication mode by streaming changes from the source system using MySQL binary logs.
The critical factor is minimizing downtime. With DMS’s continuous replication feature, the source database continues to serve live traffic without interruption, and the target database is updated almost in real time. Once the replication latency is sufficiently low and both databases are nearly identical, the company performs a controlled cutover by pointing applications to the AWS-hosted database. This method keeps the downtime limited to a quick connection string update rather than an extended migration window.
Option B, AWS DataSync, is not designed for live database replication. It focuses on transferring files between on-premises locations and AWS Storage services such as S3, EFS, and FSx. Since DataSync deals with file-based transfers, it cannot capture or replicate database-level incremental changes.
Option C, AWS Snowball Edge, is a physical migration device used to transfer extremely large datasets when network bandwidth is limited. While Snowball Edge can transfer database backups or MySQL dump files, it cannot support ongoing replication or syncing. Additionally, it cannot capture real-time writes, which makes it unsuitable for minimal-downtime migrations.
Option D, AWS Glue, is an extract-transform-load (ETL) service. Glue is excellent for analytical workloads and transforming data for data lakes, but is nit ot engineered for transactional database migration or continuous replication. It is not suitable for production database synchronization or minimal-downtime cutover scenarios.
Therefore, the most accurate and exam-relevant answer is AWS Database Migration Service.
Question 24:
A company uses Amazon S3 to store large volumes of media files. Users download these files globally, and the company wants to reduce latency while also preventing unauthorized access through public distribution. They also want to ensure files can only be accessed through a secure distribution layer. Which AWS service combination best meets this requirement?
A) Amazon CloudFront with Origin Access Control
B) Amazon RDS Proxy with IAM authentication
C) AWS Global Accelerator with EC2 instances
D) Amazon SNS with encryption
Answer:
A) Amazon CloudFront with Origin Access Control
Explanation:
When distributing S3-based media files across the globe while enforcing secure access control, Amazon CloudFront is the most effective choice because it is specifically designed to accelerate content delivery through a global network of edge locations. CloudFront drastically reduces latency by caching content close to users. However, in this scenario, the company also wants to prevent users from bypassing CloudFront and accessing objects directly from S3. This requires a mechanism that restricts S3 access to CloudFront only.
Origin Access Control is the modern method for allowing CloudFront to securely access S3 objects. It ensures that requests to S3 are authenticated and only allowed if they originate from CloudFront. This mechanism is crucial for preventing unauthorized downloads by blocking all direct S3 URL access and ensuring that users must go through the distribution layer. With OAC, the S3 bucket policy explicitly denies requests unless they come from the CloudFront distribution. This enforces privacy, security, and ensures correct usage of CloudFront caching capabilities.
Option B, Amazon RDS Proxy, is irrelevant because database proxies have no connection to static content distribution or S3 integration. They address connection pooling for databases, not content delivery.
Option C, AWS Global Accelerator, provides network acceleration for TCP/UDP workloads and improves routing performance for applications hosted on EC2, Load Balancers, or other compute endpoints. However, it is not a caching service and does not integrate with S3 for media file delivery.
Option D, Amazon SNS, is a messaging service and is not related to secure content delivery or caching. Even with encryption, SNS cannot distribute media content, nor can it restrict direct S3 access.
Therefore, CloudFront with Origin Access Control is the correct and exam-validated choice.
Question 25:
A company is deploying a new multi-tier application using Amazon EC2, Amazon RDS, and an Application Load Balancer. They want to restrict the database so it is only accessible from the application servers, and ensure the architecture follows AWS security best practices by minimizing exposure. Which configuration best satisfies this requirement?
A) Place the EC2 instances in private subnets and the database in private subnets with security groups allowing only EC2 access
B) Place the database in a public subnet with inbound rules open to the internet
C) Put the EC2 instances and the database in the same public subnet for easier routing
D) Place the EC2 instances in public subnets and allow database access through a public endpoint
Answer:
A) Place the EC2 instances in private subnets and the database in private subnets with security groups allowing only EC2 access
Explanation:
In a secure multi-tier architecture, the primary goal isto iis to isolate layers to ensure that only necessary components communicate with each other. AWS strongly recommends that both the application layer and the database layer be placed in private subnets. This reduces exposure to the public internet and adheres to the principle of least privilege.
EC2 instances running the application should be in private subnets with an Application Load Balancer in a public subnet. The ALB receives traffic from external clients and forwards it to the private EC2 instances. The Amazon RDS database should also be placed in private subnets and configured with a security group that only allows inbound database traffic from the EC2 security group. This ensures that the database is never directly exposed.
Option B directly violates best practices by placing the RDS instance in a public subnet, which is rarely recommended. Even if inbound rules are restrictive, simply exposing a database to a public IP introduces unnecessary risk.
Option C — placing everything in a public subnet — is not secure and increases the risk of attacks. Multi-tier applications should always segment public-facing and internal layers.
Option D places EC2 in public subnets and exposes the database endpoint publicly. This configuration is insecure and contradicts well-architected design patterns.
Therefore, Option A is the correct architecture for the exam.
Question 26:
A company runs an e-commerce application on Amazon EC2 behind an Application Load Balancer. The application stores session data in memory on the EC2 instances. Users complain about losing sessions when the instances scale in or out. What is the BEST solution to handle session persistence across multiple EC2 instances?
A) Use Amazon ElastiCache for Redis to store session data
B) Store session data locally on each EC2 instance
C) Store session data in Amazon S3
D) Enable sticky sessions on the Application Load Balancer
Answer:
A) Use Amazon ElastiCache for Redis to store session data
Explanation:
In a horizontally scaled application running on EC2 instances behind an Application Load Balancer (ALB), storing session data in-memory on individual instances causes session loss whenever instances are terminated or replaced during scaling events. To solve this problem, the recommended approach is to use a centralized, in-memory datastore that can persist session information across multiple instances. Amazon ElastiCache for Redis provides a managed, high-performance, in-memory caching solution with strong support for session storage.
Redis supports fast key-value storage, TTL (time-to-live) settings for session expiration, and clustering for horizontal scaling. When EC2 instances store session data in Redis, any instance can access a user’s session regardless of which instance originally handled the request. This ensures a consistent user experience even when instances scale out or in.
Option B, storing session data locally on EC2, is insecure and non-scalable. Instance termination or replacement causes all session data to be lost. This does not address the problem and is explicitly discouraged in exam scenarios.
Option C, storing session data in Amazon S3, introduces high latency. While S3 is durable and scalable, it is optimized for object storage, not high-speed session retrieval. Reading and writing session data in S3 for every user request would negatively impact performance.
Option D, enabling sticky sessions on ALB, routes the same client to the same instance. This can temporarily resolve session loss, but does not scale well for large environments. Sticky sessions cannot prevent session loss if the instance fails or is terminated. Additionally, this creates a single point of failure and does not adhere to the AWS best practice of stateless application tiers.
Therefore, Amazon ElastiCache for Redis provides a reliable, low-latency, centralized solution for session management in scalable architectures, aligning with SAA-C03 exam guidance.
Question 27:
A company is building a serverless application that processes uploaded images, generates thumbnails, and stores them for later retrieval. The solution must scale automatically, provide event-driven execution, and minimize operational overhead. Which AWS services should be used?
A) Amazon S3, AWS Lambda, and Amazon DynamoDB
B) Amazon EC2, Amazon SQS, and Amazon EBS
C) Amazon RDS, AWS Batch, and Amazon S3
D) Amazon S3, Amazon EMR, and Amazon Redshift
Answer:
A) Amazon S3, AWS Lambda, and Amazon DynamoDB
Explanation:
Serverless architectures are designed to scale automatically, reduce operational overhead, and trigger processing in response to events. For an image processing pipeline, Amazon S3 acts as a durable storage layer. When images are uploaded to S3, S3 event notifications can invoke AWS Lambda functions automatically. Lambda provides a serverless compute environment that executes code without requiring server provisioning or management. This event-driven execution ensures that thumbnails are generated immediately upon upload.
Amazon DynamoDB can store metadata about each processed image, such as file paths, thumbnail locations, processing status, and timestamps. This approach ensures that the application remains stateless while maintaining efficient metadata retrieval for downstream applications.
Option B uses EC2 and EBS, which introduces operational overhead because instances must be managed, patched, and scaled manually. While SQS could queue tasks, the architecture is not fully serverless and contradicts the requirement to minimize operational effort.
Option C uses RDS and AWS Batch, which are overkill for lightweight image processing. AWS Batch is designed for batch-oriented high-performance compute tasks and is not necessary for individual image event processing.
Option D, combining EMR and Redshift, is intended for large-scale analytics workloads and not real-time serverless image processing. The latency and cost would be significantly higher.
Therefore, the combination of Amazon S3, AWS Lambda, and Amazon DynamoDB satisfies all requirements for scalability, event-driven execution, and low operational overhead.
Question 28:
A company wants to restrict access to specific Amazon S3 buckets so that only certain IAM roles and EC2 instances can read and write objects. They also require encryption in transit and at rest. Which combination of configurations should a solutions architect recommend?
A) S3 bucket policies, IAM roles, and SSE-KMS
B) S3 ACLs only, with SSE-S3
C) Security groups attached to S3, with client-side encryption
D) Public bucket with HTTPS enforced
Answer:
A) S3 bucket policies, IAM roles, and SSE-KMS
Explanation:
When securing S3 buckets, AWS recommends combining IAM roles, bucket policies, and server-side encryption with AWS KMS (SSE-KMS). IAM roles allow EC2 instances or other services to assume permissions temporarily without embedding credentials. S3 bucket policies restrict access to specific roles or services. SSE-KMS ensures encryption at rest using managed keys, which provides control over key rotation and auditing through CloudTrail. Enforcing HTTPS ensures encryption in transit.
Option B, using ACLs only, is insufficient because ACLs cannot provide fine-grained, role-based access. SSE-S3 encrypts objects but does not allow the same control over keys.
Option C: Security groups do not apply to S3, as it is a service-level permission system, and client-side encryption adds complexity without fully solving access control.
Option D, public bucket with HTTPS, exposes the bucket and contradicts the principle of least privilege.
Thus, the correct design is S3 bucket policies + IAM roles + SSE-KMS.
Question 29:
A company wants to deploy a fault-tolerant web application that can withstand an Availability Zone failure. They also want to scale automatically based on traffic. Which AWS architecture best satisfies these requirements?
A) Auto Scaling group of EC2 instances across multiple Availability Zones behind an Application Load Balancer
B) Single EC2 instance with a public IP and manual scaling
C) EC2 instances in one AZ with a Network Load Balancer
D) Amazon Lightsail instance with snapshot-based scaling
Answer:
A) Auto Scaling group of EC2 instances across multiple Availability Zones behind an Application Load Balancer
Explanation:
High availability requires distributing resources across multiple Availability Zones (AZs). Auto Scaling ensures capacity adjusts based on demand. The Application Load Balancer distributes traffic across healthy instances in multiple AZs. Option A meets both requirements.
Option B is a single point of failure with no scalability. Option C lacks multi-AZ redundancy. Option D does not provide automatic scaling suitable for unpredictable traffic.
AWS best practices emphasize multi-AZ deployments and automatic scaling for fault tolerance and elasticity, making Option A the correct solution.
Question 30:
A company wants to process large amounts of semi-structured log data for analytics. They want a fully managed, serverless solution that can query data in place without requiring ETL pipelines. Which service should they use?
A) Amazon Athena
B) Amazon EMR
C) Amazon Redshift
D) AWS Glue
Answer:
A) Amazon Athena
Explanation:
Amazon Athena allows serverless querying of data stored in S3 using standard SQL. It works directly with semi-structured formats such as JSON, Parquet, and CSV, eliminating the need for complex ETL pipelines. Athena automatically scales to handle queries, and customers pay only per query processed. This is ideal for ad hoc analytics on log data.
Option B, EMR, requires cluster management and is not fully serverless. Option C, Redshift, requires loading data and provisioning clusters. Option D, Glue, is for ETL and transformation but does not provide interactive querying.
Therefore, Athena is the correct choice for fully managed, serverless analytics of S3-based log data.