模擬試験 2

This improves performance by adding capacity (desired 28) and uses Reserved Instances for 20, but it is not the most cost-effective. The workload’s average CPU is only 10%, indicating 20 instances are significantly overprovisioned for baseline. Reserving 20 instances for 3 years locks in unnecessary spend. Also, setting desired capacity to 28 is not true elasticity; it keeps extra instances running even outside spike hours unless scaling policies reduce it. Trap: It is tempting because it mentions a plausible AWS component, but it misses the decisive cost optimization constraint from the stem.

Spot Fleet with DefaultTargetCapacityType set to On-Demand effectively provisions mostly On-Demand capacity, so it doesn’t materially reduce cost versus using Auto Scaling with On-Demand. Additionally, Spot Fleet is a legacy approach compared to EC2 Auto Scaling with mixed instances policies. It also doesn’t address right-sizing the baseline; it keeps TotalTargetCapacity at 20 continuously, which remains overprovisioned given 10% average CPU. Trap: It is tempting because it mentions a plausible AWS component, but it misses the decisive cost optimization constraint from the stem.

This relies primarily on Spot capacity (DefaultTargetCapacityType=Spot) with a maintain request, which can reduce cost but introduces interruption and capacity-availability risk during critical market-open spikes. The question emphasizes resolving latency during spikes for a compliance program; without explicit interruption tolerance and fallback to On-Demand, Spot is risky. Replacing NLB with ALB is unnecessary for a stateless API already behind NLB and adds change without clear benefit. Trap: It is tempting because it mentions a plausible AWS component, but it misses the decisive cost optimization constraint from the stem.

Incorrect. Sharing account access keys (especially root or broadly privileged keys) is one of the least secure approaches. It uses long-term credentials, is hard to audit and rotate safely, and violates AWS best practices. Trap: It is tempting because The customer provides the firm with account access keys so the firm can log in and perform the required tasks., but it misses at least one decisive requirement from the scenario.

Incorrect. Creating an IAM user and sharing long-term access keys is explicitly discouraged for third-party access. Even if permissions are scoped, long-term credentials increase exposure (leakage, reuse, storage risk) and require ongoing rotation and secure distribution. Trap: It is tempting because The customer creates an IAM user with the required permissions and shares the user’s long-term credentials with the f..., but it misses at least one decisive requirement from the scenario.

Partially correct but not the MOST secure. Using an IAM role and STS AssumeRole provides temporary credentials and supports least privilege, which is good. However, for independent third-party access, omitting an ExternalId leaves the customer more exposed to confused deputy scenarios. Trap: Partially correct but not the MOST secure.

Incorrect. EBS snapshots via DLM are point-in-time and typically scheduled (minutes to hours). Achieving a consistent 2-minute RPO for stateful Windows instances is not realistic, and restore time (create volumes, attach, boot, reconfigure) can jeopardize the 30-minute RTO. RDS cross-Region backup copy is also slower to recover than promoting a read replica, increasing database RTO risk. Trap: It may look plausible because it uses relevant AWS services, but it misses the decisive constraint described in the explanation.

Incorrect. AWS Backup with cross-Region copy is backup/restore DR, not near-real-time replication. It is unlikely to meet the 2-minute application RPO and may struggle with 30-minute RTO due to restore orchestration. CloudFront in front of an ALB does not inherently provide multi-Region active/standby failover for dynamic APIs; origin failover and cache behavior add complexity and do not ensure optimal latency post-failover. Trap: It may look plausible because it uses relevant AWS services, but it misses the decisive constraint described in the explanation.

Incorrect. While the RDS cross-Region read replica helps meet the database RPO/RTO, using DLM EBS snapshots for the EC2 application tier is not sufficient for a 2-minute RPO and can lead to longer recovery times. Also, it does not address the requirement to update the third-party DNS to a resilient global entry point; without that, failover may depend on external DNS behavior and TTLs. Trap: It may look plausible because it uses relevant AWS services, but it misses the decisive constraint described in the explanation.

EKS on EC2 adds node, cluster, and Kubernetes operations and pod tags are not AWS billing tags for task-level chargeback. Trap: Kubernetes can run containers, but the question rewards lower operations and AWS resource tags.

EKS on Fargate removes nodes but still adds Kubernetes overhead and does not provide simple AWS tags on pods as running billing units. Trap: Fargate is attractive, but EKS pod tagging is the wrong cost-allocation mechanism here.

ECS task tags are useful, but ECS on EC2 requires managing capacity providers or Auto Scaling for up to hundreds of concurrent tasks. Trap: It has the right ECS tagging idea but misses the serverless capacity requirement.

S3 One Zone-IA keeps data online with millisecond access and is meant for infrequently accessed but still readily retrievable objects. For 7-year retention of 180 TB/month, storage cost is the dominant factor, and One Zone-IA will be significantly more expensive than Glacier Deep Archive. Also, enabling static website hosting is unnecessary and typically implies public website endpoints, conflicting with the “private-only” intent even if an endpoint policy is used. Trap: These choices preserve online access or add servers, which sounds convenient, but the stem rewards cold archival cost above retrieval speed.

EFS (even One Zone-IA) is a shared POSIX file system optimized for low-latency file access, not massive archival at minimal cost. You would also pay for EC2 instances (web server) and potentially data transfer/throughput, making it far more expensive than S3 archival classes. It also adds operational overhead (patching, scaling) that provides no benefit given the low request rate and high latency tolerance. Trap: These choices preserve online access or add servers, which sounds convenient, but the stem rewards cold archival cost above retrieval speed.

EBS Cold HDD (sc1) is the lowest-cost EBS option but is still block storage attached to EC2 and is not intended for multi-petabyte, long-term archives. You must run EC2 to serve files, manage backups/snapshots, and handle durability/availability yourself. Costs scale poorly compared to S3 Glacier Deep Archive, and operational complexity is high for a simple archive use case. Trap: These choices preserve online access or add servers, which sounds convenient, but the stem rewards cold archival cost above retrieval speed.

Creating separate tag policies per OU increases drift and overhead when one centrally managed policy can be attached to all relevant OUs. Trap: The controls are similar, but duplicating them conflicts with least operational effort.

Attaching IAM policies to every user and role is hard to keep complete across accounts and future identities. Trap: IAM can use request-tag conditions, but it is the wrong scale boundary for Organizations-wide enforcement.

Service Catalog TagOptions can help with governed provisioning, but converting every template and workflow is much more operational change than Organizations policies. Trap: It can govern tags, but the company already standardizes on CloudFormation and asks for least effort.

S3 + API Gateway + SQS are aligned, but ECS is not “serverless-first” in the exam sense because you still manage task definitions, scaling, capacity (Fargate would be closer), and operational overhead. Also, “SQS long polling to retain failed checkouts” is incorrect: long polling reduces empty receives; it does not provide failure retention. Proper failure handling is via DLQ and retention/redrive policies. Trap: Use Amazon S3 for static web hosting with Amazon API Gateway for database API services; use Amazon Simple Queue Service (Amazon SQS) for checkout queuing; use Amazon E... looks plausible because it addresses part of the scenario, but it misses or misstates a decisive requirement from the stem.

Elastic Beanstalk introduces server/instance management (even if simplified), conflicting with eliminating server management. Amazon MQ is typically chosen for JMS/AMQP compatibility and is not the simplest low-ops choice for high-throughput burst buffering compared to SQS. Storing failed events in S3 Glacier Deep Archive meets retention but is poor for “later replay” due to retrieval delays and operational complexity versus SQS DLQ redrive. Trap: Use AWS Elastic Beanstalk for web hosting with Amazon API Gateway for database API services; use Amazon MQ for order queuing; orchestrate payment business logic with A... looks plausible because it addresses part of the scenario, but it misses or misstates a decisive requirement from the stem.

Lightsail and EKS are not serverless-first and require server/cluster management, which violates the cost/ops requirement. SES is not an order queueing service and does not provide the semantics needed for reliable event buffering and replay. OpenSearch is not an appropriate mechanism for retaining failed checkout events for replay; it’s a search/analytics engine, not a durable failure queue with redrive. Trap: Use Amazon Lightsail for web hosting with AWS AppSync for database APIs; use Amazon Simple Email Service (Amazon SES) for order queuing; run payment business logic on... looks plausible because it addresses part of the scenario, but it misses or misstates a decisive requirement from the stem.

Incorrect. A Site-to-Site VPN provides L3 connectivity between networks and is not the intended pattern for consuming an AWS-hosted SaaS that already offers PrivateLink. It also introduces broader network reachability and operational overhead (tunnels, routing, failover). NACLs are stateless and coarse-grained; they are not a strong least-privilege control compared to security groups on a PrivateLink endpoint. Trap: It is tempting because it addresses a nearby AWS service or partial symptom, but it misses the decisive constraint in the question.

Incorrect. VPC peering creates direct private routing between VPCs, expanding the trust boundary and allowing potentially broad access unless tightly controlled with security groups and routes. It also does not align with the SaaS model where the provider publishes an endpoint service name (PrivateLink). Peering can create unintended lateral movement risk and is commonly disallowed when strict isolation is required. Trap: It is tempting because it addresses a nearby AWS service or partial symptom, but it misses the decisive constraint in the question.

Incorrect. This reverses the PrivateLink roles. The SaaS provider is the service provider and already publishes an endpoint service name; the firm is the consumer and should create an interface endpoint. Creating an endpoint service in the firm account would make the firm the provider, and asking the SaaS to connect to it contradicts the requirement that no resources in the firm VPC may be reachable from outside the firm VPC. Trap: It is tempting because it addresses a nearby AWS service or partial symptom, but it misses the decisive constraint in the question.

kms:GetKeyPolicy only allows reading the CMK’s key policy document. It does not grant any cryptographic capability and is not used by client-side encryption libraries to encrypt data. Upload failures due to AccessDenied in this scenario are caused by missing permissions to generate or use data keys, not by inability to view the key policy. Trap: It is tempting because it proposes kms:GetKeyPolicy, but it misses one of the decisive constraints in the stem.

kms:GetPublicKey is used with asymmetric KMS keys to retrieve the public key for operations like client-side verification or encryption with an asymmetric key. Client-side encryption for S3 with KMS CMKs typically uses symmetric keys and envelope encryption with data keys, not public-key retrieval. This action would not enable generating a DEK for file encryption. Trap: It is tempting because it proposes kms:GetPublicKey, but it misses one of the decisive constraints in the stem.

kms:Sign is for creating digital signatures with an asymmetric KMS key. It is unrelated to encrypting S3 objects (client-side or server-side). Even if the company used signing for integrity, it would not solve the AccessDenied encountered during upload, which stems from missing permission to generate a data encryption key. Trap: It is tempting because it proposes kms:Sign, but it misses one of the decisive constraints in the stem.