A company has a memory-intensive application that runs on a fleet of Amazon EC2 instances behind an Elastic Load Balancer (ELB). The instances run in an Auto Scaling group. A SysOps administrator…

The correct answer is A. Create a scaling policy that will scale the application based on the ActiveConnectionCount. Option A is correct because ActiveConnectionCount is a built-in ELB metric that directly measures the number of users currently connected to the application - making it the most accurate and straightforward signal for scaling based on user load. Auto Scaling can use this…

Submitted by amina.ke· Mar 30, 2026Cost and Performance Optimization

Question

A company has a memory-intensive application that runs on a fleet of Amazon EC2 instances behind an Elastic Load Balancer (ELB). The instances run in an Auto Scaling group. A SysOps administrator must ensure that the application can scale based on the number of users that connect to the application. Which solution will meet these requirements?

Options

ACreate a scaling policy that will scale the application based on the ActiveConnectionCount
BCreate a scaling policy that will scale the application based on the mem_used Amazon
CCreate a scheduled scaling policy to increase the number of EC2 instances in the Auto Scaling
DCreate and deploy a script on the ELB to expose the number of connected users as a custom

How the community answered

(22 responses)

A
73% (16)
B
9% (2)
C
14% (3)
D
5% (1)

Explanation

Option A is correct because ActiveConnectionCount is a built-in ELB metric that directly measures the number of users currently connected to the application - making it the most accurate and straightforward signal for scaling based on user load. Auto Scaling can use this CloudWatch metric in a target tracking or step scaling policy without any custom instrumentation.

Why the distractors are wrong:

B is tempting given the "memory-intensive" context, but mem_used is not a default CloudWatch metric for EC2 - it requires installing the CloudWatch Agent and publishing a custom metric. The question asks for a solution that scales based on connected users, not memory pressure.
C (scheduled scaling) scales at predetermined times, not in response to actual user demand - it can't react dynamically to unexpected traffic spikes.
D involves writing and deploying a custom script on the ELB to expose connected users, which is unnecessary complexity when ActiveConnectionCount already exists as a native ELB metric.

Memory tip: When a question mentions an ELB and scaling based on user connections, think "ActiveConnectionCount" - it's the ELB metric that counts exactly that. The "memory-intensive" detail is a red herring designed to lure you toward B; always anchor on what the scaling trigger should be, not the app's resource profile.

Topics

#Auto Scaling#Elastic Load Balancer (ELB)#CloudWatch Metrics#Scalability

Community Discussion

No community discussion yet for this question.

Full SOA-C02 Practice