AWS Certified Solutions Architect - Professional (SAP-C02) Practice Test

Explanation

The DynamoDB global tables solution is specifically designed for this type of multi-region, active-active data replication requirement. Here's why: - Amazon DynamoDB Global Tables: This feature provides a fully managed, multi-region, and multi-master (multi-active) database solution. You create a global table by specifying the AWS regions where you want replica tables. - Automatic Replication: When your application writes data to a replica table in one region, DynamoDB automatically propagates that write to all other replica tables in the global table, typically within seconds. This ensures data consistency across regions. - Low Latency Access: Applications in each region can read and write data to their local DynamoDB replica table with low latency. - Scalability and High Availability: DynamoDB itself is highly scalable and available. Global tables extend these benefits across multiple regions, providing resilience against regional outages. - Cost-Effective: While there are costs associated with replicated write capacity units (rWCUs) and inter-region data transfer for global tables, it's often more cost-effective and significantly less operational overhead than building and managing a custom replication solution. Why other approaches are less suitable: - S3 for Transactions with S3 CRR: Amazon S3 is an object storage service, not a transactional database. While S3 CRR can replicate objects, S3 is not designed for the frequent, low-latency reads and writes typically associated with financial transactions, nor does it offer database features like atomic counters, conditional writes, or indexing in the same way DynamoDB does. - Control Tower, Connect, and separate DynamoDB tables without native replication: AWS Control Tower is for setting up and governing a multi-account AWS environment. Amazon Connect is a contact center service. Neither of these is directly relevant to multi-region database replication. Using separate DynamoDB tables in each region without a built-in replication mechanism like global tables means you'd have to build replication yourself, which is complex. - Local DynamoDB tables with Lambda for replication: While this is a possible way to build custom replication using DynamoDB Streams and Lambda, it's significantly more complex to develop, manage, and scale compared to using the fully managed DynamoDB global tables feature. Ensuring exactly-once delivery, handling errors, managing conflicts (if writes can occur in multiple regions simultaneously on the same item without proper design), and maintaining low latency across many regions would be a substantial engineering effort.

Explanation

The CloudFormation template approach and AWS Service Catalog solution are correct because they enforce tagging *at the time of resource creation* through governed provisioning. CloudFormation templates can have tags defined directly for resources, ensuring they are applied on deployment. AWS Service Catalog allows administrators to define products (often CloudFormation templates) that automatically apply tags when users provision them. This provides controlled, compliant self-service. The AWS Config rules approach is reactive (fixes tags after creation). The Systems Manager Automation documents method relies on users using specific automation docs. The AWS-generated cost allocation tags use AWS-generated tags, not custom company-specific tags.

Explanation

The correct solutions describe a defense-in-depth strategy that addresses DDoS attacks at multiple layers. CloudFront and Shield Advanced protect against volumetric and sophisticated DDoS attacks at the edge and network/transport layers, while Security Groups provide instance-level firewalls that restrict traffic to essential ports and trusted sources only. Network Access Control Lists (NACLs) offer subnet-level IP blocking as an initial stateless filtering layer, while AWS WAF protects against application-layer attacks including SQL injection and Cross-Site Scripting (XSS), and can effectively mitigate application-layer DDoS attacks through custom rules and rate limiting. The approach using Elastic Load Balancing with oversized instances and Session Manager is incorrect because Session Manager is designed for secure instance access management, not for filtering or validating web sessions to prevent DDoS attacks. Oversizing instances alone is also an inefficient and costly approach to DDoS mitigation. The solution focusing on Multi-Factor Authentication, Amazon Fraud Detector, AWS Config, and AWS Trusted Advisor addresses governance, compliance, and fraud detection rather than providing direct DDoS mitigation capabilities. While these services enhance overall security posture, they don't specifically defend against DDoS attacks. The approach emphasizing S3 versioning and Systems Manager Patch Manager addresses data integrity and vulnerability management, which are important security practices but not primary defenses against DDoS attacks. These measures don't prevent or mitigate the high-volume malicious traffic characteristic of DDoS incidents.

Explanation

This solution provides the best of both worlds: low-cost object storage for data at rest and a high-performance file system for data in use. The Amazon S3 with FSx for Lustre lazy loading approach is the most cost-effective solution. Storing the 200 TB of data in Amazon S3 is significantly cheaper than keeping it on a continuously running file server or on high-performance EBS volumes. Amazon FSx for Lustre is a high-performance file system designed for compute-intensive workloads. The key is creating it 'on-demand' just for the job run and then deleting it, so you only pay for 72 hours of high-performance storage. 'Lazy loading' is an additional cost-saver because it only pulls data from S3 into the file system as it's requested by the application, meaning you don't have to pay to store all 200 TB in the more expensive FSx file system if the job only reads a subset. The EBS io2 Block Express volume approach is incorrect because a large, high-performance EBS volume would be extremely expensive to maintain, even if only used for 72 hours a month. It is not as cost-effective as the S3/FSx combination. Pre-loading all data into FSx for Lustre is a good solution, but less cost-effective than lazy loading. Pre-loading all 200 TB of data into the FSx for Lustre file system means you pay for 200 TB of high-performance storage for 72 hours, even if the job only uses a fraction of it. Lazy loading avoids this by only loading what's needed. The AWS Storage Gateway File Gateway approach is incorrect because a File Gateway is designed for providing on-premises access to S3 or for low-latency access to frequently used data. It is not designed to be a high-performance, parallel file system for a large compute cluster and would likely be a performance bottleneck.

Explanation

The solution combining responsive Auto Scaling across multiple Availability Zones with a cost-effective mix of Reserved Instances for baseline load, and On-Demand/Spot Instances (with diversification) for peak loads is correct. This approach ensures high availability because the Auto Scaling group automatically rebalances instances across remaining Availability Zones if one fails, provides scalability for peak traffic periods, and optimizes costs by using the right pricing models for different load characteristics.\n\nThe large fixed fleet approach is not cost-effective due to significant over-provisioning of resources that remain idle during normal operations. The small fixed fleet configuration lacks the dynamic scaling capability necessary to handle sudden peak loads effectively. The all-Spot-Instance strategy with Auto Scaling restricted to a single Availability Zone introduces unacceptable risks for high availability and production stability, as Spot Instances can be interrupted and concentrating resources in one AZ creates a single point of failure.