Design High-Performing Architectures practice questions

Answer: A) Turn cross-zone load balancing back on in the target group attributes so every node routes to targets in all AZs

With cross-zone load balancing off, each ALB node splits its traffic only among targets in its own AZ, so an AZ with few targets gets overloaded. Turning cross-zone back on at the target group level spreads requests across all healthy targets.

• AWith cross-zone load balancing on, each load balancer node spreads its traffic across registered targets in all enabled AZs, so uneven target counts per AZ no longer create hot spots. For ALBs it is always on at the load balancer level but can be turned off per target group, which is what caused this imbalance.
• BThe routing algorithm only picks among targets the node is allowed to use. With cross-zone off, each node still sends its share only to targets in its own AZ, so the small AZ stays overloaded.
• CSlow start only ramps up traffic to newly registered targets. It does not change how much traffic each AZ's targets get.
• DStickiness pins clients to targets and can make imbalance worse. It does nothing about each node being limited to its own AZ's targets.

Answer: A) Enable distributed tracing to AWS X-Ray across the request path and review the trace map and segment timings

Use distributed tracing to find which part of a request that crosses several services is slow. X-Ray traces, which can be sent through OpenTelemetry instrumentation, show the time spent in each segment. Flow logs, CloudTrail and CPU alarms don't give per-request timing.

• ACorrect. X-Ray collects data about each request, including the calls it makes to downstream services and databases. The trace map and per-segment timings show where the time is spent, which identifies bottlenecks and latency spikes. AWS now recommends sending the traces with OpenTelemetry-based instrumentation such as AWS Distro for OpenTelemetry.
• BIncorrect. Flow logs record IP traffic metadata to and from network interfaces. They don't show how long each application call within a request takes.
• CIncorrect. CloudTrail records account activity and API calls for auditing and governance. It doesn't give a per-request timing breakdown across the services in the path.
• DIncorrect. CPU alarms only show resource saturation in individual components, and those metrics already look normal. They can't show which hop in a distributed request adds the latency.

Answer: A) Enable enhanced fan-out, giving each registered consumer its own dedicated 2 MB/s per shard with push delivery and lower latency

• AEnhanced fan-out removes read contention: each consumer gets a dedicated throughput pipe per shard instead of sharing the standard GetRecords limit.
• BFewer shards reduces total capacity and worsens contention.
• CRetention affects how long records are replayable, not read throughput per consumer.
• DThat couples independent applications together and isn't always feasible.

Answer: A) Put an AWS Global Accelerator accelerator in front of both Network Load Balancers as endpoints

For non-HTTP TCP/UDP traffic that needs static IPs, lower latency over the AWS global network and fast regional failover, AWS Global Accelerator fits. CloudFront is for HTTP/HTTPS content, and Route 53 routing doesn't move traffic off the public internet.

• AGlobal Accelerator provides static anycast IP addresses and accepts TCP and UDP traffic at the nearest edge location. It then carries the traffic over the AWS global network to the closest healthy regional endpoint, which reduces latency and jitter. It also reroutes traffic quickly when an endpoint fails.
• BCloudFront does speed up dynamic content over the AWS network, but it serves content over HTTP/HTTPS. It can't carry a custom TCP protocol. AWS recommends Global Accelerator for non-HTTP use cases and for HTTP cases that need static IPs or fast regional failover.
• CLatency-based routing only picks a Region through DNS. Traffic still crosses the public internet to the load balancer, and the load balancer IPs aren't a small fixed set. Failover also depends on clients refreshing cached DNS records.
• DS3 Transfer Acceleration speeds up data transfers to and from S3 buckets through edge locations. It can't front a custom TCP API running on EC2 behind load balancers.

Answer: A) Run it on EC2 Spot Instances via a Spot Fleet / Auto Scaling group with multiple instance types and AZs

• ADiversifying across instance types and pools maximizes access to spare Spot capacity at large discounts; the workload's checkpoint/resume ability tolerates the occasional interruption.
• BOne instance is slow for thousands of parallel tasks and pays full price.
• CRIs suit steady long-running usage, not a burst of parallel batch work.
• DA single Lambda can't run thousands of long compute-heavy tasks; it also has a 15-minute limit.

Answer: A) Moving to AWS Graviton (ARM-based) instance types

• AGraviton instances typically deliver better price-performance for many scale-out and CPU-bound workloads; most open-source Linux stacks run on ARM with a rebuild of native components.
• BThat raises cost and doesn't necessarily improve price-performance.
• CChanging OS adds licensing cost and effort and doesn't inherently improve price-performance.
• DA steady CPU-bound service on always-on Lambda at max memory is usually more expensive than right-sized instances.

Answer: A) Change the cache policy so that the cache key includes only the lang query string, with no cookies or headers

A low hit ratio caused by a fragmented cache key is fixed in the cache policy: include only the query strings, cookies, and headers that change the response. Origin request policies and Origin Shield don't change the cache key.

• ACloudFront caches a separate object for every combination of values in the cache key. Because a unique session cookie is in the key, every request is a miss. Including only the value that actually changes the response lets identical responses be shared across viewers.
• BOrigin Shield adds a caching layer that consolidates requests from regional edge caches. It uses the same cache key, though, so a unique session cookie still makes every request a miss. AWS also notes that Origin Shield is a poor fit for content with low cacheability.
• COrigin request policies control what goes in origin requests, not the cache key. The cache key is set by the cache policy, and everything in the cache key is automatically included in origin requests anyway. The fragmentation stays the same.
• DAn origin group provides failover when the primary origin returns errors. It improves availability but doesn't change the cache key or how often cached responses are reused.

Answer: A) Amazon Aurora Serverless v2

• AAurora Serverless v2 scales compute (ACUs) up and down in fine-grained steps in response to load, ideal for spiky or intermittent workloads while remaining Aurora-compatible.
• BThat pays for peak capacity 24/7 even during long idle periods — wasteful and not 'automatic'.
• CDynamoDB scales well but is NoSQL; it doesn't satisfy a requirement for a relational database.
• DManual resize involves downtime and is too slow for sudden, unpredictable spikes.

Answer: A) Accelerated computing instances, such as G5 or G6, sized to the model

When a deep-learning model is limited by highly parallel floating-point math, accelerated computing instances (GPU-based G instances such as G5/G6) give much higher inference throughput and lower latency than CPU-only compute, burstable, or storage optimized instances.

• AAccelerated computing instances use hardware accelerators such as GPUs to handle floating-point work more efficiently than software running on CPUs. AWS positions G5 instances for high-performance ML inference, so this choice speeds up the matrix-heavy model the most.
• BCompute optimized instances suit CPU-bound work such as batch processing and media transcoding. Adding more CPU cores is less efficient than accelerator hardware for highly parallel deep-learning matrix math.
• CBurstable instances are for workloads with a low CPU baseline and occasional spikes. Sustained, compute-heavy inference would keep them bursting constantly, and they have no hardware accelerators.
• DStorage optimized instances provide high local disk I/O. The bottleneck here is floating-point computation, not storage, so fast local NVMe storage would not help.

Answer: A) Amazon FSx for Windows File Server

• AFSx for Windows File Server provides fully managed SMB shares with NTFS ACLs, DFS namespaces, and AD integration — the natural fit for Windows/.NET workloads needing a shared file system.
• BEFS is NFS for Linux; it isn't a native Windows SMB file system with AD integration.
• CS3 is object storage and not a true SMB file system for a Windows application.
• DA standard EBS volume attaches to one instance and offers no SMB share semantics.