CCNA Design High-Performing Architectures Questions — Page 2 of 2

MCQmedium

A mobile game backend uses Amazon Aurora. The workload has many short-lived database connections from Lambda functions, causing connection storms. What should be added? The design must avoid adding custom operational scripts.

A.An internet gateway

B.S3 Select

C.RDS Proxy

D.A larger Route 53 hosted zone

AnswerC

RDS Proxy pools and manages database connections, improving scalability for serverless and bursty workloads.

Why this answer

RDS Proxy is the correct choice because it pools and shares database connections, reducing the overhead of establishing new connections for each Lambda invocation. This prevents connection storms by maintaining a persistent pool of connections to Aurora, which is ideal for short-lived, high-frequency connections from serverless functions like Lambda.

Exam trap

The trap here is that candidates might think adding more network resources (like an internet gateway or larger DNS zone) solves connection storms, when the real issue is connection management at the database layer, not network capacity.

How to eliminate wrong answers

Option A is wrong because an internet gateway provides internet access to a VPC and does not manage database connections or connection pooling. Option B is wrong because S3 Select is used to retrieve subsets of data from objects in S3 using SQL expressions, not for managing database connections. Option D is wrong because a larger Route 53 hosted zone increases the number of DNS records you can host but does not affect database connection management or pooling.

Practice this question →

MCQmedium

A marketing team uses CloudFront with an S3 origin to serve a single-page web app. After a release, CloudFront cache hit ratio dropped sharply. The app requests the same static JS and CSS assets, but each request includes a unique tracking query parameter (for example, ?utm_source=campaign123, campaign456, etc.). You want CloudFront to cache those assets efficiently even when the tracking query parameter changes. What should you do?

A.Create a cache policy that forwards the query string to the origin and varies the cache key by all query parameters.

B.Update the CloudFront cache policy so the cache key ignores the tracking query parameter, while still using the path and other essential headers.

C.Enable S3 origin access control and keep the existing default cache policy, because origin access changes caching behavior automatically.

D.Set the CloudFront Time-to-Live (TTL) to 0 seconds to ensure the origin always serves the latest asset content.

AnswerB

CloudFront caching depends on the cache key (for example, path, selected headers, and selected query strings). If you configure a cache policy to exclude the tracking query parameter (or ignore specific query string parameters), CloudFront treats requests for the same asset as the same cached object. This prevents cache fragmentation caused by unique tracking values. Origin load decreases and cache hit ratio increases, while correctness is maintained because the excluded parameter does not affect the content of the static JS/CSS objects.

Why this answer

CloudFront's cache key determines whether a request is served from the cache or forwarded to the origin. By configuring a cache policy that ignores the tracking query parameter (e.g., utm_source), CloudFront treats all requests for the same asset path as identical, regardless of the unique tracking parameter. This allows the same JS and CSS files to be cached once and served for all campaign variations, restoring the cache hit ratio.

Exam trap

The trap here is that candidates may think forwarding all query parameters (Option A) is necessary for dynamic content, but for static assets with irrelevant tracking parameters, ignoring them is the correct approach to maximize cache hits.

How to eliminate wrong answers

Option A is wrong because forwarding the query string and varying the cache key by all query parameters would create a separate cache entry for each unique utm_source value, which is exactly the problem causing the cache hit ratio to drop. Option C is wrong because enabling S3 origin access control (OAC) only secures the origin and does not affect CloudFront's caching behavior or cache key configuration. Option D is wrong because setting TTL to 0 seconds forces CloudFront to revalidate every request with the origin, eliminating caching entirely and worsening performance, not improving cache efficiency.

Practice this question →

MCQeasy

A travel booking site uses EC2 instances behind an ALB. CPU is consistently high during peak traffic, and request latency rises. What should be configured?

A.A VPC endpoint for CloudWatch only

B.Auto Scaling policy based on an appropriate CloudWatch metric

C.S3 Object Lock

D.Disable health checks

AnswerB

Auto Scaling adds capacity when load increases and removes it when load falls.

Why this answer

An Auto Scaling policy based on a CloudWatch metric like CPUUtilization or request latency directly addresses the root cause: rising CPU and latency under peak traffic. By automatically adding EC2 instances when the metric breaches a threshold, the ALB can distribute load across more resources, reducing CPU per instance and improving response times. This is the standard AWS solution for dynamic scaling to maintain performance.

Exam trap

The trap here is that candidates may confuse monitoring (VPC endpoints) or data protection (S3 Object Lock) with scaling solutions, or think disabling health checks reduces overhead, when the correct approach is to scale horizontally based on load metrics.

How to eliminate wrong answers

Option A is wrong because a VPC endpoint for CloudWatch only enables private connectivity to CloudWatch without internet gateway, but does not add compute capacity or reduce CPU load or latency. Option C is wrong because S3 Object Lock prevents object deletion or overwrite for compliance, which is irrelevant to EC2 CPU and latency issues. Option D is wrong because disabling health checks would cause the ALB to route traffic to unhealthy instances, increasing failures and latency, not solving the performance problem.

Practice this question →

MCQhard

Based on the exhibit, a single EC2 instance hosts a latency-sensitive cache that performs sustained random reads and writes to persistent block storage. The current EBS volume is a general-purpose SSD, but BurstBalance is repeatedly depleted and p95 I/O latency has risen above 20 ms. The workload needs more than 16,000 sustained IOPS. Which change is the best fix?

A.Move the data to Amazon S3 so the instance can read and write objects directly.

B.Replace the volume with an io2 EBS volume and provision the required IOPS.

C.Keep gp2 and increase the instance size to a compute-optimized family.

D.Enable Amazon EFS with bursting throughput mode for the cache data.

AnswerB

io2 is designed for mission-critical workloads that need sustained, predictable, low-latency random I/O. Unlike gp2, it does not depend on burst credits for performance. Provisioning the required IOPS directly addresses the exhausted BurstBalance and the sustained throughput requirement above 16,000 IOPS.

Why this answer

The workload requires more than 16,000 sustained IOPS with low latency, and the gp2 volume's burst credits are exhausted, causing high latency. An io2 Block Express or io2 volume can be provisioned with the exact IOPS needed (up to 256,000 IOPS) and provides consistent single-digit millisecond latency, making it the best fix for this latency-sensitive, sustained I/O workload.

Exam trap

The trap here is that candidates often assume increasing instance size (Option C) will improve EBS performance, but EBS IOPS and throughput are tied to the volume type and size, not the instance type (except for EBS-optimized bandwidth), so the gp2 burst credit exhaustion remains the root cause.

How to eliminate wrong answers

Option A is wrong because Amazon S3 is object storage accessed via HTTPS, not block storage, and introduces network latency and throughput limitations that are unsuitable for a latency-sensitive cache requiring sustained random reads/writes. Option C is wrong because increasing the instance size to a compute-optimized family does not change the gp2 volume's burst credit model; the volume will still deplete its burst balance and throttle to baseline IOPS (e.g., 160 IOPS per GB), failing to meet the >16,000 sustained IOPS requirement. Option D is wrong because Amazon EFS is a shared file system with NFS protocol overhead and its bursting throughput mode relies on burst credits that can be exhausted, leading to throttled throughput and higher latency, not suitable for sustained high IOPS block-level cache workloads.

Practice this question →

Multi-Selecthard

Multiple EC2 instances in different Availability Zones need concurrent read/write access to the same shared files. The files are actively modified by several application servers, and low-latency metadata operations matter more than extremely high aggregate throughput. Which two changes should the team make? Select two.

Select 2 answers

A.Use Amazon EFS instead of EBS or S3 for the shared file system.

B.Create EFS mount targets in every Availability Zone that hosts application instances.

C.Use a single EBS Multi-Attach volume mounted read/write by all instances across AZs.

D.Store the files in S3 and mount them directly through the console as a shared network filesystem.

E.Place the files on instance store volumes so each server has faster local access.

AnswersA, B

Amazon EFS is the managed AWS file service built for shared POSIX-style file access from multiple instances. It supports concurrent read/write access from many EC2 hosts and is a better fit than EBS, which is attached to a single instance, or S3, which provides object storage rather than a native shared filesystem. For an application that expects standard filesystem semantics, EFS is the correct storage layer.

Why this answer

Amazon EFS provides a fully managed, POSIX-compliant, shared file system that can be mounted concurrently by multiple EC2 instances across different Availability Zones (AZs). It supports concurrent read/write access with strong consistency, and its metadata operations are optimized for low latency, making it ideal for workloads where many application servers actively modify the same files. EBS cannot be shared across AZs, and S3 lacks POSIX semantics and low-latency metadata operations.

Exam trap

The trap here is that candidates often confuse EBS Multi-Attach with a cross-AZ shared storage solution, but Multi-Attach is strictly limited to a single AZ and a small number of instances, while EFS is the only AWS shared file system that natively spans AZs with concurrent read/write access.

Practice this question →

MCQeasy

A company serves mostly static images and JavaScript files from an origin in one AWS Region. They want to reduce origin load and improve global performance. Which change most directly increases cache-hit ratio for static assets while avoiding stale content?

A.Set Cache-Control headers on the origin to always be no-cache so clients revalidate frequently.

B.Use versioned file names (e.g., app.abc123.js) and configure a long TTL with appropriate revalidation behavior.

C.Disable query string forwarding so all URLs without query strings share one cached object even when content differs.

D.Forward all headers, including cookies, to maximize personalization in edge cached responses.

AnswerB

Versioned assets allow long caching with confidence, while new filenames trigger updates when code changes.

Why this answer

Using versioned file names (e.g., app.abc123.js) allows you to set a long Cache-Control max-age TTL (e.g., one year) without risking stale content. When the file changes, the new version gets a new URL, so clients and edge caches immediately fetch the fresh object, maximizing cache hits for unchanged assets while avoiding stale content.

Exam trap

The trap here is that candidates often confuse 'no-cache' with 'no-store' or think that disabling query strings universally improves caching, but they fail to recognize that versioned filenames with long TTLs are the standard pattern for maximizing cache hits while ensuring content freshness.

Why the other options are wrong

Setting Cache-Control: no-cache forces clients to revalidate with the origin on every request, which increases origin load and defeats caching, directly contradicting the goal of reducing origin load and improving performance.

Disabling query string forwarding causes all URLs without query strings to be treated as identical, even if the underlying content differs (e.g., different versions of a file). This can serve stale or incorrect content, reducing cache-hit ratio for static assets that rely on query parameters for versioning.

Forwarding all headers, including cookies, reduces cache-hit ratio because each unique set of headers creates a separate cached object, defeating the purpose of caching static assets that don't vary by user.

Practice this question →

MCQmedium

A DynamoDB table uses this schema: partition key = customerId, sort key = timestamp. During a marketing campaign, one customer generates extremely high read traffic and the application sees ProvisionedThroughputExceeded errors even though the table’s total capacity is sufficient. What change most directly improves read distribution across partitions?

A.Increase the table’s provisioned read capacity units while keeping partition key = customerId.

B.Add a salt component to the partition key by changing it to customerId#salt, where salt is derived from a hash of requestId so a single customer’s requests are spread across many partitions; keep the sort key as timestamp.

C.Remove the sort key and use timestamp as the partition key to increase cardinality.

D.Switch to on-demand capacity and rely on DynamoDB to automatically distribute reads across partitions.

AnswerB

Hot partition throttling usually occurs when too many requests target a single partition key value. Salting transforms the partition key so that one high-traffic customerId maps to multiple distinct partition keys (e.g., customerId#0, customerId#1, etc.), which increases the number of partitions that can serve that customer’s workload concurrently and reduces the probability that a single partition becomes overloaded.

Why this answer

Adding a salt to the partition key (e.g., customerId#hash(requestId)) distributes the read-heavy customer's data across multiple physical partitions. This prevents a single hot partition from throttling requests, even when the table's total provisioned capacity is sufficient. DynamoDB's partition key determines the internal hash used for data placement, so increasing partition key cardinality directly improves read distribution.

Exam trap

The trap here is that candidates confuse total table capacity with per-partition capacity, assuming that increasing RCUs or switching to on-demand will fix throttling caused by a hot key, when in reality the bottleneck is the single partition's throughput limit.

Why the other options are wrong

Increasing read capacity units does not address the root cause: a single hot partition. The total capacity may be sufficient, but all reads for the hot customer hit the same partition, causing throttling at that partition level.

Changing the partition key to timestamp would cause all reads for a given time range to hit a single partition, creating a hot key and worsening the distribution issue, not solving it.

On-demand capacity handles throughput spikes but does not address the root cause: a single hot partition. The ProvisionedThroughputExceeded errors occur because one customer's data is concentrated on one partition, and on-demand capacity does not redistribute data across partitions.

Practice this question →

MCQmedium

A document portal requires consistent high IOPS for a transactional database on EC2. Which EBS volume type is most suitable?

A.sc1 Cold HDD

B.Instance store only

C.Provisioned IOPS SSD such as io2

D.st1 Throughput Optimized HDD

AnswerC

io2 is designed for business-critical workloads requiring consistent high IOPS and durability.

Why this answer

Provisioned IOPS SSD (io2) is the correct choice because it delivers consistent, high IOPS performance required for transactional databases running on EC2. io2 volumes offer a 99.999% durability and can sustain up to 256,000 IOPS per volume, making them ideal for latency-sensitive workloads like OLTP databases.

Exam trap

The trap here is that candidates often confuse 'high IOPS' with 'high throughput' and select st1 or sc1, not realizing that transactional databases require low-latency random I/O, which only SSD-based volumes like io2 can consistently deliver.

How to eliminate wrong answers

Option A is wrong because sc1 Cold HDD is designed for infrequently accessed, throughput-oriented workloads with low cost, and cannot provide consistent high IOPS due to its burst-bucket model and high latency. Option B is wrong because instance store volumes are ephemeral and data is lost on instance stop/termination, making them unsuitable for persistent transactional databases that require durability and consistent IOPS. Option D is wrong because st1 Throughput Optimized HDD is optimized for large, sequential workloads like big data and log processing, not for random I/O patterns typical of transactional databases, and its performance is limited to a maximum of 500 IOPS per volume.

Practice this question →

MCQmedium

A global video platform serves mostly static images and JavaScript files from an S3 origin. Users in distant countries report slow load times. What should improve performance most?

A.A larger S3 bucket

B.Amazon CloudFront distribution with the S3 bucket as origin

C.RDS read replicas

D.An EC2 Auto Scaling group in one Region

AnswerB

CloudFront caches content at edge locations close to users, reducing latency.

Why this answer

Amazon CloudFront is a content delivery network (CDN) that caches static content (images, JavaScript) at edge locations worldwide. By distributing content closer to users, it reduces latency and improves load times significantly compared to serving directly from a single S3 origin. This is the most effective solution for a global user base accessing static assets.

Exam trap

The trap here is that candidates might confuse 'scaling' (Auto Scaling, larger buckets) with 'latency reduction' (CDN), or mistakenly think database read replicas can serve static web assets, when in fact they are only for relational database read offloading.

How to eliminate wrong answers

Option A is wrong because S3 bucket size has no impact on performance; S3 scales automatically to handle any amount of data, and a larger bucket does not reduce latency for distant users. Option C is wrong because RDS read replicas are designed to offload read traffic from a relational database, not to serve static files like images or JavaScript; they address database query performance, not content delivery. Option D is wrong because an EC2 Auto Scaling group in one Region only scales compute capacity within that single geographic area, failing to reduce latency for users in distant countries who still must traverse long network paths.

Practice this question →

MCQhard

Based on the exhibit, what change should the team make to achieve the lowest possible network latency for the distributed workload?

A.Place the instances in a spread placement group across multiple Availability Zones.

B.Move the workload into a cluster placement group in one Availability Zone.

C.Add an Application Load Balancer in front of the workers to reduce inter-node latency.

D.Increase the EC2 instance size while keeping the current multi-AZ layout.

AnswerB

Cluster placement groups place instances physically close together inside one Availability Zone, which is the best AWS option for workloads that need low-latency, high-bandwidth communication between many nodes. The exhibit explicitly says the workload can run in a single AZ if performance improves. That makes cluster placement groups the right fit.

Why this answer

A cluster placement group provides the lowest possible network latency and highest throughput by placing all instances in a single Availability Zone with low-latency, non-blocking 10 Gbps or 25 Gbps network connectivity between them. This is ideal for tightly coupled, distributed workloads that require frequent inter-node communication, such as HPC or data analytics jobs.

Exam trap

The trap here is that candidates often assume multi-AZ is always better for high availability, but for latency-sensitive distributed workloads, a single-AZ cluster placement group is the correct choice to minimize inter-node latency, even though it sacrifices fault tolerance.

Why the other options are wrong

Spread placement groups maximize availability and fault isolation by placing instances on distinct hardware across multiple AZs, which increases network latency due to physical separation. The goal is lowest possible latency, which requires a cluster placement group in a single AZ.

An Application Load Balancer distributes incoming traffic across targets, but it does not reduce inter-node latency between workers; in fact, it adds a hop and increases latency for node-to-node communication.

Increasing EC2 instance size does not reduce network latency between instances; it improves compute capacity. The question specifically asks for lowest network latency, which requires physical proximity, not larger instances.

Practice this question →

MCQmedium

Your mobile app writes events to a single DynamoDB table with partition key = customerId and sort key = eventTime. During a promotional campaign, one tenant ("ACME") generates far more traffic than others. CloudWatch shows sustained throttling (ProvisionedThroughputExceeded) and elevated p99 latency only for that tenant. The workload pattern cannot be changed to a completely different schema, but you can change how items are partitioned. Which design change is most likely to reduce the hot-partition throttling while keeping efficient reads for ACME?

A.Use the same partition key (customerId), but increase the table’s provisioned capacity for that tenant.

B.Change the partition key to a salted key such as customerId + shard number, and include the eventTime ordering using the sort key.

C.Switch to on-demand capacity mode and keep the partition key unchanged.

D.Enable Global Tables so that reads are served from a nearby replica for ACME.

AnswerB

Hot-partition throttling happens when a single logical partition (one partition key value) receives more requests than it can serve. By salting the partition key (for example, customerId#shardId), ACME’s writes are spread across multiple physical partitions, reducing request rate per partition and lowering throttling. Efficient reads for ACME can be preserved by querying only the shard partitions that belong to ACME (for example, using a small, deterministic set of shardIds and issuing parallel queries per shard, then merging results). This avoids scanning the whole table and keeps access patterns predictable while improving tail latency.

Why this answer

Salting the partition key by appending a shard number (e.g., customerId + random digit) distributes ACME's writes across multiple partitions, eliminating the hot partition. The sort key still preserves eventTime ordering, so queries for a specific customer can be parallelized across shards and merged client-side or via a composite sort key pattern, maintaining efficient reads.

Exam trap

The trap here is that candidates assume increasing capacity or switching to on-demand alone solves hot partitions, but they overlook DynamoDB's fixed per-partition throughput limits that require key design changes to distribute load.

How to eliminate wrong answers

Option A is wrong because increasing provisioned capacity for a single tenant does not solve the hot-partition issue; DynamoDB distributes capacity across partitions, and a single partition's throughput is capped at 3,000 RCU or 1,000 WCU regardless of table-level settings. Option C is wrong because switching to on-demand capacity mode only handles traffic spikes at the table level, but a single hot partition still hits the same per-partition throughput limits (3,000 RCU/1,000 WCU), causing throttling. Option D is wrong because Global Tables replicate data across regions for low-latency reads and disaster recovery, but they do not redistribute write load within a single table; ACME's writes still target the same partition key in the source region, so throttling persists.

Practice this question →

MCQmedium

An Aurora PostgreSQL cluster is experiencing high read latency because 85% of traffic consists of read-only queries. The write workload must stay on the writer instance, and the team wants to offload reads without changing the application’s core query patterns. What is the best architectural option?

A.Increase the writer instance size so it can handle more reads and writes simultaneously.

B.Add Aurora reader instances (read replicas) and route read queries to the reader endpoint while keeping writes on the writer endpoint.

C.Enable Multi-AZ failover only and rely on the standby to serve reads in normal operation.

D.Move the read workload to ElastiCache Redis while keeping DynamoDB as the SQL data source.

AnswerB

Aurora reader instances are designed for exactly this pattern: they provide dedicated compute capacity for read-only workloads. By sending read queries to the reader endpoint and keeping writes on the writer endpoint, the cluster can scale read performance without forcing reads to contend with write processing on the writer.

Why this answer

Adding Aurora reader instances (read replicas) and routing read queries to the reader endpoint offloads read traffic from the writer instance without altering application query patterns. Aurora reader endpoints automatically distribute read-only connections across all replicas, reducing latency on the writer while keeping writes on the writer instance. This directly addresses the 85% read-heavy workload without requiring application changes.

Exam trap

The trap here is that candidates often confuse Multi-AZ standby instances (which are passive and cannot serve reads) with Aurora reader replicas (which are active and can serve reads), leading them to incorrectly select Option C.

Why the other options are wrong

Increasing the writer instance size does not offload reads; it only scales the single writer instance, which still handles all read traffic and does not reduce read latency from high read concurrency.

In Aurora, a Multi-AZ standby (writer failover target) does not serve read traffic; it is only used for failover. To offload reads, you need dedicated reader instances with a separate reader endpoint.

Option D is wrong because it suggests using ElastiCache Redis with DynamoDB as the SQL data source, but the question specifies an Aurora PostgreSQL cluster. DynamoDB is a NoSQL database, not a SQL data source, and this approach would require significant application changes to query patterns, violating the constraint of not changing core query patterns.

Practice this question →

MCQmedium

An event ingestion service writes to a DynamoDB table where the partition key is tenantId and the sort key is eventTime. During a campaign, one tenant generates a disproportionate share of traffic, causing write throttling and increased latency for that tenant’s writes. You can change the data model and application queries, but you must still efficiently retrieve events for a tenant for the last 10 minutes. Which change best improves write throughput by reducing hot partitions?

A.Keep tenantId as the partition key and rely on DynamoDB adaptive capacity to automatically remove all throttling.

B.Add a shard attribute to the partition key (partition key = tenantId#shard, where shard is randomly selected from a fixed range). Query all shards for the tenant for eventTime values in the last 10 minutes, then merge results in the application.

C.Change the sort key to eventTimeBucket (for example, eventTime rounded to 1-minute buckets) while keeping the partition key as tenantId.

D.Enable DAX and use it for write operations so throttled writes are served from cache instead of reaching DynamoDB.

AnswerB

This “write sharding” spreads a tenant’s traffic across multiple partition key values, which distributes the write load across multiple DynamoDB partitions (and thus multiple throughput slices). Reads for the last 10 minutes remain efficient because each shard still supports a sort-key range query on eventTime; the application merges results across shards.

Why this answer

It distributes writes for a hot tenant across multiple partitions by appending a random shard suffix to the tenantId partition key. This eliminates a single hot partition, allowing DynamoDB to scale write capacity horizontally. The application can then query all shards for the last 10 minutes and merge results, satisfying the retrieval requirement.

Exam trap

The trap here is that candidates assume adaptive capacity or caching (DAX) can solve write throttling, but neither addresses the root cause—a single partition exceeding its write capacity—which requires redistributing the partition key across multiple physical partitions.

How to eliminate wrong answers

Option A is wrong because DynamoDB adaptive capacity can only mitigate moderate hot spots by temporarily allocating extra capacity, but it cannot eliminate throttling when a single partition exceeds its 1,000 WCU or 3,000 RCU limit; sustained high traffic from one tenant will still cause throttling. Option C is wrong because changing the sort key to eventTimeBucket does nothing to distribute writes across partitions—the partition key remains tenantId, so all writes for that tenant still target the same partition, leaving the hot partition problem unsolved. Option D is wrong because DAX is a read-through cache and does not handle write operations; throttled writes are not served from cache, and DAX cannot increase write throughput or reduce hot partition contention.

Practice this question →