Free Amazon Web Services SAA-C03 Practice Exam with Questions & Answers

The best practice for granting AWS resource access to EC2 instances is to use IAM roles, not users or long-lived access keys. You create an IAM role with a policy that grants the minimum permissions required, then attach that role to an instance profile associated with the EC2 instance. The instance then automatically receives temporary credentials for AWS service access.

AWS Documentation Extract:

" Attach an IAM role to your EC2 instances to securely grant permissions to AWS services according to the principle of least privilege. Never embed access keys in EC2 instances. "

(Source: AWS EC2 documentation, IAM Roles for EC2)

A, B: Using IAM users and embedding keys violates security best practices.

C: IAM role credentials are automatically managed and never need to be manually attached as keys.

Amazon RDS for MySQL Reserved Instances provide significant savings over on-demand pricing when you plan to run the database for long periods. This is the most cost-effective option for non-production, long-running managed MySQL workloads.

Reference Extract:

" Reserved Instances provide a significant discount compared to On-Demand pricing and are recommended for steady-state workloads that run for an extended period. "

Source: AWS Certified Solutions Architect – Official Study Guide, RDS Cost Optimization section.

For secure communication between Lambda and an RDS DB instance, AWS documentation recommends placing the Lambda functions inside the same VPC and controlling traffic using security groups.

Lambda should have a dedicated security group with outbound access to the VPC CIDR range, and the DB instance’s security group should explicitly allow inbound connections from the Lambda security group. This follows the " least privilege " principle while avoiding public exposure.

Options A and B expose the DB to unnecessary risk. Option D is insecure because it bypasses security groups.

The Kubernetes Horizontal Pod Autoscaler (HPA) scales pods, not nodes. When the cluster runs out of node capacity, the HPA cannot schedule more pods.

On Amazon EKS, AWS recommends using the Kubernetes Cluster Autoscaler to automatically adjust the number of nodes in the cluster’s underlying Auto Scaling group based on pending pods.

Cluster Autoscaler watches for pods that cannot be scheduled because of insufficient resources and then scales out nodes automatically with minimal administrative overhead. It also scales in nodes when they are underutilized.

Why others are not correct:

A: Just tracking memory usage does not automatically scale nodes or integrate with Kubernetes scheduling.

C: A custom Lambda-based resizer is unnecessary undifferentiated heavy lifting compared to the native Cluster Autoscaler.

D: An Auto Scaling group is already typically used under EKS, but by itself it does not respond to pod scheduling pressure without Cluster Autoscaler.

EC2 Auto Scaling warm pools allow you to pre-initialize instances, reducing the delay in scale-out events. This results in significantly faster response times during demand surges while remaining cost-effective compared to always running at peak capacity.

Amazon S3 and AWS Lambda form a classic serverless decoupling pattern for upload-and-process workflows. AWS documents that Amazon S3 can publishevent notificationswhen objects are created and that these events can invoke aLambda functionfor processing. This design automatically scales for high upload rates, durably stores the original images in S3, and cleanly separates upload from resize processing. Storing processed results in a second S3 bucket is also a common pattern that keeps originals and derivatives separate. The EC2 and EFS options add more operational work and do not provide the same event-driven elasticity.

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

Kinesis Data Streams is the right ingestion service for real-time streaming data, and AWS Lambda is the least-operations compute option for processing and transforming records from the stream. AWS documents that Lambda can process events from stream sources such as Kinesis without infrastructure management. Storing the transformed data in DynamoDB provides durable, scalable storage for later analysis. The EC2 option introduces server management overhead. SQS is useful for queued work, but the question specifically centers on streaming data. SNS with ElastiCache is also not a durable analysis store design. Therefore, Kinesis Data Streams plus Lambda plus DynamoDB is the lowest-overhead architecture among the choices.

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

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.

For a large-scale multi-account AWS environment with many VPCs and centralized Direct Connect, AWS recommends using a Transit Gateway (TGW) architecture combined with a Direct Connect gateway (DXGW). This setup allows scalable, centralized connectivity between on-premises and multiple VPCs across accounts.

Step B: Creating a Direct Connect gateway and Transit Gateway in a central network account and connecting them via a transit VIF enables the on-premises network to access all connected VPCs.

Step D: Sharing the transit gateway with other accounts via AWS Resource Access Manager (RAM) allows the central TGW to attach VPCs in multiple accounts, simplifying multi-account connectivity.

Step F: To route cloud resources’ internet traffic back through the on-premises data center (for centralized egress), provisioning only private subnets and routing outbound internet traffic through NAT or firewall services in the data center is necessary. This requires configuring transit gateway and customer gateway routes appropriately.

Option A is partially correct in the use of Direct Connect gateway but association proposals are not scalable for hundreds of VPCs and accounts compared to transit gateway. Option C (internet gateway) is irrelevant here as traffic egress is required via on-premises data center, not directly to the internet. Option E (VPC peering) is not scalable for hundreds of VPCs.

Amazon EFS offers an Infrequent Access (IA) storage class, which can be managed via EFS lifecycle policies. Frequently accessed files remain in the Standard storage class, while infrequently accessed files are automatically moved to the IA class, significantly reducing storage costs with minimal effort and no application changes.

Reference Extract:

" EFS lifecycle management automatically transitions files that are not accessed for a set period to the EFS Infrequent Access (IA) storage class, reducing storage costs. "

Source: AWS Certified Solutions Architect – Official Study Guide, EFS and Lifecycle Management section.

AWS Outposts brings native AWS services (including Amazon EMR) on-premises, ideal when data residency or latency constraints require local processing.

You benefit from AWS’s managed services while meeting the requirement to keep data processing local.

Amazon EC2 On-Demand Instances: Since the batch jobs cannot be disrupted, On-Demand Instances provide the necessary reliability and availability.

Amazon S3 Standard: Storing data in S3 Standard for the first 30 days ensures quick and frequent access.

S3 Glacier Deep Archive: After 30 days, moving data to S3 Glacier Deep Archive significantly reduces storage costs for data that is rarely accessed.

S3 Lifecycle Configuration: Automating the transition and deletion of objects using lifecycle policies ensures cost optimization and compliance with data retention requirements.

AWS Fargate with Amazon ECS is a serverless, fully managed compute engine for containers. Fargate eliminates the need to provision or manage servers, and is ideal for periodic, long-running batch jobs. You only pay for the resources consumed during job execution, making it cost-effective for jobs that run infrequently. Lambda is not suitable because the maximum execution time is 15 minutes, but the job can take up to 2 hours.

AWS Documentation Extract:

“AWS Fargate lets you run containers without managing servers or clusters. Fargate is ideal for batch jobs, event-driven processing, and scheduled tasks that require hours of compute.”

(Source: AWS Fargate documentation)

A: Reserved Instances are cost-inefficient for infrequent workloads and require server management.

B: Lambda has a hard limit of 15 minutes per execution, insufficient for this job.

D: ECS on EC2 requires you to manage and provision EC2 instances, increasing cost and management overhead.

Amazon S3 Storage Lens with advanced activity metrics is the most operationally efficient answer because AWS documentation explicitly says you can use S3 Storage Lens advanced metrics to identify “cold” buckets, meaning buckets whose objects are no longer accessed or are accessed only rarely. That is exactly the requirement in the question. This avoids building a custom analytics workflow on top of CloudTrail or CloudWatch metrics. The standard S3 console does not provide the same purpose-built fleet-level analysis for cold-bucket identification. Athena and CloudTrail can be used for access analysis, but they require more setup, data handling, and query maintenance. S3 Storage Lens is the native managed feature for this storage-optimization scenario. (AWS Documentation)

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

Amazon S3 Intelligent-Tiering is designed for data with unknown or changing access patterns. It automatically moves data between frequent and infrequent access tiers based on usage. This tier offers immediate access to all objects, regardless of which tier they are stored in, while optimizing storage costs. S3 Intelligent-Tiering also provides the same high durability, availability, and security as other S3 storage classes and supports access from external resources using standard S3 APIs. Lifecycle policies and Glacier classes are more suitable for archival when infrequent access is predictable, but retrieval from Glacier classes is not immediate and incurs extra charges and delays.

Reference Extract from AWS Documentation / Study Guide:

" S3 Intelligent-Tiering is designed to optimize costs by automatically moving data between two access tiers when access patterns change. Data is always available and immediately accessible, making it ideal for unknown or unpredictable access patterns. "

Source: AWS Certified Solutions Architect – Official Study Guide, S3 Storage Classes section.

Explanation (AWS Docs):

You cannot “place” DynamoDB inside a VPC. Instead, you use a VPC endpoint.

A Gateway VPC Endpoint for DynamoDB enables private connectivity between your VPC and DynamoDB without traversing the public internet.

“Use a gateway VPC endpoint to privately connect your VPC to DynamoDB without requiring an internet gateway or NAT.”

— Gateway VPC Endpoints

The requirement is for immediate processing of uploaded videos and prompt notification to users. According to AWS best practices for event-driven architectures, using S3 event notifications to trigger a Lambda function upon an object creation (upload) is the optimal solution for real-time processing. Lambda can process the file as soon as it is uploaded, ensuring low latency. Once processing is complete, Lambda can save the processed file back to S3 and use Amazon SNS to notify the user.

This approach uses managed services with minimal operational overhead, is scalable, and ensures event-driven processing with instant user feedback. AWS Amplify primarily facilitates application development and hosting but does not natively provide direct push notification support for this backend workflow; instead, SNS is designed for such notification scenarios.

Reference Extract from AWS Documentation / Study Guide:

" Amazon S3 can publish events to AWS Lambda when objects are created. AWS Lambda runs code in response to events and can interact with other AWS services. Amazon SNS is a flexible, fully managed pub/sub messaging and mobile notifications service for coordinating the delivery of messages to subscribing endpoints and clients. "

Source: AWS Certified Solutions Architect – Official Study Guide, Event-driven Architectures section; AWS Lambda Developer Guide (S3 triggers); Amazon SNS User Guide.

To run RDS instances only during business hours with the least operational overhead, you can useAmazon EventBridgeto schedule events that invokeAWS Lambda functions. The Lambda functions can be configured to start and stop the RDS instances based on the specified schedule (business hours). EventBridge rules allow you to define recurring events easily, and Lambda functions provide a serverless way to manage RDS instance start and stop operations, reducing administrative overhead.

Option A: While CloudWatch alarms could be used, they are more suited for monitoring, and using Lambda with EventBridge is simpler.

Option B (Trusted Advisor): Trusted Advisor is not ideal for scheduling tasks.

Option C (Systems Manager): Systems Manager could also work, but EventBridge and Lambda offer a more streamlined and lower-overhead solution.

AWS References:

Amazon EventBridge Scheduler

AWS Lambda

BothAmazon KinesisandSQS FIFOqueues ensure the sequential processing of messages. By using the payment ID as the partition key in Kinesis or as the message group in the SQS FIFOqueue, messages are processed in order. Both solutions also allow for long-term retention (up to 10 days) of messages, making them suitable for this payment processing use case.

Option A (DynamoDB): DynamoDB does not guarantee message ordering for real-time processing.

Option C (ElastiCache): ElastiCache is for caching, not suitable for sequential message processing.

Option D (Standard SQS queue): A standard SQS queue does not guarantee ordering of messages.

AWS References:

Amazon Kinesis

Amazon SQS FIFO Queues