Free Practice Questions for Amazon Web Services SAA-C03 Exam

The least-privilege design is to create an IAM policy that explicitly lists the full ARNs of only the S3 buckets the application must access, then attach that policy to the ECS task role. The ECS task role provides AWS permissions directly to the application container, which is the correct identity boundary for ECS workloads. Attaching permissions to the instance role is broader because all tasks on the container instance could potentially inherit access through the EC2 host role. A wildcard ARN is not least privilege because it can unintentionally match extra buckets. Tag-based access can be useful in some ABAC designs, but the requirement is a specific group of buckets in one account and Region; explicit ARNs provide clearer least-privilege access.

Aservice control policyis the right control because SCPs apply guardrails at the AWS Organizations level across member accounts. AWS documentation states that SCPs do not grant permissions; instead, they define the maximum permissions available in member accounts. An explicit deny oniam:CreateUserapplied through an SCP prevents new IAM users from being created in those accounts, while existing IAM users can continue to operate within the permissions they already have, subject to the SCP. IAM policies and permissions boundaries are not the best organization-wide control for this requirement because they are not the same centralized account-level guardrail mechanism that SCPs provide. Therefore, the correct answer is to use anSCP denying iam:CreateUser. (AWS Documentation)

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

For SQS-backed worker architectures, AWS recommends scaling consumers based on queue metrics (e.g., ApproximateNumberOfMessagesVisible, AgeOfOldestMessage). EC2 Auto Scaling can “scale out based on Amazon CloudWatch alarms” tied to SQS backlog, increasing worker capacity to reduce latency as demand grows. DAX (A) accelerates DynamoDB reads, not message processing. API Gateway (B) and CloudFront (C) optimize request ingress and content delivery, not the asynchronous email-sending application. The bottleneck is consumer throughput; scaling workers with an SQS-driven policy restores timely processing without downtime and follows Well-Architected patterns for decoupled, elastic systems.

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.

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

Option Auses an IAM role attached to the EC2 instance profile, enabling secure and automated access to Secrets Manager. This is the recommended approach.

Option Buses IAM users, which is less secure and harder to manage.

Option Cis not practical for accessing secrets programmatically.

Option Dviolates best practices by granting direct access to the EC2 instance.

Comprehensive and Detailed 250 to 300 words of Explanation (AWS documentation-based, no links):

The security requirement is preventive: “prevent the deployment” of IAM roles that contain an overly permissive inline policy (Allow on Action:* and Resource:*). Preventive enforcement should occur at deployment time so noncompliant IAM resources are blocked before they exist. In a Control Tower-governed environment where resources are provisioned through CloudFormation, the most appropriate mechanism is a proactive control that evaluates templates and denies noncompliant stack operations.

Option A matches this intent. Control Tower proactive controls are designed to provide preventative guardrails by checking resource configurations (including Infrastructure as Code deployments) against defined rules and blocking deployments that violate policy. This stops risky IAM roles from being created in the first place, which is preferable to after-the-fact detection and cleanup.

Options B, C, and D are detective or reactive patterns. Detective controls (and AWS Config rules) can identify noncompliance after resources are created, but that does not “prevent deployment.” Even if remediation is automated (Option C), there is still a window where an overly permissive role exists and could be assumed or exploited. Option D only notifies, which is insufficient. Option B suggests deleting policies on deployment, but Control Tower detective controls are not intended to automatically delete deployed IAM policies; they primarily detect and report drift/noncompliance.

Therefore, A is the best solution because it enforces the requirement proactively by blocking noncompliant CloudFormation deployments, maintaining a stronger security posture and reducing operational burden associated with detection and remediation.

Use SQS FIFO to durably persist orders, guarantee order processing semantics, and decouple producers/consumers. FIFO queues provide “exactly-once processing” with message deduplication and “preserve message order.” Visibility timeouts and retries ensure messages are “processed eventually” without being lost; failed messages go to a DLQ for later reprocessing. This pattern aligns with Well-Architected reliability guidance to “queue work to protect against overload and failures” and to ensure “durable, idempotent processing” with retry and backoff. ALB/RDS Proxy/read replicas (A, B) improve availability/connection management but do not guarantee durable handoff or exactly-once processing. SNS (D) is pub/sub and does not provide FIFO semantics in this option, nor a DLQ per subscription for exactly-once. Therefore, frontends write orders to an SQS FIFO queue; backend workers in an Auto Scaling group consume, process idempotently, and use a DLQ for poison messages to meet “no lost orders,” “eventual processing,” and “exactly-once” requirements.

Edge-optimized API Gateway endpoints utilize the Amazon CloudFront global network to decrease latency for clients globally. This setup ensures that the request is routed to the closest edge location, significantly reducing response time and improving performance for worldwide users.

AWS Service Catalogallows organizations to centrally manage commonly deployed IT services and offers self-service deployment capabilities to customers. By creatingService Catalog products, the consulting company can package their solutions and tools for easy reuse by customers while maintaining central control over configuration and access. This provides a standardized and automated solution with the least operational overhead for managing and deploying solutions across different customers.

Option A (CloudFormation): CloudFormation templates are useful but don ' t provide the same level of management and user-friendly self-service capabilities as Service Catalog.

Option C (Systems Manager): Systems Manager is more focused on managing infrastructure and doesn ' t offer the same self-service capabilities.

Option D (AWS Config): AWS Config is used for tracking resource configurations, not for deploying solutions.

AWS References:

AWS Service Catalog

An Amazon ECS task running on AWS Fargate and scheduled with EventBridge Scheduler is the correct solution because the job is containerized, long-running, scheduled, and cannot tolerate infrastructure interruptions. Fargate removes the need to manage EC2 instances, operating systems, and cluster capacity, which improves operational efficiency. EventBridge Scheduler can run the task weekly before the work week starts. Lambda is incorrect because Lambda has a maximum execution duration of 15 minutes, while this job requires at least 1 hour. EC2 Spot Instances are wrong because Spot capacity can be interrupted, which violates the stateful and non-interruptible requirement. AWS DataSync is used for data transfer and synchronization, not for running custom analysis jobs.

Given the large size (180 TB) of the database and the time constraint,AWS Snowball Edge Storage Optimizedis the best solution. Snowball Edge allows for the physical transfer of large datasets to AWS efficiently without relying on slow internet connections.AWS DMSandSCTcan be used to perform ongoing replication of any changes made during the migration, ensuring minimal downtime.

Option B (VPN): Using a 100 Mbps internet connection would take far too long to transfer 180 TB.

Option C (Direct Connect): Establishing a 10 Gbps Direct Connect link might not be feasible within the 2-week timeframe.

Option D (DataSync over internet): With the existing internet connection, DataSync would also take too long.

AWS References:

AWS Snowball Edge

AWS DMS

Security groups are stateful, but they cannot explicitly deny traffic — only allow.

Network ACLs are stateless and support explicit deny rules.To prevent Application A from sending traffic to Application B, configure a deny outbound rule in the network ACL of Application A’s subnet to block traffic to Application B’s subnet.

“Unlike security groups, network ACLs support both allow and deny rules, enabling you to explicitly block traffic.”

— Network ACLs

This is the correct method to block outbound traffic between subnets.

AWS Lambda supports functions up to 10 GB of memory and 15 minutes execution time. Each invocation here requires only 1 GB of memory and finishes in 30 seconds, making it an ideal fit for Lambda. Lambda is cost-effective for event-driven, short-duration workloads and requires no infrastructure management. AWS Glue and EMR are better suited for large-scale ETL or distributed processing, which is unnecessary and more costly for this workload.

AWS Documentation Extract:

“AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers. You pay only for the compute time you consume. Lambda supports up to 10 GB memory and 15 minutes per invocation.”

(Source: AWS Lambda documentation)

B, D: AWS Glue is intended for ETL on larger datasets or batch jobs, usually with higher operational overhead and cost.

C: EMR is for large-scale distributed processing and is not cost-effective for single, fast, memory-bound jobs.

The data isfrequently accessed only for the first 30 daysand then israrely accessedbut must be retained for7 years. That pattern matchesAmazon S3 Standardfor the initial active period and thenS3 Glacier Deep Archivefor long-term retention at the lowest storage cost. AWS guidance positions Glacier Deep Archive for long-lived archive data that is accessed once or twice a year and is ideal for compliance-style retention. EFS and EBS are not cost-effective archival storage choices for this use case. S3 Standard-IA is cheaper than S3 Standard, but Glacier Deep Archive is more cost-optimized for multi-year rare access.

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

The best practice to securely provide short-term access to AWS resources, such as Amazon S3, without using long-term credentials, is to use AWS Security Token Service (STS). According to the AWS IAM Best Practices and the Security Pillar of the AWS Well-Architected Framework, temporary credentials should always be used over long-term credentials when possible.

From AWS IAM Documentation:

“Use temporary credentials (IAM roles and AWS STS) instead of long-term access keys. Temporary security credentials are short-term, automatically expire, and are retrieved using AWS STS.”

(Source: IAM Best Practices – IAM User Guide)

Option D outlines the use of a trust relationship and assume-role mechanism via AWS STS. This allows the on-premises application to request temporary, scoped-down credentials to upload files to S3 securely. This approach is:

Secure – Uses short-lived credentials with least privilege

Scalable – No need for EC2 or VPN tunnels

Low Operational Overhead – No infrastructure to maintain

AWS-Recommended – Aligned with security best practices

In contrast:

Option A uses long-term credentials, which is a security risk.

Option B requires additional infrastructure (EC2, VPN), increasing complexity and cost.

Option C relies on IP-based access, which is insecure and not a form of identity-based authentication.

This solution meets the requirement of encrypting each customer’s data separately with the least operational overhead by leveraging AWS Key Management Service (KMS).

Separate AWS KMS Keys: By creating separate KMS keys for each customer, you can ensure that each customer’s data is encrypted with a unique key. This approach satisfies the compliance requirement for separate encryption and provides fine-grained control over access to the keys.

Granular Access Control: AWS KMS allows you to define key policies and use IAM policies to grant specific permissions to the keys. This ensures that only authorized users or services can access the keys, thereby maintaining the principle of least privilege.

Logging and Monitoring: AWS KMS integrates with AWS CloudTrail, which logs all key usage and management activities. This provides an audit trail that is essential for meeting compliance requirements.

Why Not Other Options?:

Option A (Store keys in S3): Storing keys in S3 is not recommended because it does not provide the same level of security, access control, or integration with AWS services as KMS does.

Option B (Hardware security appliance): Deploying a hardware security appliance adds significant operational overhead and complexity, which is unnecessary given that KMS already provides a secure and centralized key management solution.

Option C (Single KMS key for all data): Using a single KMS key does not meet the requirement of encrypting each customer ' s data separately.

AWS References:

AWS Key Management Service (KMS)- Overview of KMS, its features, and best practices for key management.

Using AWS KMS for Multi-Tenant Applications- Guidance on how to design applications using KMS for multi-tenancy.

Amazon DocumentDB global clusters support managed cross-region failover, allowing you to promote a secondary region to become the new primary with minimal downtime. This ensures business continuity during maintenance or regional disruptions.

Reference Extract:

" Amazon DocumentDB global clusters support managed cross-Region failover, allowing you to recover quickly from regional disruptions with minimal downtime. "

Source: AWS Certified Solutions Architect – Official Study Guide, DocumentDB and Resiliency section.

Amazon RDS Proxy helps manage thousands of concurrent database connections by pooling and reusing them efficiently. It is especially useful for serverless applications like AWS Lambda that can open numerous connections quickly, potentially overwhelming the database. Using RDS Proxy reduces connection management overhead and improves fault tolerance.

Automated backupsare the correct answer because Amazon RDS uses daily automated backups together with transaction logs to support point-in-time recovery. AWS documentation states that RDS can retain automated backups for up to 35 days and uploads transaction logs every 5 minutes, which supports restoring to a specific point in time with a maximum of about 5 minutes of data loss. Read replicas are mainly for scaling reads, not for fine-grained restore after accidental edits. Manual snapshots are point-in-time copies, but they do not provide continuous point-in-time recovery. Multi-AZ improves availability, not historical recovery from user mistakes. Therefore, automated backups are the right feature for this data-loss recovery requirement. (AWS Documentation)

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