Refer to the Exhibit Practice Questions

Replace the instances with a larger instance family so each server has more headroom.

Why wrong: Bigger instances can help only when compute saturation is the main bottleneck, but the exhibit points to queue buildup and request concurrency.

Use scheduled scaling to add instances only during the business hours peak window.

Why wrong: Scheduled scaling follows the clock, not live demand, so it cannot react well to sudden surges or shifting traffic patterns.

Replace the ALB with a Network Load Balancer to reduce request latency.

Why wrong: A Network Load Balancer changes the front end, but the logs show application thread exhaustion rather than load balancer overhead.

Add a permission boundary to the developer role that points to ApprovedAppBoundary.

Why wrong: That only constrains the developer role itself; it does not force new roles to use the approved boundary.

Use an S3 bucket policy to block policy documents that grant AdministratorAccess.

Why wrong: S3 bucket policies do not control IAM role creation or IAM policy attachment.

Require team members to use STS session policies when they create new roles.

Why wrong: Session policies only limit temporary sessions and do not force a permissions boundary on newly created roles.

Amazon S3 with multipart uploads because it provides durable object storage and high throughput.

Why wrong: S3 is object storage, not block storage, and it cannot serve the low-latency random I/O pattern shown in the benchmark.

Amazon EFS because it can be mounted by EC2 and supports persistent file access.

Why wrong: EFS is shared file storage, but it generally has higher latency than provisioned block storage for this single-instance random I/O workload.

Amazon FSx for Windows File Server because it offers durable storage and low latency.

Why wrong: FSx for Windows File Server is a managed file system for Windows-based use cases, not the best fit for a single Linux EC2 block-storage workload.

Use sc1 because it is optimized for infrequent access and large objects.

Why wrong: sc1 is for cold, sequential workloads, not for low-latency databases that need thousands of random IOPS.

Use st1 because it provides high throughput for streaming data.

Why wrong: st1 is designed for throughput-heavy sequential access, not low-latency random I/O for transactional databases.

Use standard magnetic storage because it is compatible with all EC2 instances.

Why wrong: Magnetic storage is legacy and far below the performance needed for a database showing high IOPS and latency pressure.

Add a NAT gateway to the private subnet route table and keep using the public Secrets Manager endpoint.

Why wrong: This restores connectivity, but it sends traffic through the internet path and adds NAT cost.

Create a gateway VPC endpoint for Secrets Manager and point the route table to it.

Why wrong: Gateway endpoints are not used for Secrets Manager; they are used for specific services like S3 and DynamoDB.

Use VPC peering to connect the application subnet to another VPC that already has internet access.

Why wrong: VPC peering does not provide internet egress or a private AWS service endpoint by itself.

Backup and restore only, because the existing daily backups are already in another Region.

Why wrong: Backup and restore typically takes too long to rebuild the environment and recover data for a 45-minute RTO, especially when application tiers and databases both need to be restored and validated.

Pilot light, because the recovery Region only needs minimal resources and can be scaled after a disaster.

Why wrong: Pilot light keeps only core components running in the recovery Region. That is cheaper, but it usually requires too much time to scale and activate the full stack to meet a 45-minute RTO.

Active-active, because it minimizes RTO by keeping both Regions fully live all the time.

Why wrong: Active-active provides the fastest recovery, but it is typically the most expensive option because both Regions must be fully provisioned and operating all the time. That conflicts with the stated budget constraint.

Use an interface VPC endpoint for S3 only, because gateway endpoints cannot be used with bucket policies.

Why wrong: Gateway endpoints are the standard and recommended private-connectivity mechanism for S3 from EC2 instances in VPCs, and they can absolutely be combined with S3 bucket policies. The claim that gateway endpoints cannot be used with bucket policies is incorrect. In fact, aws:SourceVpce is a common condition key used specifically to restrict access to a particular endpoint.

Add a NAT gateway and remove the bucket policy condition because the NAT route will automatically secure the S3 traffic.

Why wrong: A NAT gateway provides outbound internet access for private subnets, but it does not keep S3 traffic private in the way a VPC endpoint does. It also does not enforce endpoint-based authorization. This option fails both requirements: it introduces internet egress and removes the access control that limits the bucket to the approved endpoint.

Move the bucket policy restriction to a security group attached to the S3 bucket so only the VPC endpoint can reach it.

Why wrong: Security groups do not apply to S3 because S3 is a managed regional service, not an ENI-backed resource in your VPC. S3 access is controlled with IAM, bucket policies, endpoint policies, and condition keys such as aws:SourceVpce. The correct enforcement point is the bucket policy, not a security group.

Increase the table's sort key cardinality while keeping the same read pattern.

Why wrong: Changing sort key cardinality does not help if the application repeatedly reads the same items. The bottleneck is repeated reads, not range query design.

Switch the table to provisioned mode with auto scaling disabled.

Why wrong: Disabling auto scaling removes an important safety mechanism and does not reduce latency. It may also worsen throttling during peaks if capacity is not manually tuned.

Move the session data to Amazon EFS so the application can read it from shared files.

Why wrong: EFS is a file system, not a low-latency key-value cache. Moving the data would change the data model and would not provide the same read performance characteristics as DAX.

Keep simple routing and lower the TTL to 10 seconds.

Why wrong: A lower TTL can make clients refresh cached answers sooner, but simple routing still returns only one endpoint and does not provide primary/secondary failover behavior. It does not automatically switch traffic to the standby Region when the primary becomes unhealthy.

Use weighted routing with equal weights for both ALBs.

Why wrong: Weighted routing is useful for traffic splitting or gradual migration, but it is not the same as health-based disaster recovery. Equal weights do not create a primary endpoint with an automatic standby that is used only on failure.

Use geolocation routing so users in each continent reach a closer ALB.

Why wrong: Geolocation routing makes decisions based on user location, not on endpoint health or Regional disaster recovery. It is not designed to shift all traffic away from an unhealthy primary Region.

Enable S3 Transfer Acceleration on the bucket so CloudFront fetches objects faster from the origin.

Why wrong: Transfer Acceleration can speed uploads to S3, but it does not improve CloudFront cache-key efficiency or reduce misses.

Switch the origin from S3 to an Application Load Balancer so CloudFront can cache dynamic responses more effectively.

Why wrong: An ALB origin is useful for dynamic applications, but it does not solve the cache-busting header issue for static assets.

Configure CloudFront to forward every viewer header to the origin so the origin can decide whether the content is cacheable.

Why wrong: Forwarding more headers usually makes cache hit ratio worse because more unique request variations are cached separately.

Create a read replica in another Availability Zone and promote it manually if needed.

Why wrong: A read replica can help with read scaling or disaster recovery, but manual promotion is not the same as automatic failover. It adds operational delay.

Increase the automated backup retention period to 30 days.

Why wrong: Longer backup retention helps with recovery from deletion or corruption, but it does not keep the database online during an Availability Zone failure. Backups are not failover.

Resize the DB instance to a larger class.

Why wrong: A larger instance may improve performance, but it does not protect against the loss of the Availability Zone. The same single point of failure would remain.

Use an IAM user in Account B and hard-code the narrower S3 path in its access key policy.

Why wrong: This reintroduces long-term credentials and defeats the purpose of using STS assumed-role access. It also creates a separate identity instead of reusing the central deployment role.

Add a bucket ACL that grants write access only to the TeamA pipeline session name.

Why wrong: S3 ACLs cannot evaluate STS session names or enforce per-session restrictions. They are also a poor fit for least-privilege automation because they are coarse and difficult to manage safely at scale.

Attach a permissions boundary to the central role so every pipeline session inherits the narrower prefix automatically.

Why wrong: A permissions boundary limits the maximum permissions of an IAM principal, but it does not let different callers apply different temporary restrictions when they assume the same role. The boundary would apply to the role itself, not dynamically to one TeamA session versus other pipeline sessions.

Keep the bucket public and require signed URLs at CloudFront, because signed URLs automatically block all direct S3 requests.

Why wrong: Signed URLs protect access through CloudFront, but they do not make the S3 bucket private. If the bucket policy is public, anyone who knows the S3 URL can still bypass CloudFront. The origin itself must be locked down.

Add an S3 access point and allow the CloudFront distribution to use it without changing the bucket policy.

Why wrong: An access point does not automatically solve the direct-public-access problem. The origin still needs a resource policy that restricts who can read the objects, and the CloudFront distribution must be explicitly authorized to use that origin path.

Attach AWS WAF to the distribution and block requests that do not include a signed cookie.

Why wrong: WAF can help with edge filtering, but it does not prevent direct S3 object URL access. The origin must be private through CloudFront authorization, otherwise the bucket remains reachable outside CloudFront regardless of WAF rules.

Use Max I/O performance mode to optimize for the highest possible latency tolerance.

Why wrong: Max I/O is designed for very large, highly parallel access patterns and typically trades some latency for scale. That is not needed here.

Use One Zone storage class to increase metadata speed.

Why wrong: One Zone changes durability and availability scope, not the EFS performance mode that controls access behavior and latency characteristics.

Use Provisioned Throughput mode because it is the only performance mode available.

Why wrong: Provisioned Throughput changes bandwidth allocation, but the exhibit is asking about the performance mode choice between General Purpose and Max I/O.

R7i instances because more memory will improve CPU-bound job throughput.

Why wrong: Memory-optimized instances help memory-heavy workloads, but the benchmark shows CPU is the bottleneck, not RAM.

M7a instances because general-purpose families are always the safest performance choice.

Why wrong: General-purpose instances are versatile, but they are not usually the best throughput-per-dollar choice for a clearly CPU-bound workload.

T3 instances because burstable instances can handle occasional nighttime spikes at lower cost.

Why wrong: Burstable instances are better for variable, low-average-CPU workloads, not sustained CPU-heavy batch processing that runs near saturation.