Free Practice Questions for Amazon Web Services SAA-C03 Exam

Amazon Kinesis Data Streams provides a highly scalable and durable service for ingesting real-time streaming data. By decoupling ingestion and processing, Kinesis can handle large spikes in traffic without service disruption. Lambda functions (or other consumers) can then process the data as it arrives, scaling automatically. This pattern avoids 503 errors due to compute saturation and delivers a resilient, serverless, and highly scalable architecture.

Reference Extract from AWS Documentation / Study Guide:

" Kinesis Data Streams provides a scalable and durable real-time data streaming service. Coupling Kinesis with AWS Lambda enables event-driven processing, elasticity, and decoupling between ingestion and processing layers. "

Source: AWS Certified Solutions Architect – Official Study Guide, Streaming and Serverless section.

To automatically identify sensitive data in Amazon S3 and monitor access patterns for suspicious activities:

Amazon Macie uses machine learning and pattern matching to discover and protect sensitive data in S3. It provides visibility into data security risks and enables automated protection against those risks.

Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect AWS accounts and workloads. It analyzes events from AWS CloudTrail, VPC Flow Logs, and DNS logs.

By enabling both services, the company can automate the discovery of sensitive data and continuously monitor access patterns for potential security threats.

The current architecture tightly couples image upload, resizing, and storage into a single synchronous workflow handled by EC2 instances. This increases upload latency and degrades user experience. The optimal solution is to decouple upload from processing and offload work to managed services.

Option C allows users’ browsers to upload images directly to Amazon S3 using presigned URLs, bypassing the EC2 web servers entirely. This significantly reduces server load, network hops, and request latency while improving scalability and performance. Presigned URLs also maintain security by granting time-limited, scoped access to S3.

Option D complements this by using S3 Event Notifications to invoke an AWS Lambda function whenever a new image is uploaded. The Lambda function performs the image resizing asynchronously and stores the processed image back in S3. This event-driven, serverless pattern eliminates tight coupling between upload and processing and ensures automatic scaling with minimal operational overhead.

Option A is unsuitable because Glacier is for archival storage and not designed for active uploads or processing. Option B still routes uploads through EC2, maintaining the bottleneck. Option E introduces unnecessary delays and inefficiency by resizing images on a schedule instead of reacting to upload events.

Therefore, C and D together provide the most performant, scalable, and operationally efficient image upload and processing architecture using AWS-native, event-driven services.

DynamoDB export to Amazon S3 (via point-in-time exports or table backups) “does not consume read capacity” and has no impact on table performance. Once data is in S3, Amazon Redshift can ingest efficiently with COPY from S3, which is the standard, parallel, high-throughput load path with minimal management. Direct COPY from DynamoDB (B) performs a table scan that can consume provisioned throughput, risking throttling. Building Lambda pipelines (C) adds custom code and scheduling overhead. Athena federated queries (D) are ad hoc analytics, not optimized for bulk, recurring warehouse loads. Therefore, exporting to S3 and loading with Redshift COPY maintains DynamoDB throughput and minimizes operational burden.

To meet the requirements, the key must support automatic rotation, and the company must be able to disable (deactivate) the key and schedule deletion. In AWS KMS, these lifecycle controls are available for customer managed keys. Automatic key rotation is supported for symmetric customer managed KMS keys used for encryption and decryption operations. When automatic rotation is enabled, AWS KMS generates new cryptographic material for the key on a regular schedule while the key ID remains the same, helping organizations meet compliance and security best practices without manual operational work.

Option C is the only choice that explicitly combines a symmetric customer managed key with automatic rotation enabled, which directly satisfies the rotation requirement. As a customer managed key, it can also be disabled (to prevent use) and scheduled for deletion (with a waiting period), meeting the rest of the lifecycle needs.

Option A is incorrect because automatic rotation is not generally available for asymmetric KMS keys in the same way; asymmetric keys are used for specialized use cases such as signing or asymmetric encryption, and rotation behavior differs. Options B and D mention “disabling envelope encryption,” which is not a configurable “option” you turn off in KMS; envelope encryption is a recommended pattern where KMS protects data keys, and services commonly use it under the hood. Those options therefore do not describe a valid configuration that meets the requirement.

Therefore, the correct solution is to create a symmetric customer managed KMS key and enable automatic rotation, while using standard KMS controls to disable and schedule deletion when required.

AWS guidance is to deploy one NAT gateway per Availability Zone for production workloads to improve resiliency and avoid cross-AZ dependency. However, the question explicitly says only production requires high availability. In non-production environments, the company can reduce cost by keeping a single NAT gateway and updating private-subnet route tables to use that remaining gateway. This saves hourly NAT gateway charges while preserving internet egress for private subnets. Reducing Availability Zones would affect more than NAT cost and would also weaken overall environment design. NAT instances add operational overhead compared with a managed NAT gateway. A transit gateway is unrelated to this cost problem. Therefore, keeping one NAT gateway per AZ for production and reducing to one NAT gateway in non-production is the most cost-effective answer.

============

The recommended and simplest method for granting cross-account access to an S3 bucket is to use a bucket policy that grants permission to the other AWS account.

This provides direct, controlled, IAM-based access without duplication of data or use of distribution mechanisms like CloudFront.

Transfer Acceleration and replication are unrelated to permissions.

=====================================================

The least operational overhead approach is to use AWS Directory Service with AWS Managed Microsoft AD and establish a trust relationship with the existing on-premises Microsoft Active Directory. This pattern lets employees continue using their existing corporate credentials while AWS operates the directory infrastructure (patching, monitoring, availability, and domain controller management), reducing the burden compared to building and maintaining custom federation components. With a trust in place, identities and group memberships from the on-premises directory can be used for authentication and authorization workflows in AWS.

To provide role-based access to AWS resources and the AWS Management Console, users should assume IAM roles that grant permissions based on job function. IAM roles with appropriate trust policies enable temporary credentials and least-privilege access without creating long-lived IAM users for every employee. This aligns with AWS best practices of centralized identity management and using roles for access control.

Option B is not a standard direct integration pattern: IAM does not “LDAP bind” directly to on-premises AD for console access. Option C can work (custom identity broker + STS) but increases operational overhead because the company must build, secure, operate, and maintain the broker, including availability, updates, and incident response. Option D is not the typical solution for employee console federation from AD; Amazon Cognito is primarily aimed at customer identity and application sign-in, not as the primary mechanism for workforce console access to AWS accounts.

Therefore, A provides the required federation with the smallest operational footprint while supporting role-based access control.

Amazon SQS FIFO queues support deduplication and ordering. AWS documents thatMessageDeduplicationIdis used with FIFO queues to prevent duplicate delivery within a5-minute deduplication window, which matches this requirement exactly. Standard queues do not provide this deduplication guarantee, and SNS filter policies are not a deduplication mechanism for this use case. Because the company wants the least development effort, using API Gateway to place messages directly on an SQS FIFO queue with a deduplication token is the cleanest approach.

============

The Requester Pays feature in Amazon S3 allows the bucket owner to configure the bucket so that the requester, rather than the bucket owner, pays for data transfer and request costs. This is ideal for sharing large datasets with the public or with other AWS accounts when you want to minimize your own data transfer expenses.

Reference Extract from AWS Documentation / Study Guide:

" Requester Pays buckets allow you to configure the bucket so that the requester instead of the bucket owner pays the cost of the request and the data download from the bucket. "

Source: AWS Certified Solutions Architect – Official Study Guide, S3 Cost Management section.

Aurora Global Database is designed for low-latency cross-Region reads and disaster recovery for relational data.

Amazon S3 Cross-Region Replication (CRR) automatically replicates unstructured data to another Region, ensuring high availability and resilience.

“Aurora Global Database replicates your data with typical latency of less than 1 second to secondary AWS Regions.”

“Amazon S3 Cross-Region Replication automatically replicates every object uploaded to your bucket to a destination bucket in another AWS Region.”

— Aurora Global Database

— S3 Cross-Region Replication

This combination meets the multi-Region, high availability, fault-tolerant requirement for both relational and unstructured data.

Provisioned Concurrency:

AWS Lambda’s provisioned concurrency ensures that a predefined number of execution environments are pre-warmed and ready to handle requests, reducing latency during traffic spikes.

This solution optimizes costs during low-traffic periods when combined with AWS Application Auto Scaling to dynamically adjust the provisioned concurrency based ondemand.

Incorrect Options Analysis:

Option B: Switching to EC2 would increase complexity and cost for a serverless application.

Option C: A fixed concurrency level may result in over-provisioning during low-traffic periods, leading to higher costs.

Option D: Periodically warming functions does not effectively handle sudden spikes in traffic.

AWS DataSync provides managed, incremental, parallelized transfers between EFS file systems across Regions, supporting scheduled or continuously running tasks with automatic change detection, encryption in transit, and integrity verification. You can configure two tasks in opposite directions (bi-directional) to achieve two-way synchronization with high availability using agents in each Region and EFS locations connected via VPC endpoints. Native EFS replication (B) is one-way (read-only target) and not intended for active/active two-way sync. Options A and D rely on custom rsync and cross-Region mounts or SFTP, which introduce operational overhead, latency, and fail to provide resilient, managed synchronization. DataSync minimizes operational burden while delivering fault-tolerant, scalable, cross-Region EFS sync.

Amazon CloudWatch Container Insightsis designed for monitoring containerized environments like EKS. It provides native support for collecting and visualizing metrics and logs in a centralized location through CloudWatch dashboards, offering the most operationally efficient solution.

Option A:Using the CloudWatch agent provides basic metrics but lacks the specific insights required for containerized applications.

Option B:Kinesis Data Streams and Firehose add unnecessary complexity for this use case.

Option C:CloudTrail is for auditing API activity and is not designed for application metrics and log aggregation.

AWS Documentation References:

Amazon CloudWatch Container Insights

Amazon DynamoDB provides single-digit millisecond performance at any scale and is fully managed to handle millions of catalog records. It is ideal for structured catalog data such as product metadata and scales seamlessly during high-traffic events like sales. Amazon S3 is optimized for storing unstructured large objects such as videos and manuals, with virtually unlimited scalability and high durability. Option A (RDS) would not handle massive scale or traffic spikes as efficiently. Option C overloads DynamoDB by forcing it to store large binary data, which is not its purpose. Option D (DocumentDB) is suitable for JSON-like documents but not optimal for storing large media files and would add operational complexity. Therefore, option B represents the best separation of structured and unstructured data storage.

State Machine Testing with Logs:

Changing the log level to ALL enables capturing detailed request and response data. This helps verify HTTP headers, body, and responses.

Incorrect Options Analysis:

Option A and B: The TestState API is not a valid option for Step Functions.

Option C: A data flow simulator does not exist for AWS Step Functions.

EC2 Image Builder is the AWS-managed service specifically designed to automate the creation, patching, hardening, and testing of AMIs.

For this scenario, best practice is to:

Use EC2 Image Builder pipelines to generate new golden AMIs whenever features are deployed or on a schedule.

Include build components such as update-linux to automatically apply OS security patches and updates during image creation.

Deploy the new AMIs through existing Auto Scaling groups, ensuring that every newly launched instance is already patched and compliant.

This approach:

Prevents OS vulnerabilities from being introduced at deployment time.

Scales across dozens of applications because AMI pipelines are reusable and automated.

Minimizes manual effort and reduces drift between instances.

Amazon Inspector (Option A) identifies vulnerabilities but does not itself patch AMIs.

AWS Backup (Option B) is for data protection, not vulnerability management.

Patch Manager (Option C) patches running instances, but the requirement is to ensure vulnerabilities are not introduced with new AMIs; golden image pipelines with EC2 Image Builder are the recommended solution.