Free SAA-C03 Practice Questions
(AWS Certified Solutions Architect - Associate)

Explanation: Deploying RDS Read Replicas offloads read traffic from the primary instance, improving transactional write performance and reducing read latency for the application. A separate Read Replica for analytics isolates their queries, preventing them from impacting the main application's performance. Vertically scaling the instance would increase costs and might not fully resolve the read contention from two distinct workloads. Migrating to Aurora would offer performance benefits but is a larger operational undertaking and may not be the most immediate or cost-effective solution for splitting workloads. Client-side caching helps for popular reads but doesn't address the analytical workload or the heavy strain on the primary DB.

Explanation: A Multi-Region active-passive setup with RDS cross-Region Read Replicas (configured for replication) provides a low RPO by continuously replicating data, and a low RTO as the replica can be promoted to primary during a disaster. This approach minimizes administrative effort compared to manual restoration. Hourly S3 backups would likely exceed the 15-minute RPO. Increasing EC2 instances and RDS size enhances resilience within a single region but doesn't protect against a regional outage, failing to meet the RTO. Daily AWS Backup snapshots would exceed the 15-minute RPO.

Explanation: Using SQS and SNS for asynchronous communication immediately introduces loose coupling between components without requiring a complete rewrite of the application's internal logic. This allows for incremental migration and improved fault isolation. Containerizing the monolith on ECS would provide some deployment flexibility but doesn't fundamentally decouple the internal components. Breaking down into Lambda functions is a significant refactoring effort, not a minimal initial step. Re-platforming to larger EC2 instances does not address the tight coupling issue.

Explanation: Storing session state in a shared, external store like Amazon ElastiCache (a caching service) allows EC2 instances to be stateless, enabling seamless horizontal scaling without losing session data and improving fault tolerance. This minimizes administrative overhead compared to managing persistent sessions locally. Sticky sessions would direct users to specific instances, hindering horizontal scaling and increasing the impact of instance failures. Increasing instance size (vertical scaling) provides temporary relief but doesn't fundamentally solve the stateful problem for large-scale, resilient architectures. Database-backed sessions would introduce latency and could become a bottleneck under heavy load.

Explanation: Blue/Green deployment provides zero downtime by running two identical environments (blue and green) and shifting traffic between them. This allows for testing the new version thoroughly before making it live and offers an immediate rollback option by switching traffic back to the old environment, which minimizes operational complexity compared to other advanced deployment patterns. In-place deployments still incur downtime for updates and rollbacks. Deploying during off-peak hours does not eliminate downtime. Canary deployments are more complex to manage for immediate full rollback and are typically used for gradual feature rollout and risk mitigation over time.

Explanation: The fan-out pattern using Amazon SNS (pub/sub) and SQS (message queues) allows a single message to be sent to multiple, independent consumers. This provides excellent loose coupling, fault isolation (consumers process independently), and scalability, aligning with minimum cost by using managed services. Directly triggering Lambda functions for each process might lead to invocation limits or complex error handling for multiple destinations. Creating separate SQS queues and sending to all requires more complex application logic to manage multiple sends. A single SQS queue with filtering workers would re-introduce coupling and scaling bottlenecks.

Explanation: The Circuit Breaker pattern prevents an application from repeatedly trying to access a failing external service, thus preventing cascading failures and allowing the service to recover. It can provide immediate fallback responses when the circuit is 'open.' Increasing timeout settings would merely delay the failure and still allow cascading issues. Using an SQS queue buffers requests but doesn't prevent the calling service from being blocked waiting for a response, nor does it provide an immediate fallback. Deploying the microservice in Multi-AZ increases its own availability but does not protect it from a failing *external* dependency.

Explanation: Horizontal scaling with Auto Scaling groups allows the application to dynamically add or remove EC2 instances based on demand (e.g., CPU utilization). This is cost-effective because resources are only provisioned when needed for the report generation, rather than constantly running larger, more expensive instances. Vertical scaling would mean paying for oversized instances all the time, which is not cost-effective. Scheduling on a single large instance might still be slower and less resilient than a horizontally scaled fleet. Migrating to Lambda could be efficient but might require significant refactoring, which isn't the most immediate or cost-effective solution without further context on refactoring effort.

Explanation: Deploying the application across multiple AZs with an Auto Scaling group for EC2 instances and Amazon RDS Multi-AZ ensures high availability and automatic failover in case of an AZ outage. This provides resilience against AZ failures at a significantly lower cost than a Multi-Region deployment, which is designed for regional disasters. A Multi-Region strategy, while offering higher resilience against regional failures, is substantially more expensive and complex than needed for only AZ resilience. Daily AWS Backup snapshots would result in data loss and extended recovery time, failing the RPO/RTO implied by 'minimal data loss' and 'remain available'. Increasing instance size does not provide AZ-level resilience.

Explanation: Implementing a custom health check that only reports an instance as 'healthy' after the application has fully warmed up and loaded necessary caches ensures that traffic is only routed to fully operational instances, directly addressing the performance degradation during scaling. Configuring a longer 'instance warm-up' period in the Auto Scaling group is a simpler alternative, but it's less precise than a custom health check that verifies actual application readiness. Pre-provisioning instances is costly and inefficient. Detailed custom scripts can be complex to manage and maintain, increasing administrative overhead.