Auto Scaling Groups: Managing Your EC2 Fleet Efficiently Quiz

Explore essential concepts of auto scaling groups in cloud computing, focusing on how EC2 fleets automatically adjust to demand. This quiz reviews scaling policies, group configurations, and best practices to optimize resource usage and uptime.

1. Purpose of Auto Scaling Groups

   What is the primary purpose of an auto scaling group for EC2 instances in a cloud environment?

   1. Automatically adjusts the number of instances based on demand
   2. Schedules server maintenance
   3. Maintains a static number of instances at all times
   4. Increases data encryption on servers

   Explanation: The main function of an auto scaling group is to increase or decrease the number of instances as needed to meet demand. This helps ensure availability and cost efficiency. Increasing data encryption refers to a security measure, not scaling. Maintaining a static number ignores changing requirements. Scheduling maintenance is a different management task.

2. Minimum Size Setting

   When configuring an auto scaling group, what does the minimum size parameter define?

   1. The smallest disk size for each instance
   2. The least number of instances to keep running at any time
   3. The minimum number of users allowed
   4. The lowest network bandwidth required

   Explanation: Minimum size sets a baseline, ensuring a minimum number of instances are always running. Disk size and network bandwidth are unrelated to this parameter. The number of users allowed is a separate concern handled by application logic, not scaling groups.

3. Scaling Policy Example

   If your application's CPU load often exceeds 80%, which scaling policy would help maintain performance?

   1. Add one instance when average CPU load goes above 80%
   2. Add storage when CPU load is high
   3. Send alerts but do not change instance count
   4. Reduce the group’s minimum size

   Explanation: Adding an instance helps handle increased load, which maintains performance. Adding storage may not address CPU load issues. Sending alerts is helpful for monitoring but does not fix the problem automatically. Reducing the minimum size could make things worse by lowering resources.

4. Desired Capacity Meaning

   What does the desired capacity specify in an auto scaling group configuration?

   1. The preferred network port for traffic
   2. Maximum storage size for the group
   3. Desired billing limit per month
   4. The preferred number of running instances at any given time

   Explanation: Desired capacity reflects how many instances you ideally want running, and the auto scaling group works to maintain this number. Storage size, billing limits, and choosing a network port are managed elsewhere and are not controlled by the desired capacity setting.

5. Health Check Actions

   What action does an auto scaling group typically take when it detects an unhealthy instance?

   1. Changes the server's IP address
   2. Terminates the unhealthy instance and launches a replacement
   3. Disables monitoring for the instance
   4. Increases the maximum instance size

   Explanation: Upon detecting an issue, the group removes the bad instance and starts a new one to maintain service. Changing the IP address or increasing size doesn't resolve unhealthy instance problems. Disabling monitoring would likely hide rather than fix the issue.

6. Scaling Event Trigger

   Which of the following metrics could trigger a scaling out event in an auto scaling group?

   1. User password expiration
   2. Average CPU utilization above a certain percentage
   3. Disk encryption status
   4. Number of open help desk tickets

   Explanation: High CPU usage is a common metric to trigger scaling since it reflects resource strain. Password expiration and help desk tickets are user and support related, not infrastructure performance. Disk encryption status affects security, not load-based scaling.

7. Maximum Size Impact

   What happens if an auto scaling group reaches its maximum size setting during a high demand period?

   1. All instances are switched to larger hardware
   2. No additional instances are launched beyond the maximum size
   3. Oldest instances are automatically terminated
   4. The group automatically increases the maximum size limit

   Explanation: Once the maximum is reached, no more instances are added, which helps control costs and resource usage. The group cannot increase its own maximum automatically. Terminating oldest instances or switching hardware do not address scaling constraints.

8. Launch Template Selection

   Why is a launch template or launch configuration necessary when creating an auto scaling group?

   1. It defines how new instances are configured and started
   2. It schedules system backups each hour
   3. It encrypts network traffic between instances
   4. It sets the domain name for the group

   Explanation: A launch template provides needed details like image, instance type, and security rules for new instances. Network encryption, domain name setup, and backup scheduling are managed elsewhere, not by the launch template.

9. Instance Distribution Strategy

   What is the benefit of using multiple availability zones in an auto scaling group?

   1. Improves reliability and reduces risk of single-zone failures
   2. Disables health checks automatically
   3. Prevents users from accessing the service
   4. Doubles the processing power of each instance

   Explanation: Distributing instances across zones improves resilience in case one zone faces issues. It does not increase instance power or disable important features. Preventing user access contradicts the purpose of scaling and reliability.

10. Scaling In Action

    What does a 'scaling in' event do in the context of an auto scaling group?

    1. Adds new instances for increased capacity
    2. Upgrades all instances to a newer version
    3. Reduces the number of running instances when demand drops
    4. Switches from on-demand to reserved instances

    Explanation: Scaling in decreases the number of instances to save costs when fewer resources are needed. Adding instances is scaling out, not in. Switching billing types and upgrading software are separate operations unrelated to the scaling in concept.