A company is building a new web platform where user requests trigger an AWS Lambda function that performs an insert into an Amazon Aurora MySQL DB cluster. Initial tests with less than 10 users on…

Question

Options

• AEdit the my.cnf file for the DB cluster to increase max_connections
• BIncrease the instance size of the DB cluster
• CChange the DB cluster to Multi-AZ
• DIncrease the number of Aurora Replicas

• A
  9% (3)
• B
  73% (24)
• C
  15% (5)
• D
  3% (1)

Explanation

Explanation

Increasing the instance size of the Aurora MySQL DB cluster is the correct solution because Aurora's max_connections limit is automatically determined by the instance's memory (RAM) - larger instance classes have more memory, which directly allows a higher maximum connection count, resolving the "too many connections" error at scale.

Why the distractors are wrong:

• A is incorrect because Aurora MySQL does not use a my.cnf file for configuration; parameters are managed through DB Parameter Groups, and even then, max_connections in Aurora is tied to instance memory, not a simple config file edit.
• C is incorrect because Multi-AZ improves availability and failover, not connection limits - it doesn't increase the number of connections the primary instance can accept.
• D is incorrect because Aurora Replicas handle read traffic only; Lambda insert operations write to the primary instance, so adding replicas doesn't help with write connection limits.

Memory Tip: Think "Bigger box = more connections" - in Aurora MySQL, max_connections ≈ instance memory / connection overhead. When you hit connection limits under load, sizing up the instance is the lever to pull. For production workloads, also remember RDS Proxy as a connection pooling solution (a common exam alternative answer).

No community discussion yet for this question.