SOA-C02 Deployment, Provisioning, and Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create a target tracking scaling policy that uses the custom metric as a target.

  Why this is correct

  With a target tracking scaling policy, you first publish a custom metric to CloudWatch (for example, ActiveUserSessions) and then define the policy with a target value such as 1000 sessions per instance. Amazon EC2 Auto Scaling continuously computes the required capacity to keep the metric near that target, proactively adding or removing instances without static thresholds or manually tuned cooldowns. This makes it ideal for a dynamic, session-based workload where the relationship between load and capacity is stable and predictable.

• ✗

  Create a step scaling policy that adjusts capacity based on the magnitude of the metric breach.

  Why it's wrong here

  Step scaling policies are unsuitable for this scenario as they adjust capacity in discrete steps when specific thresholds are breached, rather than proactively maintaining a desired target value for the custom metric. The requirement is for continuous optimisation based on the number of active user sessions. However, step scaling is tempting because it does allow scaling based on custom metrics and is ideal for scenarios needing varied responses to different magnitudes of a metric breach, such as adding more instances for larger deviations.

• ✗

  Create a scheduled scaling policy that increases capacity during peak hours.

  Why it's wrong here

  Scheduled scaling relies on predetermined time patterns (for example, adding capacity every weekday at 9:00 AM) and cannot react to real-time fluctuations in user sessions. If an unexpected traffic spike occurs outside the scheduled window, or if the actual peak hours shift, the Auto Scaling group will either be under-provisioned during the surge or over-provisioned when demand is low. Because the organization's requirement is to scale automatically based on the actual custom metric, a scheduled policy does not satisfy the stated need and is not a valid substitute for metric-driven scaling.

• ✗

  Create a simple scaling policy that adds instances when the custom metric exceeds a threshold and removes when below.

  Why it's wrong here

  A simple scaling policy adjusts capacity by a fixed number (or fixed percentage) of instances whenever a CloudWatch alarm breaches a static threshold, then enters a cooldown period that prevents further changes until that period elapses. This creates a slow, reactive loop: for example, if sessions are climbing steadily, simple scaling adds a fixed batch, then waits through cooldown, allowing the metric to drift far from the desired level before the next adjustment. Unlike target tracking, it cannot continuously recalculate the exact capacity needed to hold the custom metric at a chosen target, so it is not well suited to maintaining a specific sessions-per-instance ratio.

Go deeper

Related to this question