模擬試験 4

CloudFront can cache and reduce read latency, but it is not a multi-Region write solution and does not replicate objects between Regions. Global Accelerator improves routing to regional endpoints, but S3 is not fronted by GA in a way that provides active-active writes and a single S3 data endpoint. Trap: It looks attractive because it improves routing or availability, but routing alone does not satisfy the deeper data, security, or operational constraint.

One-way CRR only replicates from the original bucket to the new bucket. If the application in ap-southeast-2 writes to its local bucket, those objects will not replicate back to us-east-1, violating the requirement to support writes from both Regions while keeping datasets aligned. Trap: It addresses part of the database story, but it does not remove the specific bottleneck or constraint called out in the stem.

S3 gateway endpoints provide private connectivity from a VPC to S3 within a Region; they do not create a global endpoint, do not enable multi-Region writes, and do not replicate data. S3 Intelligent-Tiering is a storage class optimization for cost and access patterns, unrelated to cross-Region latency reduction or active-active multi-Region data access. Trap: S3 gateway endpoints provide private connectivity from a VPC to S3 within a Region; they do not create a global endpoint, do not enable multi-Region writes, and do not replicate data.

Increasing Lambda memory can reduce function runtime, but it does not directly solve the database connection limit or connection storm. Explicitly closing the DB connection after each query is usually counterproductive for Lambda-to-RDS because it increases connection churn (auth/TLS setup) and can raise DB CPU. This option might slightly reduce concurrent duration, but it won’t reliably prevent exhausting 500 connections during bursts. Trap: It is tempting because it addresses a nearby AWS service or partial symptom, but it misses the decisive constraint in the question.

ElastiCache for Redis is useful when repeated read queries dominate and results can be cached (e.g., course catalog browsing). However, the workload is described as transactional reads and writes for enrollment, and the symptoms include near-max DB connections and high CPU. Caching does not reduce the number of concurrent DB connections created by Lambda, and it does not help write-heavy or strongly consistent transactional paths. Trap: It is tempting because it addresses a nearby AWS service or partial symptom, but it misses the decisive constraint in the question.

Initializing the DB client outside the handler and reusing connections is a good Lambda optimization, but it only helps within a single warm execution environment. With concurrency spiking to 3,200, Lambda will create many parallel environments, each potentially holding one or more connections, still overwhelming a 500-connection RDS limit. This is a partial mitigation, not a robust solution for burst conditions compared to RDS Proxy. Trap: It is tempting because it addresses a nearby AWS service or partial symptom, but it misses the decisive constraint in the question.

Amazon FSx for Windows File Server provides a managed SMB file system that applications can access over SMB, and AWS DataSync can migrate data into it. However, the requirement is specifically to move the shared storage to Amazon S3 for durability and cost efficiency during the interim period. FSx for Windows stores data in the FSx file system rather than using S3 as the primary storage backend, so it does not satisfy the core storage-location requirement. It also introduces an AWS-hosted file system service when the design goal is to keep SMB access on premises while S3 serves as the durable backend. Trap: It is tempting because it proposes Create a new Amazon FSx for Windows File Server file system. Configure AWS DataSync with one location for the on-premises SMB s..., but it misses one of the decisive constraints in the stem.

Copying data directly from the on-premises SMB repository to an S3 bucket can satisfy the durability/cost goal, but it does not satisfy the access requirement. The application cannot use native S3 APIs for 4 months and must continue to access the dataset via SMB with minimal changes. S3 is an object store and does not provide an SMB endpoint for Windows clients without an intermediary service. Trap: It is tempting because it proposes Create an Amazon S3 bucket for the application. Copy the data from the on-premises repository directly to the S3 bucket., but it misses one of the decisive constraints in the stem.

AWS Server Migration Service (historical) is for migrating server workloads, not for providing an SMB interface backed by S3. Even if a file server were lifted and shifted to EC2, that would still mean operating a file server in AWS, which the requirements prohibit. It also adds operational burden (patching, scaling, HA) and does not inherently achieve the goal of storing the dataset in S3 as the primary repository. Trap: It is tempting because it proposes Deploy an AWS Server Migration Service (AWS SMS) connector on premises and lift-and-shift the file server to an Amazon EC2 inst..., but it misses one of the decisive constraints in the stem.

Incorrect. Relies on IP allow listing CloudFront service IP ranges, which the question explicitly forbids and is operationally brittle due to frequent changes. Also, “move the ALB into private subnets” conflicts with the described architecture (ALB in public subnets) and would require redesign (internal ALB) while still needing a supported path for CloudFront to reach the origin. Trap: It can look plausible because it mentions AWS WAF web ACL with an IP match rule for the CloudFront service IP ranges and WAF, but the requirement is application-layer origin authentication without static IP allow lists.

Incorrect. Systems Manager Parameter Store does not provide automatic rotation for arbitrary random strings in the same way Secrets Manager does for secrets rotation. Additionally, ALB listener rules are primarily for routing/forwarding decisions; they are not a robust security enforcement mechanism to block unauthorized requests based on a secret header compared to AWS WAF’s explicit allow/block controls. Trap: It can look plausible because it mentions AWS Systems Manager Parameter Store with automatic rotation enabled and CloudFront, but the requirement is application-layer origin authentication without static IP allow lists.

Incorrect. Shield Advanced provides DDoS protections and visibility but does not solve origin authentication. The option still depends on allowing CloudFront IP ranges at the network layer (security group policy), which violates the “no static IP allow lists” requirement and is difficult to maintain. Origin access control here needs an application-layer verification mechanism (e.g., WAF header match). Trap: It can look plausible because it mentions AWS Shield Advanced and create a security group policy to allow connections only from CloudFront IP address ranges and CloudFront, but the requirement is application-layer origin authentication without static IP allow lists.

File Gateway correctly preserves NFSv3 access and Lifecycle can transition objects after 5 days, but S3 Standard-IA is not the most cost-effective archival choice for backups when multi-hour retrieval is acceptable. Standard-IA is designed for infrequent access with millisecond retrieval and has higher storage cost (plus minimum storage duration and retrieval fees). Given a 72-hour DR retrieval window, Deep Archive would reduce storage cost significantly. Trap: It is tempting because Deploy an AWS Storage Gateway file gateway backed by an Amazon S3 bucket, write backups over NFS to the file share, a..., but it misses at least one decisive requirement from the scenario.

Volume Gateway presents iSCSI block volumes, not NFS file shares, so it fails the “preserves NFS access” requirement. While transitioning to S3 Glacier Deep Archive could be cost-effective for archival, the access method is wrong for the stated workflow. , iSCSI) rather than file-based NFS/SMB shares. Trap: It is tempting because Deploy an AWS Storage Gateway volume gateway associated with an Amazon S3 bucket, present iSCSI volumes to on premise..., but it misses at least one decisive requirement from the scenario.

Tape Gateway is intended for integrating with existing backup software that writes to a virtual tape library (VTL), not for preserving NFSv3 file access. It can be cost-effective for tape-based backup workflows, but it changes the access pattern and tooling. Additionally, transitioning to S3 Standard-IA is not an archival optimization compared to Glacier Deep Archive for long-term backup retention. Trap: It is tempting because Deploy an AWS Storage Gateway tape gateway with virtual tapes, write backups to the VTL, and configure an S3 Lifecycl..., but it misses at least one decisive requirement from the scenario.

Redshift Spectrum can query S3, but it normally adds a Redshift warehouse or Redshift Serverless layer. For a five-hour weekday window and six users, that is more cost and management than Athena. Trap: It uses S3, but adds a warehouse pattern that the workload does not need.

EMRFS on S3 decouples storage from compute, but Presto on EMR still requires cluster provisioning, scaling, patching, and shutdown/startup orchestration. It does not minimize operational overhead as well as Athena. Trap: It fixes HDFS dependency but leaves the EMR compute model in place.

Loading all logs into Redshift adds ingestion, tuning, and ongoing compute cost. A full warehouse is unnecessary for intermittent SQL over existing Parquet files. Trap: Redshift is powerful, but the scenario is asking for low-cost serverless querying.

Incorrect. A Network Load Balancer can expose L4 services, but it is not intended for transparent inline inspection/service insertion. NLB does not provide the GWLB/GWLBe model where route tables steer traffic as a next hop for inspection while preserving flow symmetry in the same way. Using NLB + PrivateLink is common for private SaaS/service access, not inline firewall insertion. Trap: The wording includes familiar load balancing or deployment tooling, but it misses the transparent GWLB/GWLBe service-insertion model.

Incorrect. Launch Wizard can simplify initial deployments, but it does not inherently provide the required architecture for transparent inline inspection at scale across many accounts. It also doesn’t replace the need for GWLB/GWLBe-based traffic steering and cross-account endpoint service consumption. Additionally, focusing on instance target type misses the key modernization goal: GWLB-based service insertion plus automated scaling. Trap: The wording includes familiar load balancing or deployment tooling, but it misses the transparent GWLB/GWLBe service-insertion model.

Incorrect. Endpoints for consuming a GWLB endpoint service are created in the consumer VPCs (member accounts), not in the centralized security VPC. Creating VPC endpoints in the security account would not allow member VPC route tables to target those endpoints, and it misunderstands the PrivateLink consumption model. The correct approach is per-member VPC GWLBe with routes pointing locally. Trap: The wording includes familiar load balancing or deployment tooling, but it misses the transparent GWLB/GWLBe service-insertion model.

Application dual writes and new Route 53 URLs violate no code changes, and weighted routing is traffic splitting rather than deterministic read failover. Trap: It uses two buckets, but pushes failover and consistency into the application path.

CloudFront origin failover is useful, but Lambda copy is custom replication that must handle retries, scaling, ordering, and failures for a high-request object workload. Trap: Event-driven copy can look flexible, but it is higher overhead and less native than S3 CRR.

CRR addresses replication, but manually updating the application during an outage fails the automatic failover and no application changes requirements. Trap: It solves only the data-copy half of the problem.

Incorrect. An endpoint service in eu-central-1 cannot use an NLB that exists in ap-southeast-2. PrivateLink endpoint services are Regional and must be backed by an NLB (or GWLB) in the same Region as the endpoint service. Granting account permissions is valid for PrivateLink, but the cross-Region NLB reference is not supported. Trap: This can look plausible because it mentions Configure a PrivateLink endpoint service in eu-central-1 to use the existing NLB in ap-southeast-2, and grant specific AWS accounts permission to connect, but it fails at least one decisive constraint in the stem.

Incorrect. NLB cannot attach an ALB target group that “references” an ALB in another Region, and PrivateLink endpoint services must be backed by an NLB in the same Region. While ALB-to-NLB chaining is sometimes used within a Region (via IP targets), this proposed cross-Region ALB reference is not a supported construct and adds unnecessary complexity. Trap: This can look plausible because it mentions Place an Application Load Balancer (ALB) in front of the EC2 instances in ap-southeast-2, create an NLB in eu-central-1, attach an ALB target group that references the ALB in ap-southeast-2 to the eu-central-1 NLB, and expose it via a PrivateLink endpoint service, but it fails at least one decisive constraint in the stem.

Incorrect. AWS RAM can share certain resources (e.g., subnets, Transit Gateways, Route 53 Resolver rules), but it does not share EC2 instances across Regions for use as targets in a Regional target group. Also, target groups and load balancers are Regional; you cannot register “shared instances” from another Region into an instance target group in eu-central-1. Trap: This can look plausible because it mentions Use AWS Resource Access Manager (AWS RAM) to share the EC2 instances from ap-southeast-2 with eu-central-1, create an instance target group in eu-central-1 that includes the shared instances, and expose it through a PrivateLink endpoint service, but it fails at least one decisive constraint in the stem.