Practice Test #3

Incorrect. Amazon Inspector focuses on vulnerability management and exposure findings (e.g., CVEs, network reachability), not governance for cost allocation tags. It is not designed to discover or enforce missing CostCenter tags on EC2 instances, and it would not provide the required preventive control to block untagged launches. Trap: It can look plausible because it mentions Amazon Inspector at the organization level to discover resources with missing CostCenter tags, but the requirement is centralized tag compliance, organization-wide reporting, and preventive enforcement at launch time.

Incorrect. An IAM policy can deny ec2:RunInstances when a request tag is missing, but it must be attached and maintained in each account (and potentially for many roles/users). It is easier to misconfigure, may not cover all principals, and is not as robust as an SCP for organization-wide preventive governance. The question explicitly wants organization-wide control and centralized reporting. Trap: It can look plausible because it mentions IAM, but the requirement is centralized tag compliance, organization-wide reporting, and preventive enforcement at launch time.

Incorrect. AWS Security Hub aggregates security findings from services and partners; it is not a primary mechanism for tag compliance reporting across all EC2 instances. While custom findings could be created indirectly, it does not natively provide the required-tag compliance evaluation and does not enforce preventive controls to block untagged EC2 launches. Trap: It can look plausible because it mentions AWS Security Hub to aggregate a list of EC2 instances that are missing the CostCenter tag, but the requirement is centralized tag compliance, organization-wide reporting, and preventive enforcement at launch time.

Incorrect. An Application Load Balancer is Regional and cannot span multiple Regions or be attached to subnets in two different VPCs/Regions. Likewise, an Auto Scaling group cannot launch instances across multiple Regions; it is scoped to one Region and one VPC. VPC peering does not change these service boundaries, so this design cannot implement the required cross-Region active-passive DR. Trap: It looks like cross-Region HA, but it either stretches Regional services beyond their scope or fails to enforce primary/secondary DNS behavior.

Incorrect/insufficient. While it correctly builds separate stacks in each Region, it does not explicitly configure Route 53 for active-passive behavior. “Enable health checks on both records” without a failover routing policy could lead to active-active behavior (depending on routing policy) or ambiguous traffic routing. The requirement states traffic must be served only from ap-southeast-2 during normal operations. Trap: It looks like cross-Region HA, but it either stretches Regional services beyond their scope or fails to enforce primary/secondary DNS behavior.

Incorrect. Like option A, it relies on an ALB and Auto Scaling group spanning multiple VPCs/Regions, which is not supported. A single Route 53 record pointing to one ALB also does not provide the required active-passive cross-Region failover. VPC peering is unnecessary for this pattern and does not enable cross-Region load balancing. Trap: It looks like cross-Region HA, but it either stretches Regional services beyond their scope or fails to enforce primary/secondary DNS behavior.

It violates the security requirement because artifacts would be stored in S3, which is not the approved registry. Also, Lambda layers are ZIP archives, not created from a Docker image stored in S3. Trap: It is tempting because it mentions Amazon S3, but it misses a required capability, constraint, or lower-operations pattern from the stem.

Although ECR is the approved registry, Lambda layers are not created directly from an ECR container image. Layers are published as ZIP archives (uploaded to Lambda), and typical deployment workflows often involve S3 as a staging location. Trap: It is tempting because it mentions Amazon ECR, but it misses a required capability, constraint, or lower-operations pattern from the stem.

ECS/Fargate runs long-lived containers, but Lambda cannot “reference a running container” as a Lambda layer. Layers are static dependency bundles mounted into the Lambda execution environment at init time. Trap: It is tempting because it mentions Amazon ECS, but it misses a required capability, constraint, or lower-operations pattern from the stem.

Taking snapshots every 4 minutes and copying them to another Region is not a practical way to achieve a sub-4-minute RPO for a 9 TB relational database. Snapshot creation, cross-Region copy, and restore operations introduce substantial delay, and restoring a new Aurora cluster from backup would almost certainly exceed the 12-minute RTO. This option is a backup-and-restore strategy, not a warm standby disaster recovery design. It is suitable for longer recovery windows, not near-real-time cross-Region failover. Trap: The alternative is attractive because it lowers steady-state cost, but it cannot satisfy both the cross-Region and minute-level recovery constraints.

An RDS for PostgreSQL cross-Region read replica is a valid disaster recovery pattern, but it is not the strongest choice for a strict RPO under 4 minutes on a 9 TB database. Cross-Region replication for standard RDS PostgreSQL is asynchronous and can experience lag that is harder to bound tightly under heavy write workloads or large-scale operational conditions. The option may work in some environments, but the question asks for a solution that should be chosen to meet the stated objectives with confidence. Aurora-based cross-Region replication patterns are generally better aligned with stringent minute-level DR requirements. Trap: The alternative is attractive because it lowers steady-state cost, but it cannot satisfy both the cross-Region and minute-level recovery constraints.

A read replica in the same Region does not satisfy the explicit requirement to fail over to a secondary AWS Region. It can help with instance or Availability Zone failures, but it offers no protection against a full Regional outage. Because the compliance requirement specifically calls for secondary-Region failover, this option must be eliminated regardless of its cost or promotion speed. Therefore it cannot be the correct answer. Trap: The alternative is attractive because it lowers steady-state cost, but it cannot satisfy both the cross-Region and minute-level recovery constraints.

Incorrect. AWS Firewall Manager can centrally manage security group policies, but security groups do not provide HTTP request-rate limiting and are not well-suited to blocking hundreds of rotating IPs based on application-layer behavior. You would need frequent updates as IPs change weekly, which is operationally heavy. Additionally, security groups are stateful L3/L4 controls and cannot express “300 requests in 5 minutes” logic. Trap: It is tempting because it addresses a nearby AWS service or partial symptom, but it misses the decisive constraint in the question.

Incorrect. An allow-only security group policy (allowlisting CIDRs) is typically infeasible for a public mobile wallet API because legitimate users come from many dynamic ISP/mobile IP ranges. It would also create significant operational burden and business risk (blocking real customers). This does not address the core requirement of rate limiting abusive login attempts at the application layer. Trap: It is tempting because it addresses a nearby AWS service or partial symptom, but it misses the decisive constraint in the question.

Incorrect. An AWS WAF IP set match rule can block known bad IPs, but the scenario states the source IPs rotate every 7 days. That would require continuously updating the IP set (manual or automated), which is less operationally efficient than a rate-based rule. IP sets are best when the malicious IPs are stable and you want deterministic blocking, not behavior-based throttling. 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 is operationally heavy (role and inline deny policies in every account) and not centrally enforced. IAM policies cannot reliably override all possible privilege paths, and account admins/root could still grant themselves permissions unless constrained by SCPs. Also, creating vendor-admin-role in every account expands the attack surface and does not address spoofing or consistent organization-wide enforcement. Trap: It is tempting because it proposes Create an IAM role named vendor-admin-role in every AWS account and attach the PowerUserAccess managed policy; add inline polic..., but it misses one of the decisive constraints in the stem.

Incorrect. Permission boundaries limit only the roles/users they are attached to; they do not restrict other principals (including admins/root) and do not provide organization-wide enforcement. Creating vendor-admin-role in every account with AdministratorAccess is the opposite of least privilege and increases risk. Boundaries on developer roles do not prevent other roles from gaining Private Marketplace admin permissions. Trap: It is tempting because it proposes Create an IAM role named vendor-admin-role in every AWS account and attach the AdministratorAccess managed policy; define a per..., but it misses one of the decisive constraints in the stem.

Incorrect. It places the admin role in developer product accounts, violating the requirement that administration be restricted to vendor managers in shared services accounts. Attaching an SCP only to shared services OUs is backwards; the restriction must apply across the entire organization. It also fails to prevent spoofing and does not centrally deny other accounts from gaining Private Marketplace admin capabilities. Trap: It is tempting because it proposes Create an IAM role named vendor-admin-role in all developer product accounts and attach the AWSPrivateMarketplaceAdminFullAcces..., but it misses one of the decisive constraints in the stem.

EC2 behind an ALB across multiple AZs is highly available, and scheduled Auto Scaling can prepare for predictable Sunday peaks. However, it requires OS/app server management, patching, AMI maintenance, and right-sizing. It is less “minimal operational overhead” than serverless and may still overprovision capacity for the 4-hour window, increasing cost and operational burden. Trap: It can look plausible because it mentions Amazon EC2 On-Demand Instances behind an Application Load Balancer across multiple Availability Zones and Amazon EC2 Auto Scaling to add capacity before the Sunday evening submission surge, but the requirement is elastic serverless ingestion and low-operations analytics over stored data.

ECS with an ALB and scheduled Service Auto Scaling reduces some operational work versus raw EC2, but you still manage container images, task sizing, scaling policies, and potentially the underlying capacity (unless using Fargate, which is not stated). It can meet availability and scaling needs, but it is not as low-ops and elastic as API Gateway + Lambda for bursty, short-duration spikes. Trap: It can look plausible because it mentions Amazon Elastic Container Service and Amazon ECS, but the requirement is elastic serverless ingestion and low-operations analytics over stored data.

Redshift + QuickSight can deliver strong BI performance, but Redshift is a managed data warehouse that typically requires capacity planning (node types, scaling, concurrency), data loading pipelines, and ongoing cost even outside peak usage unless using additional features. For this use case, it is more operationally heavy than a serverless S3/Athena approach. Trap: It can look plausible because it mentions Amazon Redshift and Amazon QuickSight to generate the monthly dashboards from Amazon Redshift, but the requirement is elastic serverless ingestion and low-operations analytics over stored data.

Memory-optimized instances fit the in-memory shard requirement, but a partition placement group is aimed at fault isolation by placing instances into separate partitions (different racks). That separation can increase network hop count and does not target the absolute lowest instance-to-instance latency. Trap: It can be built, but it keeps more infrastructure to operate or does not target the stated constraint as directly as the correct pattern.

Compute-optimized instances may help with CPU-heavy workloads, but the question emphasizes that hot game-state shards must be stored and replicated entirely in memory, which typically points to memory-optimized instances. Additionally, partition placement groups prioritize failure-domain isolation rather than the lowest latency. Trap: It can be built, but it keeps more infrastructure to operate or does not target the stated constraint as directly as the correct pattern.

A spread placement group places instances on distinct underlying hardware to reduce correlated failures, which is useful for a small number of critical instances but generally increases physical separation and can worsen latency. It is not intended for high-throughput, low-latency east-west replication. Trap: It can be built, but it keeps more infrastructure to operate or does not target the stated constraint as directly as the correct pattern.

Although a 1 Gbps Direct Connect would be much faster than the existing 150 Mbps internet link, it is still a network-based transfer and would take substantial time for 72 TB, in addition to potential provisioning delays for the circuit. The question asks for the least amount of time for a one-time migration, and offline transfer with Snowball is generally faster for this data volume. AWS DMS is the correct migration service, but the transport method in this option is not the fastest available. Therefore, this is a valid approach, but not the best answer for minimum elapsed migration time. Trap: Request a 1 Gbps AWS Direct Connect connection between the on-premises data center and AWS. Use AWS Database Migration Service (AWS DMS) to migrate the on-premises Mar... looks plausible because it addresses part of the scenario, but it misses or misstates a decisive requirement from the stem.

AWS DataSync is intended for accelerating and orchestrating file and object data transfers, not for performing logical relational database migration from MariaDB into Aurora MySQL. AWS Application Migration Service is used to rehost whole servers into Amazon EC2 and does not migrate a MariaDB database into Aurora as a managed database target. This option misuses both services for the stated goal. Even if transfer performance improved, the migration path itself is not appropriate. Trap: Use AWS DataSync over the existing internet connection to accelerate the transfer between the on-premises data center and AWS. Use AWS Application Migration Service to... looks plausible because it addresses part of the scenario, but it misses or misstates a decisive requirement from the stem.

AWS Snowball can help with offline bulk transfer, but this option uses AWS Application Migration Service, which is not a database migration tool and cannot load data from Amazon S3 into Aurora MySQL. MGN replicates server disks for lift-and-shift migrations to EC2, not relational data into Aurora. Also, the older Snowball S3 Adapter terminology does not change the fact that the target migration service is wrong. Because the service combination is invalid for database migration, this option cannot be correct. Trap: Order an AWS Snowball device. Load the data into an Amazon S3 bucket by using the S3 Adapter for Snowball. Use AWS Application Migration Service to migrate the data fr... looks plausible because it addresses part of the scenario, but it misses or misstates a decisive requirement from the stem.