Practice Test #7

Uploading 85 TB via AWS CLI over the internet consumes significant WAN bandwidth and is usually slow and operationally risky (retries, long transfer windows). While multipart upload helps with large objects, it does not meet the requirement to minimize network bandwidth usage. This option is best only when bandwidth is ample and time constraints are modest.

S3 File Gateway provides an NFS mount backed by S3, but it still transfers data to AWS over the network. Copying 85 TB through the gateway will consume substantial bandwidth and can take a long time depending on the internet link. File Gateway is better for ongoing hybrid workflows and caching, not for minimizing bandwidth during a bulk migration.

Direct Connect can provide higher, more consistent throughput than the public internet, but it still uses network bandwidth and typically has provisioning lead time and ongoing costs. For a one-time, static 85 TB migration with a requirement to minimize network usage, Snowball is more appropriate and usually faster to initiate than setting up Direct Connect.

Instance store can provide very high IOPS, but restoring EBS snapshots directly onto instance store is not a native “restore” operation; you would need to copy data at the OS/file level after creating EBS volumes from snapshots, which is time-consuming for 50 TB. It also adds operational complexity and risk of missing the 4-hour window. Additionally, instance store is ephemeral, which is usually undesirable for repeatable compliance testing datasets.

EBS Multi-Attach is only supported for io1/io2 and is intended for clustered applications with coordinated writes, not for creating isolated clones. Attaching the same production volumes to staging violates the requirement for complete isolation and risks data corruption or performance impact if the staging environment performs writes. Snapshots do not change the fact that the option proposes attaching production volumes, which is the core issue.

Creating new EBS volumes and restoring from snapshots provides isolation, but without Fast Snapshot Restore the volumes are lazy-loaded. To achieve consistent high performance, you often must initialize the volumes by reading all blocks, which for 50 TB can take a long time and may exceed the 4-hour window. This option is plausible but does not minimize cloning time nor guarantee immediate sustained 10,000+ IOPS performance after restore.

AWS Budgets is primarily designed for setting cost or usage thresholds and sending alerts when spending exceeds defined limits. Although budgets can be scoped with filters and cost categories, they are not intended for detailed exploratory analysis of historical EC2 spending patterns over a 60-day period. The question asks for investigation and visualization of what drove the increase, which is better handled by Cost Explorer. Budgets is useful as a complementary governance tool, but not as the primary analysis solution here.

The AWS Billing Dashboard provides summary-level billing views and basic charts, but it does not offer the level of drill-down needed to isolate which EC2 instance types or related families caused the compute cost increase. It is useful for seeing that costs changed, but not for performing detailed analysis across a custom time window with flexible grouping. Because the requirement is to identify the specific drivers of the spike, the Billing Dashboard is too limited. It lacks the richer investigative capabilities available in Cost Explorer.

AWS Cost and Usage Reports combined with Amazon S3 and Amazon QuickSight can absolutely provide highly detailed and customizable cost analytics, including line-item billing analysis. However, this approach requires enabling CUR, storing and managing report data, preparing datasets, and building dashboards, which adds more implementation and maintenance effort. The question explicitly asks for minimal management effort, so this solution is unnecessarily complex for a 60-day EC2 cost investigation. It is more appropriate when an organization needs advanced custom reporting beyond native billing tools.

Incorrect. Route 53 failover is DNS-based and cannot guarantee immediate failover because clients and resolvers may cache records beyond the intended TTL. Also, NLB cannot “invoke Lambda” directly; Lambda integrations are associated with ALB (HTTP/HTTPS) or other event sources, not NLB UDP listeners. While NLB supports UDP, the processing architecture described is not valid and does not meet microsecond/instant failover needs.

Incorrect. Application Load Balancer is a Layer 7 load balancer and does not support UDP. Even though Global Accelerator would help with latency and failover, the ALB endpoint cannot accept UDP traffic from trading terminals. This option fails the fundamental protocol requirement and therefore cannot be the correct design for the described system.

Incorrect. This combines Route 53 DNS failover with ALBs. It fails two requirements: ALB does not support UDP, and Route 53 failover is not immediate due to DNS caching/TTL behavior. Even with aggressive health checks, DNS-based approaches typically cannot meet microsecond-sensitive, continuous trading failover expectations compared to Global Accelerator.

Although EventBridge and SNS are appropriate for event detection and alerting, AWS Config is not the best fit for this use case. AWS Config is primarily designed for configuration compliance evaluation and optional remediation, not for directly handling KMS key deletion scheduling events as the most streamlined response path. It adds unnecessary complexity compared with a direct EventBridge-to-Systems Manager Automation integration. As a result, it does not represent the least operational overhead solution for automatically canceling scheduled key deletion.

This option could be made to work by having EventBridge detect the KMS ScheduleKeyDeletion event and invoking a Lambda function to call CancelKeyDeletion. However, Lambda introduces custom code that must be written, tested, secured, monitored, and maintained over time. Because the question asks for the least operational overhead, a managed Systems Manager Automation workflow is preferable to a bespoke Lambda-based remediation path. The option is also imprecise in referring to DeleteKey rather than the actual KMS deletion scheduling operation.

This option provides an alerting mechanism by using CloudTrail, CloudWatch Logs, metric filters, alarms, and SNS notifications. However, it does not include any automated remediation to cancel the scheduled deletion of the KMS key. Since the requirement explicitly says the deletion attempt must be blocked automatically, alerting alone is insufficient. It also uses a more operationally heavy log-processing path than EventBridge for this event-driven use case.