Topic 08 Practice Test 3 covers Elastic Scaling, Load Balancing, Containers, Serverless, and Microservices for AWS SAA-C03. For broader exam preparation, review the AWS SAA-C03 Exam Dumps. Every option includes focused technical reasoning explaining both the AWS architecture concept and its fit to the scenario.
Question 1
A new stateless service has a stable utilization signal but no reliable traffic schedule. The requirement is to let the scaling system calculate changes around the target value. Which design choice best satisfies this requirement? Choose ONE.
- EC2 Auto Scaling target tracking
- EC2 Auto Scaling scheduled scaling
- EC2 Auto Scaling predictive scaling
- Auto Scaling lifecycle hook
Correct Answer(s)
A
Rationale
- EC2 Auto Scaling target tracking provides metric driven desired capacity adjustment for a service needs proportional capacity changes without engineers defining every threshold step. The requested action is let the scaling system calculate changes around the target value. Because the evidence aligns with EC2 Auto Scaling target tracking, it aligns with this constraint.
- EC2 Auto Scaling scheduled scaling acts as time based capacity changes at known for a service needs proportional capacity changes without engineers defining every threshold step. The requested action is let the scaling system calculate changes around the target value. Under this evidence, EC2 Auto Scaling scheduled scaling does not match.
- EC2 Auto Scaling predictive scaling enables forecast based capacity planning from historical for a service needs proportional capacity changes without engineers defining every threshold step. The requested action is let the scaling system calculate changes around the target value. Under these conditions, EC2 Auto Scaling predictive scaling is not the remedy.
- Auto Scaling lifecycle hook controls pause instance launch or termination transitions for a service needs proportional capacity changes without engineers defining every threshold step. The requested action is let the scaling system calculate changes around the target value. For the required behavior, Auto Scaling lifecycle hook leaves the issue intact.
Question 2
A one-time campaign has a known launch window. The requirement is to schedule temporary desired-capacity changes around the event window. Which design choice best satisfies this requirement? Choose ONE.
- EC2 Auto Scaling target tracking
- EC2 Auto Scaling predictive scaling
- Auto Scaling warm pool
- EC2 Auto Scaling scheduled scaling
Correct Answer(s)
D
Rationale
- EC2 Auto Scaling target tracking supports metric driven desired capacity adjustment for a marketing event has a published start and end time and must have extra instances ready in advance. The requested action is schedule temporary desired-capacity changes around the event window. In this architecture, EC2 Auto Scaling target tracking does not satisfy it.
- EC2 Auto Scaling predictive scaling implements forecast based capacity planning from historical for a marketing event has a published start and end time and must have extra instances ready in advance. The requested action is schedule temporary desired-capacity changes around the event window. Under the scenario, EC2 Auto Scaling predictive scaling operates elsewhere.
- Auto Scaling warm pool serves as pre initialized instances kept near ready for a marketing event has a published start and end time and must have extra instances ready in advance. The requested action is schedule temporary desired-capacity changes around the event window. For this workload, Auto Scaling warm pool is the wrong control.
- EC2 Auto Scaling scheduled scaling functions as time based capacity changes at known for a marketing event has a published start and end time and must have extra instances ready in advance. The requested action is schedule temporary desired-capacity changes around the event window. Because the evidence aligns with EC2 Auto Scaling scheduled scaling, it resolves the stated need.
Question 3
Architects want to validate forecast quality without changing production capacity yet. The requirement is to run predictive scaling in forecast-only mode for evaluation. Which design choice best satisfies this requirement? Choose ONE.
- EC2 Auto Scaling target tracking
- EC2 Auto Scaling predictive scaling
- EC2 Auto Scaling scheduled scaling
- Auto Scaling warm pool
Correct Answer(s)
B
Rationale
- EC2 Auto Scaling target tracking offers metric driven desired capacity adjustment for the team wants forecast recommendations before enabling automated predictive changes. The requested action is run predictive scaling in forecast-only mode for evaluation. In the requested path, EC2 Auto Scaling target tracking cannot meet this need.
- EC2 Auto Scaling predictive scaling handles forecast based capacity planning from historical for the team wants forecast recommendations before enabling automated predictive changes. The requested action is run predictive scaling in forecast-only mode for evaluation. Because the evidence aligns with EC2 Auto Scaling predictive scaling, it fits this case.
- EC2 Auto Scaling scheduled scaling creates time based capacity changes at known for the team wants forecast recommendations before enabling automated predictive changes. The requested action is run predictive scaling in forecast-only mode for evaluation. Given this case, EC2 Auto Scaling scheduled scaling misses this case.
- Auto Scaling warm pool gives pre initialized instances kept near ready for the team wants forecast recommendations before enabling automated predictive changes. The requested action is run predictive scaling in forecast-only mode for evaluation. For this design, Auto Scaling warm pool targets another requirement.
Question 4
A platform team wants fault-domain diversity to persist during routine scaling. The requirement is to configure the group with multiple Availability Zone subnets. Which design choice best satisfies this requirement? Choose ONE.
- EC2 Auto Scaling target tracking
- ECS Availability Zone spread placement
- Multi-AZ Auto Scaling group
- ALB target groups and health checks
Correct Answer(s)
C
Rationale
- EC2 Auto Scaling target tracking enables metric driven desired capacity adjustment for new capacity should remain spread across zones as instances are replaced and scaled. The requested action is configure the group with multiple Availability Zone subnets. In this decision, EC2 Auto Scaling target tracking solves a different problem.
- ECS Availability Zone spread placement controls task placement distributed across fault domains for new capacity should remain spread across zones as instances are replaced and scaled. The requested action is configure the group with multiple Availability Zone subnets. For the stated goal, ECS Availability Zone spread placement does not fit here.
- Multi-AZ Auto Scaling group acts as instance distribution across multiple Availability Zones for new capacity should remain spread across zones as instances are replaced and scaled. The requested action is configure the group with multiple Availability Zone subnets. Because the evidence aligns with Multi-AZ Auto Scaling group, it matches the stated evidence.
- ALB target groups and health checks supplies Layer 7 distribution to healthy application for new capacity should remain spread across zones as instances are replaced and scaled. The requested action is configure the group with multiple Availability Zone subnets. With the stated need, ALB target groups and health checks addresses another layer.
Question 5
A resilience test deliberately makes one group member unhealthy. The requirement is to allow Auto Scaling to terminate and launch a replacement. Which design choice best satisfies this requirement? Choose ONE.
- ALB target groups and health checks
- Auto Scaling health-check replacement
- Auto Scaling lifecycle hook
- EC2 Auto Scaling target tracking
Correct Answer(s)
B
Rationale
- ALB target groups and health checks implements Layer 7 distribution to healthy application for capacity must return to desired count after an instance is declared unhealthy. The requested action is allow Auto Scaling to terminate and launch a replacement. With that requirement, ALB target groups and health checks fails this constraint.
- Auto Scaling health-check replacement supports automatic replacement of unhealthy group instances for capacity must return to desired count after an instance is declared unhealthy. The requested action is allow Auto Scaling to terminate and launch a replacement. Because the evidence aligns with Auto Scaling health-check replacement, it meets the operating need.
- Auto Scaling lifecycle hook serves as pause instance launch or termination transitions for capacity must return to desired count after an instance is declared unhealthy. The requested action is allow Auto Scaling to terminate and launch a replacement. For this operating model, Auto Scaling lifecycle hook does not resolve it.
- EC2 Auto Scaling target tracking applies metric driven desired capacity adjustment for capacity must return to desired count after an instance is declared unhealthy. The requested action is allow Auto Scaling to terminate and launch a replacement. Under that constraint, EC2 Auto Scaling target tracking serves another purpose.
Question 6
Operations wants controlled launch and termination workflows. The requirement is to attach a lifecycle hook and complete the transition when processing finishes. Which design choice best satisfies this requirement? Choose ONE.
- Auto Scaling lifecycle hook
- Auto Scaling health-check replacement
- Auto Scaling warm pool
- EC2 Auto Scaling target tracking
Correct Answer(s)
A
Rationale
- Auto Scaling lifecycle hook offers pause instance launch or termination transitions for an event-driven process must receive notice and complete work during scaling transitions. The requested action is attach a lifecycle hook and complete the transition when processing finishes. Because the evidence aligns with Auto Scaling lifecycle hook, it addresses this requirement.
- Auto Scaling health-check replacement creates automatic replacement of unhealthy group instances for an event-driven process must receive notice and complete work during scaling transitions. The requested action is attach a lifecycle hook and complete the transition when processing finishes. With this evidence, Auto Scaling health-check replacement changes another mechanism.
- Auto Scaling warm pool gives pre initialized instances kept near ready for an event-driven process must receive notice and complete work during scaling transitions. The requested action is attach a lifecycle hook and complete the transition when processing finishes. Under this evidence, Auto Scaling warm pool does not match.
- EC2 Auto Scaling target tracking delivers metric driven desired capacity adjustment for an event-driven process must receive notice and complete work during scaling transitions. The requested action is attach a lifecycle hook and complete the transition when processing finishes. Under these conditions, EC2 Auto Scaling target tracking is not the remedy.
Question 7
Architects want elasticity without paying full running cost for a large idle fleet. The requirement is to maintain warm pool members that can enter service faster than fresh launches. Which design choice best satisfies this requirement? Choose ONE.
- EC2 Auto Scaling scheduled scaling
- Auto Scaling lifecycle hook
- Auto Scaling warm pool
- Lambda provisioned concurrency
Correct Answer(s)
C
Rationale
- EC2 Auto Scaling scheduled scaling controls time based capacity changes at known for the application has predictable software initialization cost yet still needs elastic EC2 scaling. The requested action is maintain warm pool members that can enter service faster than fresh launches. For the required behavior, EC2 Auto Scaling scheduled scaling leaves the issue intact.
- Auto Scaling lifecycle hook supplies pause instance launch or termination transitions for the application has predictable software initialization cost yet still needs elastic EC2 scaling. The requested action is maintain warm pool members that can enter service faster than fresh launches. In this architecture, Auto Scaling lifecycle hook does not satisfy it.
- Auto Scaling warm pool enables pre initialized instances kept near ready for the application has predictable software initialization cost yet still needs elastic EC2 scaling. The requested action is maintain warm pool members that can enter service faster than fresh launches. Because the evidence aligns with Auto Scaling warm pool, it is the direct fit.
- Lambda provisioned concurrency establishes pre initialized execution environments for low for the application has predictable software initialization cost yet still needs elastic EC2 scaling. The requested action is maintain warm pool members that can enter service faster than fresh launches. Under the scenario, Lambda provisioned concurrency operates elsewhere.
Question 8
A tiered web platform needs one Layer-7 entry point and elastic backends. The requirement is to route the application through ALB target groups that track healthy registered targets. Which design choice best satisfies this requirement? Choose ONE.
- Network Load Balancer
- Auto Scaling health-check replacement
- API Gateway with Lambda
- ALB target groups and health checks
Correct Answer(s)
D
Rationale
- Network Load Balancer serves as Layer 4 distribution for TCP or for multiple Auto Scaling groups must register scalable HTTP targets behind one listener. The requested action is route the application through ALB target groups that track healthy registered targets. For this workload, Network Load Balancer is the wrong control.
- Auto Scaling health-check replacement applies automatic replacement of unhealthy group instances for multiple Auto Scaling groups must register scalable HTTP targets behind one listener. The requested action is route the application through ALB target groups that track healthy registered targets. In the requested path, Auto Scaling health-check replacement cannot meet this need.
- API Gateway with Lambda provides managed request front door for serverless for multiple Auto Scaling groups must register scalable HTTP targets behind one listener. The requested action is route the application through ALB target groups that track healthy registered targets. Given this case, API Gateway with Lambda misses this case.
- ALB target groups and health checks implements Layer 7 distribution to healthy application for multiple Auto Scaling groups must register scalable HTTP targets behind one listener. The requested action is route the application through ALB target groups that track healthy registered targets. Because the evidence aligns with ALB target groups and health checks, it satisfies this design.
Question 9
An ECS service exposes a non-HTTP network protocol. The requirement is to register task targets behind a Network Load Balancer. Which design choice best satisfies this requirement? Choose ONE.
- ALB target groups and health checks
- API Gateway with Lambda
- Network Load Balancer
- AWS Cloud Map service discovery
Correct Answer(s)
C
Rationale
- ALB target groups and health checks gives Layer 7 distribution to healthy application for container tasks need a stable Layer-4 entry point for a TCP service while task addresses change. The requested action is register task targets behind a Network Load Balancer. For this design, ALB target groups and health checks targets another requirement.
- API Gateway with Lambda delivers managed request front door for serverless for container tasks need a stable Layer-4 entry point for a TCP service while task addresses change. The requested action is register task targets behind a Network Load Balancer. In this decision, API Gateway with Lambda solves a different problem.
- Network Load Balancer creates Layer 4 distribution for TCP or for container tasks need a stable Layer-4 entry point for a TCP service while task addresses change. The requested action is register task targets behind a Network Load Balancer. Because the evidence aligns with Network Load Balancer, it aligns with this constraint.
- AWS Cloud Map service discovery functions as dynamic naming and discovery for service for container tasks need a stable Layer-4 entry point for a TCP service while task addresses change. The requested action is register task targets behind a Network Load Balancer. For the stated goal, AWS Cloud Map service discovery does not fit here.
Question 10
A microservice needs elastic task replicas within defined bounds. The requirement is to apply target tracking to ECS Service Auto Scaling. Which design choice best satisfies this requirement? Choose ONE.
- ECS capacity provider with managed scaling
- ECS Service Auto Scaling
- AWS Fargate
- EC2 Auto Scaling target tracking
Correct Answer(s)
B
Rationale
- ECS capacity provider with managed scaling supplies container demand linked to EC2 cluster for container task demand should follow a target utilization signal while preserving minimum and maximum task counts. The requested action is apply target tracking to ECS Service Auto Scaling. With the stated need, ECS capacity provider with managed scaling addresses another layer.
- ECS Service Auto Scaling controls automatic changes to ECS desired task for container task demand should follow a target utilization signal while preserving minimum and maximum task counts. The requested action is apply target tracking to ECS Service Auto Scaling. Because the evidence aligns with ECS Service Auto Scaling, it resolves the stated need.
- AWS Fargate establishes serverless compute capacity for containers for container task demand should follow a target utilization signal while preserving minimum and maximum task counts. The requested action is apply target tracking to ECS Service Auto Scaling. With that requirement, AWS Fargate fails this constraint.
- EC2 Auto Scaling target tracking handles metric driven desired capacity adjustment for container task demand should follow a target utilization signal while preserving minimum and maximum task counts. The requested action is apply target tracking to ECS Service Auto Scaling. For this operating model, EC2 Auto Scaling target tracking does not resolve it.
Question 11
A container platform keeps EC2 ownership but wants less manual host scaling. The requirement is to use capacity-provider managed scaling for the backing group. Which design choice best satisfies this requirement? Choose ONE.
- ECS Service Auto Scaling
- AWS Fargate
- ECS Availability Zone spread placement
- ECS capacity provider with managed scaling
Correct Answer(s)
D
Rationale
- ECS Service Auto Scaling applies automatic changes to ECS desired task for the platform wants ECS placement demand to drive the lifecycle of EC2 container instances. The requested action is use capacity-provider managed scaling for the backing group. Under that constraint, ECS Service Auto Scaling serves another purpose.
- AWS Fargate provides serverless compute capacity for containers for the platform wants ECS placement demand to drive the lifecycle of EC2 container instances. The requested action is use capacity-provider managed scaling for the backing group. With this evidence, AWS Fargate changes another mechanism.
- ECS Availability Zone spread placement acts as task placement distributed across fault domains for the platform wants ECS placement demand to drive the lifecycle of EC2 container instances. The requested action is use capacity-provider managed scaling for the backing group. Under this evidence, ECS Availability Zone spread placement does not match.
- ECS capacity provider with managed scaling serves as container demand linked to EC2 cluster for the platform wants ECS placement demand to drive the lifecycle of EC2 container instances. The requested action is use capacity-provider managed scaling for the backing group. Because the evidence aligns with ECS capacity provider with managed scaling, it fits this case.
Question 12
An organization standardizes stateless services on managed container compute. The requirement is to use Fargate capacity for the container tasks. Which design choice best satisfies this requirement? Choose ONE.
- AWS Fargate
- ECS capacity provider with managed scaling
- ECS Availability Zone spread placement
- Multi-AZ Auto Scaling group
Correct Answer(s)
A
Rationale
- AWS Fargate gives serverless compute capacity for containers for new microservices need per-task compute isolation without a persistent customer-managed worker fleet. The requested action is use Fargate capacity for the container tasks. Because the evidence aligns with AWS Fargate, it matches the stated evidence.
- ECS capacity provider with managed scaling delivers container demand linked to EC2 cluster for new microservices need per-task compute isolation without a persistent customer-managed worker fleet. The requested action is use Fargate capacity for the container tasks. Under these conditions, ECS capacity provider with managed scaling is not the remedy.
- ECS Availability Zone spread placement functions as task placement distributed across fault domains for new microservices need per-task compute isolation without a persistent customer-managed worker fleet. The requested action is use Fargate capacity for the container tasks. For the required behavior, ECS Availability Zone spread placement leaves the issue intact.
- Multi-AZ Auto Scaling group supports instance distribution across multiple Availability Zones for new microservices need per-task compute isolation without a persistent customer-managed worker fleet. The requested action is use Fargate capacity for the container tasks. In this architecture, Multi-AZ Auto Scaling group does not satisfy it.
Question 13
A resilient container tier values zone diversity over maximum bin packing. The requirement is to apply an Availability Zone spread strategy for the service. Which design choice best satisfies this requirement? Choose ONE.
- Multi-AZ Auto Scaling group
- ECS capacity provider with managed scaling
- AWS Fargate
- ECS Availability Zone spread placement
Correct Answer(s)
D
Rationale
- Multi-AZ Auto Scaling group establishes instance distribution across multiple Availability Zones for the scheduler should favor even replica distribution by zone before packing hosts. The requested action is apply an Availability Zone spread strategy for the service. Under the scenario, Multi-AZ Auto Scaling group operates elsewhere.
- ECS capacity provider with managed scaling handles container demand linked to EC2 cluster for the scheduler should favor even replica distribution by zone before packing hosts. The requested action is apply an Availability Zone spread strategy for the service. For this workload, ECS capacity provider with managed scaling is the wrong control.
- AWS Fargate offers serverless compute capacity for containers for the scheduler should favor even replica distribution by zone before packing hosts. The requested action is apply an Availability Zone spread strategy for the service. In the requested path, AWS Fargate cannot meet this need.
- ECS Availability Zone spread placement supplies task placement distributed across fault domains for the scheduler should favor even replica distribution by zone before packing hosts. The requested action is apply an Availability Zone spread strategy for the service. Because the evidence aligns with ECS Availability Zone spread placement, it meets the operating need.
Question 14
An API backend experiences sudden but valid traffic bursts. The requirement is to rely on Lambda scaling while monitoring concurrency quotas. Which design choice best satisfies this requirement? Choose ONE.
- AWS Lambda automatic scaling
- Lambda reserved concurrency
- Lambda provisioned concurrency
- API Gateway with Lambda
Correct Answer(s)
A
Rationale
- AWS Lambda automatic scaling applies concurrency created automatically for incoming invocations for a serverless function must expand execution environments as request concurrency rises within account and function limits. The requested action is rely on Lambda scaling while monitoring concurrency quotas. Because the evidence aligns with AWS Lambda automatic scaling, it addresses this requirement.
- Lambda reserved concurrency provides function specific concurrency reservation and maximum for a serverless function must expand execution environments as request concurrency rises within account and function limits. The requested action is rely on Lambda scaling while monitoring concurrency quotas. Given this case, Lambda reserved concurrency misses this case.
- Lambda provisioned concurrency acts as pre initialized execution environments for low for a serverless function must expand execution environments as request concurrency rises within account and function limits. The requested action is rely on Lambda scaling while monitoring concurrency quotas. For this design, Lambda provisioned concurrency targets another requirement.
- API Gateway with Lambda enables managed request front door for serverless for a serverless function must expand execution environments as request concurrency rises within account and function limits. The requested action is rely on Lambda scaling while monitoring concurrency quotas. In this decision, API Gateway with Lambda solves a different problem.
Question 15
Serverless workloads compete for shared concurrency during spikes. The requirement is to configure reserved concurrency on that function. Which design choice best satisfies this requirement? Choose ONE.
- Lambda provisioned concurrency
- AWS Lambda automatic scaling
- Lambda reserved concurrency
- ECS Service Auto Scaling
Correct Answer(s)
C
Rationale
- Lambda provisioned concurrency functions as pre initialized execution environments for low for a critical function needs a guaranteed portion of account concurrency while also having a defined ceiling. The requested action is configure reserved concurrency on that function. For the stated goal, Lambda provisioned concurrency does not fit here.
- AWS Lambda automatic scaling supports concurrency created automatically for incoming invocations for a critical function needs a guaranteed portion of account concurrency while also having a defined ceiling. The requested action is configure reserved concurrency on that function. With the stated need, AWS Lambda automatic scaling addresses another layer.
- Lambda reserved concurrency delivers function specific concurrency reservation and maximum for a critical function needs a guaranteed portion of account concurrency while also having a defined ceiling. The requested action is configure reserved concurrency on that function. Because the evidence aligns with Lambda reserved concurrency, it is the direct fit.
- ECS Service Auto Scaling implements automatic changes to ECS desired task for a critical function needs a guaranteed portion of account concurrency while also having a defined ceiling. The requested action is configure reserved concurrency on that function. With that requirement, ECS Service Auto Scaling fails this constraint.
Question 16
A function must deliver consistent startup latency during a known launch window. The requirement is to schedule or configure provisioned concurrency ahead of the event. Which design choice best satisfies this requirement? Choose ONE.
- Lambda reserved concurrency
- Lambda provisioned concurrency
- Auto Scaling warm pool
- AWS Lambda automatic scaling
Correct Answer(s)
B
Rationale
- Lambda reserved concurrency handles function specific concurrency reservation and maximum for a planned event needs Lambda environments ready before user traffic arrives. The requested action is schedule or configure provisioned concurrency ahead of the event. For this operating model, Lambda reserved concurrency does not resolve it.
- Lambda provisioned concurrency establishes pre initialized execution environments for low for a planned event needs Lambda environments ready before user traffic arrives. The requested action is schedule or configure provisioned concurrency ahead of the event. Because the evidence aligns with Lambda provisioned concurrency, it satisfies this design.
- Auto Scaling warm pool offers pre initialized instances kept near ready for a planned event needs Lambda environments ready before user traffic arrives. The requested action is schedule or configure provisioned concurrency ahead of the event. Under that constraint, Auto Scaling warm pool serves another purpose.
- AWS Lambda automatic scaling creates concurrency created automatically for incoming invocations for a planned event needs Lambda environments ready before user traffic arrives. The requested action is schedule or configure provisioned concurrency ahead of the event. With this evidence, AWS Lambda automatic scaling changes another mechanism.
Question 17
A microservice team wants an API layer without maintaining reverse-proxy instances. The requirement is to expose the functions through API Gateway resources and routes. Which design choice best satisfies this requirement? Choose ONE.
- API Gateway with Lambda
- ALB target groups and health checks
- Network Load Balancer
- AWS Cloud Map service discovery
Correct Answer(s)
A
Rationale
- API Gateway with Lambda provides managed request front door for serverless for several lightweight Lambda operations need one managed API surface with routing and authorization features. The requested action is expose the functions through API Gateway resources and routes. Because the evidence aligns with API Gateway with Lambda, it aligns with this constraint.
- ALB target groups and health checks acts as Layer 7 distribution to healthy application for several lightweight Lambda operations need one managed API surface with routing and authorization features. The requested action is expose the functions through API Gateway resources and routes. Under this evidence, ALB target groups and health checks does not match.
- Network Load Balancer enables Layer 4 distribution for TCP or for several lightweight Lambda operations need one managed API surface with routing and authorization features. The requested action is expose the functions through API Gateway resources and routes. Under these conditions, Network Load Balancer is not the remedy.
- AWS Cloud Map service discovery controls dynamic naming and discovery for service for several lightweight Lambda operations need one managed API surface with routing and authorization features. The requested action is expose the functions through API Gateway resources and routes. For the required behavior, AWS Cloud Map service discovery leaves the issue intact.
Question 18
An EKS team wants native pod-level elasticity. The requirement is to apply HPA to the deployment. Which design choice best satisfies this requirement? Choose ONE.
- EKS node autoscaling
- ECS Service Auto Scaling
- Kubernetes Horizontal Pod Autoscaler on EKS
- EC2 Auto Scaling target tracking
Correct Answer(s)
C
Rationale
- EKS node autoscaling supports worker node capacity changes for pending for a Kubernetes workload needs a minimum and maximum replica range driven by measured resource use. The requested action is apply HPA to the deployment. In this architecture, EKS node autoscaling does not satisfy it.
- ECS Service Auto Scaling implements automatic changes to ECS desired task for a Kubernetes workload needs a minimum and maximum replica range driven by measured resource use. The requested action is apply HPA to the deployment. Under the scenario, ECS Service Auto Scaling operates elsewhere.
- Kubernetes Horizontal Pod Autoscaler on EKS functions as pod replica scaling from observed metrics for a Kubernetes workload needs a minimum and maximum replica range driven by measured resource use. The requested action is apply HPA to the deployment. Because the evidence aligns with Kubernetes Horizontal Pod Autoscaler on EKS, it resolves the stated need.
- EC2 Auto Scaling target tracking serves as metric driven desired capacity adjustment for a Kubernetes workload needs a minimum and maximum replica range driven by measured resource use. The requested action is apply HPA to the deployment. For this workload, EC2 Auto Scaling target tracking is the wrong control.
Question 19
An EKS cluster currently leaves many empty nodes after traffic falls. The requirement is to enable node-level autoscaling alongside workload-level scaling. Which design choice best satisfies this requirement? Choose ONE.
- Kubernetes Horizontal Pod Autoscaler on EKS
- ECS capacity provider with managed scaling
- AWS Fargate
- EKS node autoscaling
Correct Answer(s)
D
Rationale
- Kubernetes Horizontal Pod Autoscaler on EKS offers pod replica scaling from observed metrics for pod replicas can scale down, and unused worker capacity should also contract over time. The requested action is enable node-level autoscaling alongside workload-level scaling. In the requested path, Kubernetes Horizontal Pod Autoscaler on EKS cannot meet this need.
- ECS capacity provider with managed scaling creates container demand linked to EC2 cluster for pod replicas can scale down, and unused worker capacity should also contract over time. The requested action is enable node-level autoscaling alongside workload-level scaling. Given this case, ECS capacity provider with managed scaling misses this case.
- AWS Fargate gives serverless compute capacity for containers for pod replicas can scale down, and unused worker capacity should also contract over time. The requested action is enable node-level autoscaling alongside workload-level scaling. For this design, AWS Fargate targets another requirement.
- EKS node autoscaling handles worker node capacity changes for pending for pod replicas can scale down, and unused worker capacity should also contract over time. The requested action is enable node-level autoscaling alongside workload-level scaling. Because the evidence aligns with EKS node autoscaling, it fits this case.
Question 20
A microservice architecture wants loose endpoint coupling inside the application network. The requirement is to use AWS Cloud Map for service discovery metadata and naming. Which design choice best satisfies this requirement? Choose ONE.
- ALB target groups and health checks
- AWS Cloud Map service discovery
- API Gateway with Lambda
- Network Load Balancer
Correct Answer(s)
B
Rationale
- ALB target groups and health checks enables Layer 7 distribution to healthy application for internal services need a registry that tracks healthy service endpoints as instances register and deregister. The requested action is use AWS Cloud Map for service discovery metadata and naming. In this decision, ALB target groups and health checks solves a different problem.
- AWS Cloud Map service discovery acts as dynamic naming and discovery for service for internal services need a registry that tracks healthy service endpoints as instances register and deregister. The requested action is use AWS Cloud Map for service discovery metadata and naming. Because the evidence aligns with AWS Cloud Map service discovery, it matches the stated evidence.
- API Gateway with Lambda controls managed request front door for serverless for internal services need a registry that tracks healthy service endpoints as instances register and deregister. The requested action is use AWS Cloud Map for service discovery metadata and naming. For the stated goal, API Gateway with Lambda does not fit here.
- Network Load Balancer supplies Layer 4 distribution for TCP or for internal services need a registry that tracks healthy service endpoints as instances register and deregister. The requested action is use AWS Cloud Map for service discovery metadata and naming. With the stated need, Network Load Balancer addresses another layer.