Practice Test #1

AWS Data Pipeline is primarily for scheduled/batch data movement and orchestration, not high-volume real-time streaming ingestion. While S3 + EMR can analyze large datasets, the ingestion layer here is the weak point: Data Pipeline does not provide the same real-time buffering, scaling, and replay semantics as Kinesis. This option also increases operational complexity for near-real-time requirements.

An Auto Scaling group of EC2 instances to capture and forward streaming events is a DIY ingestion approach that is harder to scale reliably and operate (capacity planning, backpressure handling, retries, ordering, and failure recovery). It can work, but it is not the most appropriate managed pattern for 25 TB/day of real-time telemetry. Kinesis provides these capabilities natively with less operational overhead.

Amazon CloudFront is designed to cache and deliver content with low latency; it is not intended to store or collect user interaction telemetry as a primary data ingestion mechanism. Triggering Lambda from S3 object creation implies batch/object-based ingestion rather than continuous streaming, and it can create scaling and latency challenges at very high volumes. This is an architectural mismatch for real-time behavior analytics.

Denying ec2:DeleteSnapshot in IAM can reduce accidental deletions for a specific principal, but it’s not a reliable safety net. The script could run under another role, an admin could still delete, and it doesn’t provide recovery if deletion happens. It also conflicts with the requirement to allow deletions (not keep snapshots forever) because you’d need exceptions and more policy management.

Copying snapshots to another Region is primarily a disaster recovery strategy for regional outages, not an accidental-deletion safety net. If the same automation or operator deletes snapshots in both Regions (or if permissions allow), you can still lose them. It also adds ongoing cost and operational complexity (copy schedules, monitoring, retention management) compared to a simple recycle bin rule.

EBS snapshots are not objects you can copy directly into an S3 bucket and then choose S3 Standard-IA. Snapshots are stored and managed by the EBS snapshot service. While some AWS services can export certain data to S3, “copy snapshots to S3 Standard-IA” is not a valid native mechanism for EBS snapshot retention and recovery in this context.

Incorrect. AWS Transfer Family does not use Amazon EBS as a storage backend, so attaching an io2 EBS volume to a Transfer Family endpoint is not a supported architecture. EBS is block storage intended for EC2 and similar compute-attached use cases, not for managed Transfer Family storage integration. In addition, the option specifies FTP rather than SFTP, which does not meet the implied enterprise-grade security expectations for a financial services workload unless explicitly required.

Incorrect. AWS Transfer Family can use Amazon EFS as a backend, so this option is closer than A or D, but it is not the best answer for a serverless high-scale partner file exchange workload. EFS introduces file-system performance design considerations and is generally less straightforward than S3 for large-scale external file exchange, while the question does not require POSIX semantics that would justify EFS. The wording about elastic IP addresses is also problematic because Transfer Family endpoint networking is managed differently, and the option is less clean and less aligned with the simplest scalable serverless design than S3-backed Transfer Family.

Incorrect. A Transfer Family endpoint placed in a private subnet behind a NAT gateway would not be reachable inbound from external partner banks on the internet. NAT gateways are used for outbound internet access from private resources, not for accepting inbound partner connections or enforcing source-IP allow lists. Although S3 and a custom identity provider could satisfy storage and authentication requirements, the networking design as stated fails the external access requirement.

API Gateway is for building and managing APIs, not for routing generic S3 API calls from workloads to S3 to reduce data transfer charges. Placing API Gateway in a subnet is also conceptually incorrect (API Gateway is a managed regional service, not deployed into your VPC unless using private integrations). It would add request-based costs and complexity and does not provide the direct private S3 routing benefit of a gateway endpoint.

A NAT gateway in a public subnet allows private subnets to reach the internet/AWS public endpoints, including S3, but it introduces NAT gateway hourly charges and per-GB data processing fees. For large medical images, NAT processing costs can be substantial and often the root cause of rising bills. Also, you don’t attach an “endpoint policy” to a NAT gateway; endpoint policies apply to VPC endpoints.

Putting the application in a public subnet and using an internet gateway sends S3 traffic over public IP routing paths. This does not minimize cost and can increase security risk by expanding the attack surface. It also doesn’t provide fine-grained network-level controls like VPC endpoint policies and bucket policies requiring a specific VPC endpoint. This is generally the opposite of best practice for healthcare workloads.

Savings Plans can reduce compute cost for steady-state, predictable EC2 usage, but they do not address the root cause: heavy static content bandwidth driving scale-out events. Peak demand (6–10 PM) is spiky and may not be fully covered by a commitment without overcommitting. Also, Savings Plans don’t reduce latency or offload traffic from the instances; they only discount eligible compute usage.

Spot Instances with a mixed instances policy can lower costs for burst capacity, but it introduces interruption risk and still keeps static content delivery on EC2. For large video/PDF downloads, the main cost driver is data transfer and origin load, not just instance-hours. Spot can help, but it’s not the MOST cost-effective redesign compared to moving static delivery to CloudFront/S3.

API Gateway + Lambda is not suitable for serving large static assets like videos and PDFs at scale. Lambda has payload/streaming constraints and would be cost-inefficient for high-bandwidth delivery; API Gateway also adds per-request costs and isn’t a CDN. This option increases complexity and cost while not providing the edge caching and optimized delivery that CloudFront offers.