Free Amazon Web Services SAP-C02 Practice Exam with Questions & Answers | Set: 9

The modernized application needs to store and serve video files up to 4 GB. Large binary content should not be stored directly in a database because it negatively affects database performance, scaling, and backup/restore times. The standard AWS pattern is to store large objects in Amazon S3 and keep only references (such as keys or URLs) in the database.

User profile data is simple, text-based, and currently lives in a single table. This is a good fit for a key-value or document-style data model such as Amazon DynamoDB, which provides fully managed horizontal scaling and predictable performance at scale.

Option B migrates the profile table to DynamoDB using AWS DMS with AWS Schema Conversion Tool (SCT). Video files are stored as objects in Amazon S3, which is designed for large, durable, and highly scalable object storage. The DynamoDB item stores only the S3 key that corresponds to each user’s video, keeping the database small and responsive. S3 can scale rapidly and independently of the database, and offloads the heavy I/O load of large objects away from the transactional store, so overall application performance is not negatively impacted by video storage or retrieval.

Option A stores the videos as base64-encoded strings in a TEXT column in a relational database. Storing multi-gigabyte objects directly in a relational database table leads to large row sizes, larger indexes, longer backup times, and degraded performance as the table grows. This does not meet the requirement to avoid affecting application performance.

Option C uses Amazon Keyspaces (for Apache Cassandra) as the profile store and S3 for video. While storing videos in S3 is correct, Keyspaces is typically chosen when there is already a Cassandra-based workload or a need for Cassandra-compatible interfaces. For a simple single-table user profile store being migrated from MySQL, DynamoDB is the more natural, managed choice and aligns better with AWS migration and modernization guidance.

Option D stores the videos as base64-encoded strings in DynamoDB items. DynamoDB has a maximum item size of 400 KB, which is far smaller than the 4 GB video size requirement. This makes option D technically infeasible.

Therefore, migrating user profile data to DynamoDB and storing video files in Amazon S3, with S3 keys stored in the corresponding DynamoDB items (option B), provides scalable video storage and protects application performance.

https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html

- Refer to Default Result section - If the instance is terminating, both abandon and continue allow the instance to terminate. However, abandon stops any remaining actions, such as other lifecycle hooks, and continue allows any other lifecycle hooks to complete.

https://aws.amazon.com/blogs/infrastructure-and-automation/run-code-before-terminating-an-ec2-auto-scaling-instance/

https://github.com/aws-samples/aws-lambda-lifecycle-hooks-function

https://github.com/aws-samples/aws-lambda-lifecycle-hooks-function/blob/master/cloudformation/template.yaml

The correct design is to use CloudWatch usage metrics and service quota metric math. AWS publishes usage metrics for some services in the AWS/Usage namespace, and these metrics correspond to service quotas. CloudWatch can use the SERVICE_QUOTA metric math function to compare current usage against the quota and trigger an alarm when usage approaches a defined threshold. This is exactly the requirement: notify the team when Fargate task usage reaches 80% of the maximum allowed tasks. Amazon SNS is the standard low-overhead notification target for CloudWatch alarms. Polling ECS with Lambda is unnecessary custom engineering. AWS Config evaluates resource compliance, not quota utilization trends. Monitoring each ECS service’s sample count would not accurately represent account-level Fargate task quota consumption. (AWS Documentation)

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

https://aws.amazon.com/blogs/mt/self-service-vpcs-in-aws-control-tower-using-aws-service-catalog/

https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.htmlhttps://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-transitgatewayattachment.html

The company should create a Network Load Balancer (NLB) and associate it with one static IP address in multiple Availability Zones. The company should also create an ALB-type target group for the NLB and add the existing ALB. The company should add the NLB IP addresses to the firewall appliance and update the clients to connect to the NLB. This solution will allow traffic flow to AWS from the on-premises network by using static IP addresses that can be added to the firewall appliance’s allow list. The NLB will forward requests to the ALB, which will use path-based routing to forward requests to the target groups.

This option allows the company to use a single VPC to host multiple test environments that are isolated from each other by using different subnets and security groups1. By including a transit gateway attachment and related routing configurations, the company can enable the test environmentsto communicate with the central server in the on-premises data center through a VPN connection2. By using AWS CloudFormation to deploy all test environments into the VPC, the company can automate the creation and deletion of test environments without any manual intervention3. This option also minimizes the operational overhead by reducing the number of VPCs, accounts, and resources that need to be managed.

Working with VPCs and subnets

Working with transit gateways

Working with AWS CloudFormation stacks

The best answer is C because the workload has millions of small 64 KB uploads every hour. Sending every S3 object event through EventBridge to an ECS task creates high event and invocation overhead. Amazon Data Firehose can buffer many incoming records and deliver larger compressed objects to S3, which reduces the small-object problem and improves cost efficiency. The ECS processing takes an average of 15 minutes, so replacing it with Lambda is risky because Lambda has a maximum runtime of 900 seconds, exactly 15 minutes. For five-year retention, S3 Lifecycle rules can transition data to S3 Glacier Deep Archive for long-term low-cost archival. DynamoDB TTL is appropriate for automatically expiring 15-day results without custom cleanup jobs. (AWS Documentation)

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

A is correct because when a Lambda function is configured to run inside a VPC, it uses ENIs in the selected subnets and does not receive a public IPv4 address. To reach the public internet from private subnets, outbound IPv4 traffic must go through a NAT gateway (or NAT instance). A NAT gateway uses an Elastic IP address (EIP) for its public source address. Therefore, if the external provider requires public IPv4 allowlisting, the company should place the Lambda function in private subnets with a route to the NAT gateways, then provide the provider with the EIPs of the NAT gateways that will be used for egress. This satisfies the requirement to provide connectivity details in advance and ensures the provider sees only the approved public IPv4 addresses.

Why the other options are incorrect:

B (egress-only internet gateway): An egress-only internet gateway is for IPv6 outbound-only traffic, not IPv4. It does not provide an IPv4 address to allowlist, and it is not used to solve “public IPv4 allowlist” requirements.

C (associate EIP with an internet gateway): You cannot associate an Elastic IP address with an internet gateway. Internet gateways do not have a single, customer-assigned EIP for all egress. Also, placing Lambda in public subnets does not automatically give Lambda a stable public IP; Lambda in a VPC still uses private IPs on ENIs and would need NAT (for private subnet egress) or different architecture for stable egress IPs.

D (ENA for Lambda): Lambda does not support attaching a custom ENA device or installing an ENA driver via a Lambda layer to control a stable public source IP. Lambda’s VPC networking is managed by AWS; you cannot present an ENI’s private IP as an internet-routable public IPv4 allowlist address.

Establish AWS Direct Connect Connections:

Step 1: Set up two AWS Direct Connect (DX) connections from the company headquarters to a chosen AWS Region. This provides a redundant and high-availability setup to ensure continuous connectivity.

Step 2: Ensure that these DX connections terminate in a specific Direct Connect location associated with the chosen AWS Region.

Use Company WAN:

Step 1: Configure the company ' s global WAN to route traffic through the established Direct Connect connections.

Step 2: This setup ensures that all traffic between the company ' s headquarters and AWS does not traverse the public internet, maintaining compliance with security requirements.

Set Up Direct Connect Gateway:

Step 1: Create a Direct Connect Gateway in the AWS Management Console. This gateway allows you to connect your Direct Connect connections to multiple VPCs across different AWS Regions.

Step 2: Associate the Direct Connect Gateway with the VPCs in the various Regions where your critical data is stored. This enables access to data in multiple Regions through a single Direct Connect connection.

By using Direct Connect and Direct Connect Gateway, the company can achieve secure, reliable, and cost-effective access to data stored across multiple AWS Regions without using the public internet, ensuring compliance with industry regulations.

References

AWS Direct Connect Documentation

Building a Scalable and Secure Multi-VPC AWS Network Infrastructure​(AWS Documentation)​​(AWS Documentation)​.

https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/

https://docs.aws.amazon.com/appsync/latest/devguide/graphql-overview.html

AWS AppSync is a fully managed GraphQL service that allows applications to securely access, manipulate, and receive data as well as real-time updates from multiple data sources1. AWS AppSync supports GraphQL subscriptions to perform real-time operations and can push data to clients that choose to listen to specific events from the backend1. AWS AppSync uses WebSockets to establish and maintain a secure connection between the clients and the API endpoint2. Therefore, using AWS AppSync and leveraging WebSockets is a suitable design to reduce comment latency and improve user experience.

The best solution is to create an AWS WAF web ACL and configure a rule to block any requests that do not originate from the specified country. This will ensure that only users from the allowed country can access the application. AWS WAF also provides logging capabilities that can capture the access requests that have been blocked. This solution requires the least possible maintenance as it does not involve updating IP ranges or security group rules. References: [AWS WAF Developer Guide], [AWS Shield Developer Guide]

Option C is correct because leveraging Amazon Kinesis Data Streams and AWS Lambda to ingest and process the raw data resolves the issues permanently and enable growth as new sensors are provisioned. Amazon Kinesis Data Streams is a serverless streaming data service that simplifies the capture, processing, and storage of data streams at any scale. Kinesis Data Streams can handle any amount of streaming data and process data from hundreds of thousands of sources with very low latency. AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers. Lambda can be triggered by Kinesis Data Streams events and process the data records in real time. Lambda can also scale automatically based on the incoming data volume. By using Kinesis Data Streams and Lambda, the company can reduce the load on the API servers and improve the performance and scalability of the data ingestion and processing layer3

Option E is correct because re-architecting the database tier to use Amazon DynamoDB instead of an RDS MySQL DB instance resolves the issues permanently and enable growth as new sensors are provisioned. Amazon DynamoDB is a fully managed key-value and document database that delivers single-digit millisecond performance at any scale. DynamoDB supports auto scaling, which automatically adjusts read and write capacity based on actual traffic patterns. DynamoDB also supports on-demand capacity mode, which instantly accommodates up to double the previous peak traffic on a table. By using DynamoDB instead of RDS MySQL DB instance, the company can eliminate high write latency and improve scalability and performance of the database tier.

This option will optimize the application’s performance by reducing the overhead of opening and closing database connections for each Lambda invocation. An RDS proxy is a fully managed database proxy for Amazon RDS that makes applications more scalable, more resilient to database failures, andmore secure1. It allows applications to pool and share connections established with the database, improving database efficiency and application scalability1. By creating an RDS proxy by using the Lambda console, you caneasily configure your Lambda function to use the proxy endpoint instead of the directdatabase endpoint2. This will enable your Lambda function to reuse existing connections from the proxy’s connection pool, reducing the latency and CPU utilization caused by establishing new connections for each invocation. It will also prevent connection saturation or exhaustion on the database, which can degrade performance or cause errors3.

The workload must be deployed to a second AWS Region to reduce latency for users while maintaining business continuity. Because more than 95% of operations are read operations, the database layer must efficiently support low-latency reads in multiple Regions without introducing complex replication logic or sacrificing availability.

Amazon Aurora MySQL global database is specifically designed for multi-Region deployments. It provides a single primary Region for writes and up to multiple secondary Regions with read-only replicas that use low-latency, storage-based replication. This architecture is well suited for read-heavy workloads because read traffic can be served locally in each Region while writes are centralized. Aurora global database also supports fast recovery and promotes a secondary Region in the event of a primary Region failure, which satisfies business continuity requirements.

Option A correctly migrates the existing RDS for MySQL database to an Aurora MySQL global database and deploys application infrastructure (ALB and Auto Scaling group) in the second Region. This enables applications in each Region to read from the closest Aurora replica, reducing read latency while preserving a managed, highly available database architecture.

To route users to the closest healthy Region, DNS-based traffic management is required. Route 53 latency-based routing directs users to the endpoint (ALB) with the lowest latency from their location. This directly addresses the requirement to reduce application latency while also supporting multi-Region availability.

Option C provides this routing capability by configuring latency-based routing with Route 53 and pointing records to both ALBs. Route 53 continuously evaluates latency and health checks to route traffic appropriately, which supports both performance and business continuity.

Option B is not sufficient because migrating to a separate Multi-AZ database in another Region does not provide a shared data layer or managed cross-Region replication. This would require custom replication and conflict resolution and does not maintain a single logical dataset across Regions. CloudFront improves content delivery for static assets but does not solve database read latency or data consistency.

Option D uses geolocation routing, which routes traffic based on user location rather than actual measured latency. This is less precise than latency-based routing and does not automatically adapt to changing network conditions or Region health.

Option E introduces Aurora Serverless v2, which is not designed for multi-Region global database replication. Aurora Serverless v2 focuses on scaling capacity within a Region, not on reducing latency across Regions or providing managed global read replicas.

Therefore, migrating to an Aurora MySQL global database and using Route 53 latency-based routing provides low-latency reads, high availability, and business continuity with minimal operational overhead.