AWS Certified Solutions Architect Associate Practice Test (SAA-C03)

Configure an S3 Lifecycle rule that transitions the objects to S3 Standard-Infrequent Access (Standard-IA) 60 days after upload. Standard-IA offers the same millisecond latency and 11-nines durability as S3 Standard at a lower storage cost, with a 30-day minimum-storage duration that the workload already satisfies. Add a second transition to move the objects to S3 Glacier Flexible Retrieval (formerly "S3 Glacier") after they are 365 days old. Glacier Flexible Retrieval provides the lowest-cost archive tier that still allows retrieval in minutes to hours-adequate for the client's occasional access needs. S3 One Zone-IA is not chosen because, although it has the same durability as Standard-IA, it stores data in a single Availability Zone and offers lower availability (99.5%), making it less suitable for a primary copy that must remain available. Leaving the data in S3 Standard or moving it directly to Glacier after 60 days would either cost more or slow access during the high-access period.

Amazon API Gateway is a fully managed service that lets you create, publish, maintain, monitor, and secure APIs at any scale. It integrates with Amazon Cognito user pools, IAM, or Lambda authorizers for authentication and authorization. To meter and control consumption, you attach API keys to usage plans, which provide request quotas and throttling limits; detailed metrics and logs are pushed to Amazon CloudWatch for monitoring.

An Application Load Balancer with Amazon Cognito can authenticate users, but ALB has no built-in per-client throttling or usage-tracking features-you would need AWS WAF or another service for that.

Running the services directly on Amazon EC2 with security groups only restricts network traffic and provides none of the API-level monitoring or rate-limiting capabilities.

Using AWS Lambda alone would still require you to build or add separate authentication, metering, and throttling logic; API Gateway already provides these capabilities out of the box.

In a multi-tier (three-tier) architecture, the presentation, business logic, and data layers run on separate, independent infrastructure. Because the tiers are decoupled, each one can be scaled horizontally or vertically on its own to meet demand. This independence lets architects add web servers when user traffic grows, increase application-tier capacity for compute-intensive processing, or scale database read replicas-all without forcing changes to the other tiers. Designs that keep all tiers on the same instances or couple them with fixed ratios negate these benefits and limit scalability.

Using an auto scaling service for elastic compute is the best fit for the scenario described, where consistent compute power is required with the flexibility to scale up during traffic surges. This service will automatically adjust the number of compute instances to handle the load, providing a balance between performance and cost. A serverless function execution platform, while ideal for certain event-driven patterns, does not provide a persistent baseline environment which web applications typically require. Using a larger fixed compute instance may lead to cost inefficiencies due to over-provisioning during non-peak times. Data processing managed services are not suitable as they are tailored for batch jobs and not interactive platforms with variable traffic.

Opting for the S3 Glacier or S3 Glacier Deep Archive storage class is ideal for rarely accessed data that can tolerate retrieval times of several hours, with Deep Archive being the most cost-effective for data that needs to be stored for a decade or longer. Additionally, utilizing the Hadoop Distributed File System (HDFS) on Amazon EMR for infrequent access is incorrect as EMR is a compute optimized service, not a storage service, and would lead to higher costs due to ongoing compute charges. The use of Storage Gateway for storing directly into S3 would introduce unnecessary costs and complexity for a one-time migration need.

Creating a Customer Managed Key in AWS Key Management Service (KMS) and using IAM policies to restrict access to that key to a specific IAM group containing the senior security personnel provides a secure way to allow only authorized staff to manage the keys. This fits the principle of least privilege by specifically designating which IAM identities have permissions to perform key administrative operations. Using AWS managed keys does not provide the same level of granular control over access permissions. Encrypting the keys with another key would add complexity without solving the access control requirement. Rotating keys independently of access policies ensures keys are refreshed regularly but does not address who can manage key permissions.

The correct answer understands that adjusting the memory size also affects the CPU available to the Lambda function, allowing it to complete execution faster. Thus, for moderate processing requirements, it is not necessary to allocate the highest option, but the Architect should choose a memory size that provides sufficient CPU for efficient execution while avoiding unnecessary costs associated with overprovisioning.

Using a customer-managed AWS KMS key (CMK) satisfies the requirements because the organization controls the key material.

• Rotation: A customer-managed CMK can be rotated on demand or by enabling automatic rotation with a custom period from 90 to 2560 days (default 365 days), giving the company full control over the schedule.
• Disablement: The key owner can call the DisableKey operation to make the CMK unusable almost immediately if a compromise is suspected.

AWS-managed keys (the default aws/s3 key) rotate automatically every year and cannot be disabled or have their schedule changed. SSE-S3 uses keys fully managed by Amazon S3, so the customer cannot supply, rotate, or disable its own keys. Therefore, creating and using a customer-managed CMK for SSE-KMS on the S3 bucket is the only configuration that meets all stated requirements.

Amazon ElastiCache effectively addresses the challenge of reducing database load by caching query results. It supports caching strategies, both for Redis and Memcached, that can store frequently accessed data in-memory, thereby improving application performance by providing low-latency access to the data and reducing the load on the database tier. This aligns with the criteria specified for enhancing performance and scalability for read-heavy operations, making it the best option given the scenario described.

Amazon RDS Read Replicas are not the ideal choice because, while they can reduce the load by serving read requests, they are not a caching layer and do not offer the same low latency as an in-memory cache. Using RDS Multi-AZ would provide high availability but would not address the performance issue related to read-heavy queries as effectively as a caching layer. Amazon S3 is primarily used for object storage and is not suitable for caching database query results.

AWS Direct Connect provides a dedicated, private layer-2 or layer-3 connection that keeps traffic on the AWS global backbone. This bypasses the public Internet and delivers predictable, low-latency performance-ideal for large, daily data transfers. A Site-to-Site VPN is encrypted but still rides the Internet, so latency and jitter remain unpredictable. AWS Global Accelerator optimizes Internet paths for end-user traffic, not for data-center-to-AWS links. AWS DataSync over the Internet encrypts traffic but still uses public routes unless combined with Direct Connect, so it cannot meet the "never traverse the Internet" requirement on its own.

The statement is true. In the us-east-1 region, standard EBS snapshots are billed at $0.05 per GB-month, whereas S3 Standard-Infrequent Access storage is $0.0125 per GB-month. Even though snapshots are incremental, holding the same quantity of backup data in the snapshot standard tier costs four times more than placing that data directly in S3 Standard-IA. Therefore, using the standard tier for EBS snapshots is less cost-effective for storing infrequently accessed backups compared to using S3 Standard-IA.

AWS best practice is to enforce both controls with a bucket policy that (1) denies all requests when the global condition key aws:SecureTransport is false, ensuring that only HTTPS traffic is allowed, and (2) denies PUT operations that do not specify server-side encryption with the designated customer-managed KMS key via the condition keys s3:x-amz-server-side-encryption and s3:x-amz-server-side-encryption-aws-kms-key-id. This configuration encrypts data both in transit and at rest while giving the organization full control and auditability over the CMK.

Attach a resource-based policy (bucket policy) to the S3 bucket that identifies the network administration team's AWS account as the principal and grants only the required permissions. A bucket policy is evaluated in the account that owns the resource and explicitly supports specifying an entire account in the Principal element, which cleanly limits access to that account.

IAM identity-based policies in the security engineers' account cannot by themselves grant principals from another account access to the bucket; a resource-based policy in the bucket owner's account is still required for cross-account access. Although legacy S3 ACLs can grant permissions to another AWS account via that account's canonical user ID, AWS now recommends disabling ACLs and using bucket policies for simpler management and finer-grained control. Restricting access by source IP address does not satisfy the requirement because any principal from any account could still reach the bucket if it originates from the allowed network range.

Amazon S3 Intelligent-Tiering is the best solution for this scenario because it automatically moves the data to the most cost-effective access tier without performance impact or operational overhead. This is ideal for data with unknown or changing access patterns. Amazon S3 Standard is not the most cost-effective for data that is infrequently accessed over time. Amazon EFS is not optimized for object storage and cost-effectiveness like S3 Intelligent-Tiering. Amazon EBS volumes are not suitable for object storage and are best for block storage for use with EC2 instances.

CPU utilization is a useful default metric, but it is not adequate for every workload. Memory-bound applications, for example, may need policies that trigger on memory usage or other custom CloudWatch metrics you publish. AWS Auto Scaling also supports predefined metrics such as NetworkIn/NetworkOut and Application Load Balancer request count, as well as fully custom metrics, so you should choose the metric-or combination of metrics-that best reflects real resource saturation for the application. Options B is therefore correct; the other options incorrectly claim that CPU is always sufficient or that other metrics are unsupported.

AWS Lambda allows the platform to automatically scale the compute capacity by running code in response to events. It is well-suited for unpredictable workloads as it ensures that the startup only pays for the compute time consumed, thereby optimizing costs. Although Amazon EC2 with Auto Scaling can scale to meet demand, it is not as cost-optimized for burstable, sporadic workloads because of the continuous running of instances. ECS and EKS are container management services and, while they offer scaling capabilities, they don't offer the same level of cost optimization and event-driven scaling that AWS Lambda provides for the described use case.

A cross-Region read replica keeps a near-real-time copy of the database in another AWS Region. Because updates are shipped asynchronously-typically within seconds-you can promote the replica to a standalone primary during a regional outage, keeping data loss well under the 5-minute RPO and achieving a short RTO (promotion usually takes minutes).

User-defined snapshot or backup schedules of 6 or 12 hours leave data gaps far larger than 5 minutes. Although Amazon RDS automated backups ship transaction logs every 5 minutes and can meet the RPO, restoring from those backups involves creating and initializing a new DB instance, resulting in a much longer RTO than promoting a ready-to-serve replica. Manual multi-Region replication similarly provides no built-in guarantee of meeting the 5-minute RPO and adds operational overhead.

Amazon S3 Glacier and Amazon S3 Glacier Deep Archive are designed for data archiving and long-term backup at very low costs. Among the available storage classes, S3 Glacier Deep Archive provides the lowest cost option that meets the requirement of retaining data for long periods without frequent access. It is suitable for archiving data that may be retrieved once or twice a year.

The implementation of a resource policy on the storage service belonging to one account to allow access to another account’s users is the most appropriate and secure method for this scenario. Specifically, you can use a bucket policy to define permissions at the resource level, in this case to allow read-only access to the specified object prefixes for the data analytics team. Directly attaching policies to the users in the other account or using network-based access controls would not achieve the desired effect of cross-account access at the bucket level, especially with the granularity required for specific object prefixes.

The correct answer is to transition the reports to S3 Standard-Infrequent Access (S3 Standard-IA) after 30 days and then to S3 Glacier Flexible Retrieval (formerly known as S3 Glacier) after 90 days. S3 Standard-IA is cost-effective for data that is accessed less frequently but requires rapid access when needed. After 90 days, when the reports are rarely accessed, moving them to S3 Glacier Flexible Retrieval will further reduce storage costs. S3 One Zone-Infrequent Access is cheaper than S3 Standard-IA but does not offer the same level of availability and resilience, as it stores data in a single Availability Zone. S3 Intelligent-Tiering could also be used, but in this scenario, the access patterns are predictable, so utilizing lifecycle transitions to Standard-IA and Glacier Flexible Retrieval is more cost-effective.