Practice Test #3

EC2 Instance Connect simplifies SSH key delivery, but it does not remove the need for network-level SSH reachability to the instance. In private subnets, you still need a path such as a bastion host, VPN, or Direct Connect to reach port 22. Also, the option explicitly creates a bastion host, which the requirement forbids. Operationally, it still involves managing an access host and related security controls.

A Site-to-Site VPN is valid for private access, but it is not the most cost-effective or simplest for a distributed developer population. Requiring developers to use an additional client VPN (or “second VPN”) adds complexity, support overhead, and potentially extra licensing/cost. It also shifts the solution away from a straightforward AWS-managed administrative access pattern and does not inherently provide session-level auditing like Session Manager.

A public bastion host is a traditional pattern, but it violates the “without bastions” requirement and increases operational burden (patching, hardening, monitoring, key management, and incident response). It also requires opening inbound SSH to the bastion (even if restricted), managing security group rules, and handling SSH keys. This is typically less secure and less cost-optimized than Session Manager for ongoing operations.

This option is incorrect because AWS Cost Explorer does not automatically determine department ownership of resources. Department-level visibility requires a cost attribution method such as cost allocation tags or separate AWS accounts. In addition, AWS Cost Anomaly Detection is intended to identify unusual spending behavior compared to historical patterns, not to monitor a fixed budget threshold like 75% of $50,000. Therefore, this option fails both the ownership attribution requirement and the specific budget-threshold alert requirement.

This option is incorrect because although cost allocation tags are appropriate for assigning costs to departments, AWS Trusted Advisor is not a budgeting or spend-threshold notification service. Trusted Advisor provides recommendations related to cost optimization, security, performance, service limits, and fault tolerance. It does not natively track monthly spend against a defined budget and alert at 75% consumption. AWS Budgets is the correct AWS service for budget-based notifications.

This option is incorrect because AWS Cost Explorer predictive analytics can forecast future spending trends, but it cannot infer which department owns which resources without tags or account boundaries. That means it does not satisfy the requirement for clear visibility into spending by oncology, cardiology, and neurology. While AWS Budgets is the correct service for sending alerts at 75% of a monthly budget, the lack of a valid cost attribution mechanism makes the overall solution incomplete. As a result, this option does not fully meet the stated requirements.

Amazon RDS for SQL Server reduces operational overhead, but it does not provide the level of administrative/host access typically required to install and run specialized third-party libraries and custom security extensions. Replacing those components with AWS Lambda is a significant redesign and may not be feasible quickly or maintain identical functionality. This option underestimates refactoring effort and risk for a financial system.

Running SQL Server on Amazon EC2 with a SQL Server AMI provides full administrative control and can support any third-party libraries. However, it shifts responsibility for backups, patching, monitoring, and high availability/DR design back to the company, which conflicts with the goal of reducing operational overhead. While instance pricing can be optimized, the ongoing labor and operational complexity usually make it less cost-effective overall.

Migrating to Amazon Aurora PostgreSQL would require rewriting the application, stored procedures, and removing SQL Server dependencies, plus reworking third-party library integration. This is a modernization project, not a quick migration, and it introduces significant cost, time, and functional risk. Aurora can be cost-effective long term, but it is not the most cost-effective option for maintaining current functionality under tight timelines.

Incorrect. VPC peering adds operational complexity: managing two VPCs, configuring peering, updating route tables, and handling security rules across VPC boundaries. It also introduces constraints (no transitive routing, careful CIDR planning to avoid overlap). While it works, it is more overhead than simply adding a secondary CIDR to the existing VPC.

Incorrect. Transit Gateway is designed for scalable hub-and-spoke connectivity across many VPCs and on-prem networks. For a single VPC needing more IPs, TGW is unnecessary and adds cost and configuration complexity (attachments, TGW route tables, propagation/associations). It does not address the root problem as directly as expanding the existing VPC.

Incorrect. Using EC2-based VPN instances plus a Site-to-Site VPN/virtual private gateway is high operational overhead (instance management, patching, scaling, HA design) and is not the right tool for connecting two AWS VPCs for simple capacity expansion. This option is slower to deploy, more failure-prone, and more complex than native VPC CIDR expansion.

Incorrect. Cache-Control headers influence how clients and intermediaries cache content, but they do not provide a global network path optimization for large uploads/downloads. They might help reduce repeated downloads if a CDN/browser caches objects, but the question emphasizes frequent large file transfers by global users and maximizing throughput—requirements better met by Transfer Acceleration or a CDN strategy, not headers alone.

Incorrect. CloudFront can accelerate downloads and reduce latency by serving cached content from edge locations, but hosting the video files on EC2 is not cost-effective or operationally efficient compared to S3 for large object storage. Additionally, the question highlights frequent uploads; CloudFront is not the primary service for accelerating uploads at scale without extra complexity, whereas S3 Transfer Acceleration is designed for this use case.

Incorrect. ElastiCache is an in-memory cache for low-latency data access (Redis/Memcached) and is not suitable for storing or transferring multi-GB video files. EC2 with Auto Scaling also introduces management overhead and does not inherently reduce global transfer latency. This option misunderstands the problem: the challenge is global network transfer performance for large objects, not application caching of small, hot data.

Storage Gateway Volume Gateway (stored volumes) presents iSCSI block volumes to on-prem hosts and is useful for hybrid block storage and backup to AWS. However, it is not a POSIX-compliant parallel file system and does not provide Lustre-like parallel I/O semantics across 100+ nodes. iSCSI shared block access also introduces coordination/cluster filesystem complexity and is not designed for sub-millisecond, high-concurrency HPC file workloads.

Building a parallel file system on an EC2 instance with EBS (even RAIDed gp3) is not a fully managed solution and creates single-instance bottlenecks and operational risk (patching, scaling, HA, metadata performance). EBS is block storage attached to EC2; sharing it across many nodes requires additional clustering and typically cannot deliver the managed, horizontally scalable parallel I/O architecture expected for HPC genomics workloads.

Amazon EFS provides managed, POSIX-compliant shared file storage over NFSv4.1 and can scale throughput (Max I/O mode, Provisioned Throughput). But EFS is not a parallel file system like Lustre; it is optimized for general shared file access rather than ultra-low-latency, high-throughput parallel I/O patterns. For HPC scratch and genomics pipelines needing sub-millisecond latencies and parallel striping, EFS is usually not the best fit.

AWS Fargate with an ALB across multiple AZs can be highly available and scalable, but containerizing a legacy Java app typically requires creating container images, adjusting configuration, logging, and CI/CD processes. That is more change than a straightforward EC2 rehost. It can meet resilience goals, but it is not the best fit for “minimize code changes” compared to EC2 Auto Scaling for an existing RHEL-based deployment.

Rewriting the application into microservices on AWS Lambda with API Gateway is a major refactor. It changes the application architecture, deployment model, and often the data access patterns, which conflicts with the requirement to minimize code changes. While serverless can scale well and reduce ops, it introduces significant redesign effort and risk—typically not appropriate for a time-sensitive migration of a trading platform.

Migrating from MySQL to Amazon DocumentDB (MongoDB-compatible) is a database model change (relational to document). This would require significant schema redesign, query rewrites, and application code changes, violating the “minimize code changes” requirement. Although DocumentDB can be deployed across AZs, it is not a drop-in replacement for MySQL and is not the best choice for transactional relational workloads typical in trading systems.

Amazon MQ for RabbitMQ is a good step for reducing broker ops and improving HA. However, placing MySQL on EC2 in a Multi-AZ Auto Scaling group is not a valid HA database strategy by itself. Auto Scaling can replace instances, but it does not provide synchronous replication, consistent storage, or automatic database failover. This option leaves significant operational overhead and risk for the database tier.

Running RabbitMQ on EC2 with Multi-AZ Auto Scaling is operationally heavy and not inherently HA. RabbitMQ requires clustering/quorum configuration, durable storage design, careful node replacement, and client reconnection handling. Auto Scaling alone can also cause disruptive replacements. While RDS Multi-AZ is the right choice for the database, the broker tier still has higher operational overhead than using Amazon MQ.

This option relies entirely on EC2 Auto Scaling for RabbitMQ and MySQL, both stateful systems. Auto Scaling does not automatically provide data replication, durable shared storage, or coordinated failover for brokers/databases. You would need to build and operate clustering/replication, backups, and failover mechanisms yourself, which conflicts with the “least operational overhead” requirement and increases the risk of downtime.

Incorrect. FSx is a managed file system service (e.g., FSx for Windows File Server), but “FSx File Gateway mode” is not the appropriate Storage Gateway option for landing data into S3 for file-based analytics. The requirement is to query .csv files cost-effectively using SQL; that pattern is best served by S3 as the data lake storage, not by maintaining an FSx-backed file system.

Incorrect. Amazon EMR with EMRFS can query data in S3 using Spark/Hive/Presto, but it requires cluster provisioning and ongoing management. For only 3–4 analytical query runs per day, EMR is typically less cost-effective than Athena because you pay for EC2 instances (and often idle time) unless you build and orchestrate ephemeral clusters, adding complexity.

Incorrect. Amazon Redshift can query S3 using COPY or Redshift Spectrum, but a Redshift cluster introduces higher fixed costs and operational considerations. For ad hoc SQL queries on raw CSV files a few times daily, Athena is usually the most cost-effective serverless choice. Redshift is better when you need consistently high concurrency, complex warehousing, or frequent queries on curated datasets.