AWS Certified Solutions Architect - Associate SAA-C03 Practice Test 44
Question 430
An Auto Scaling group terminates worker nodes as queue depth falls. Some nodes are still finishing long database imports and need a controlled drain before termination. Which feature can hold termination while cleanup occurs?
- Use an EC2 Auto Scaling lifecycle hook to perform supported drain or cleanup actions before termination completes.
- Set the instance's EBS volume type to gp3, which pauses any Auto Scaling termination until database imports finish.
- Use only an ALB listener priority value to delay all instance termination events for an unlimited time.
- Disable CloudWatch Logs because log delivery is the cause of premature Auto Scaling termination.
Explanation
Correct Answer
A:Lifecycle hooks can pause the termination progression while external logic completes bounded cleanup, reducing interruption to in-flight work.
Incorrect Answers
B:Volume performance selection does not provide an Auto Scaling lifecycle wait/heartbeat mechanism.
C:Listener routing priorities do not govern instance shutdown lifecycle waits or worker job completion.
D:Logging is unrelated to the missing lifecycle drain control and disabling it removes diagnostics.
Question 431
A team operates six containerized REST microservices. Engineers prefer an AWS-managed container orchestrator with task definitions, services and load balancing rather than maintaining Kubernetes control-plane configuration. Which option aligns?
- Run every service by hand with Docker commands on one fixed EC2 instance and call it a managed multi-AZ orchestrator.
- Require EKS solely because every container application on AWS must use Kubernetes.
- Use AWS App Runner for each HTTP container while expecting ECS task definitions, ECS service deployment and existing target-group controls to remain unchanged.
- Use Amazon ECS services with appropriately configured task definitions and target groups.
Explanation
Correct Answer
D:ECS provides AWS-native orchestration of container tasks and independently deployable services with integrations for scaling and networking.
Incorrect Answers
A:A manually operated single host is not a managed distributed orchestration platform with desired-state recovery.
B:Kubernetes may be appropriate for specific requirements, but is not mandatory when ECS meets the stated AWS-native preference.
C:App Runner is a managed application deployment service and may suit simple web workloads, but it is not a drop-in ECS service scheduler with the required ECS task-definition and target-group management semantics.
Question 432
An Amazon ECS service uses rolling deployments and has a previously completed healthy service revision. A new task definition repeatedly fails to start and later fails application health checks, leaving the deployment stuck without reaching a steady state. The team wants ECS to declare the rollout failed and return to the previous healthy revision without a manual switch. What should the service configure?
- Increase only the minimum number of tasks and assume the ECS scheduler will always roll back any deployment automatically by default.
- Enable the ECS deployment circuit breaker with rollback for the rolling deployment and monitor its deployment failure events.
- Enable S3 Versioning on the image artifact bucket and assume ECS automatically redeploys the previous running revision whenever the bucket changes.
- Replace the ECS scheduler with a Route 53 health check that directly changes container task definitions when a new task fails startup.
Explanation
Correct Answer
B:The ECS deployment circuit breaker detects rolling task startup and health-check failures and can roll back to a previous completed service revision. EventBridge deployment state events can support operational alerting.
Incorrect Answers
A:Desired and minimum task counts control capacity but do not by themselves enable automatic reversal of a failed service revision. Rollback is a separate deployment failure-detection configuration.
C:S3 object versions do not instruct ECS to identify a failed rollout or roll back service deployments. The ECS deployment controller and failure-detection settings own that decision.
D:DNS health checks can influence client routing but do not directly replace ECS deployment failure detection or swap the service task-definition revision.
Question 433
An ECS service should maintain six healthy API tasks across two Availability Zones. After two tasks crash, the service remains under desired capacity until an operator manually runs tasks. What ECS control should own replacement and growth?
- Set and monitor ECS service desired count and supported service autoscaling, with suitable health checks and capacity.
- Launch tasks only as ad hoc one-off RunTask commands with no service to maintain a steady count.
- Configure an S3 bucket lifecycle rule for task failures, because it launches new containers on a crash.
- Disable container health checks and rely on operators noticing crashes before replacement occurs.
Explanation
Correct Answer
A:An ECS service maintains desired task state and can integrate Application Auto Scaling. Task health and available infrastructure determine successful replacement.
Incorrect Answers
B:One-off tasks lack the steady-state service controller that automatically replaces failed replicas.
C:Object lifecycle operations do not implement container service desired count or task rescheduling.
D:Hiding task failures cannot maintain reliable desired capacity or remove broken API targets promptly.
Question 434
Several ECS Fargate microservices currently run with broad shared security groups allowing every port to every service. The security team needs only the payments API to reach an RDS listener and only ingress tier to reach payments. What network design should be used?
- Move all tasks to one public subnet and enable unrestricted public addresses for convenience.
- Assign scoped task networking and security-group rules that permit only required service-to-service and database flows.
- Use only ECS task CPU quotas to prevent unauthorized TCP connections between containers.
- Keep all inbound and outbound ports open between every service because container separation removes network risk.
Explanation
Correct Answer
B:Task-level networking and narrowly scoped security groups support least-privilege east-west access and reduce lateral movement.
Incorrect Answers
A:Broad public placement and reachability violate the explicitly private and least-privilege connectivity objective.
C:CPU reservations and limits manage compute resources, not network authorization or segmentation.
D:Container isolation does not substitute for network controls when compromised tasks can communicate with unrelated services.
Question 435
A software vendor delivers Kubernetes manifests, operators and admission policies that must run consistently across on-premises clusters and AWS. The company wants a managed Kubernetes API control plane while retaining compatible tooling. What AWS service fits?
- Use a self-managed Kubernetes control plane on EC2 Auto Scaling groups but count EC2 host scaling as equivalent to the fully managed EKS control plane.
- Use an ECS-only task definition and assume every Kubernetes custom resource operates unchanged through it.
- Use Amazon EKS to provide a managed Kubernetes control plane for supported worker environments.
- Use Amazon S3 as the Kubernetes API endpoint without provisioning any cluster control plane.
Explanation
Correct Answer
C:EKS exposes Kubernetes APIs and ecosystem tooling, supporting teams whose platform requirements specifically depend on Kubernetes resources.
Incorrect Answers
A:Self-managed Kubernetes control planes require operating their own API servers and etcd. EC2 instance scaling alone does not satisfy a requirement specifically for Amazon EKS managed Kubernetes APIs.
B:ECS has different orchestration APIs and does not natively implement all Kubernetes custom resource/controller semantics.
D:Object storage cannot schedule pods or expose Kubernetes admission and controller interfaces.
Question 436
An EKS deployment increases pod replica count when requests rise, but node Auto Scaling responds separately. The team asks which feature directly changes the number of desired service pods based on CPU or custom metrics. What should they configure?
- Increase only EBS volume size on cluster nodes; this automatically raises deployment replica count.
- Use an S3 lifecycle rule on container images to reschedule new Kubernetes pods under load.
- Delete the EKS cluster control plane and depend on pod metrics alone to run all resources.
- Configure Kubernetes Horizontal Pod Autoscaler with suitable metrics and resource requests for the deployment.
Explanation
Correct Answer
D:HPA changes pod replica counts from workload signals. Node or compute capacity scaling is an additional responsibility so newly requested pods can actually schedule.
Incorrect Answers
A:Storage capacity changes cannot directly adjust Kubernetes desired pod replicas based on request or CPU metrics.
B:S3 object lifecycle transitions do not implement a Kubernetes deployment autoscaler.
C:Without a functioning Kubernetes API and scheduler, HPA cannot manage deployment replica state.
Question 437
An EKS cluster uses Karpenter and has unconstrained regional EC2 capacity, but its pending stateless web pods need 4 vCPUs and x86_64. Karpenter logs show its only NodePool permits a single unavailable Spot instance family in one AZ. What is the direct configuration remedy?
- Broaden compatible NodePool instance-family/AZ/capacity-type requirements and confirm pod selectors and limits permit the new nodes.
- Increase only the Horizontal Pod Autoscaler maximum replicas without changing the permitted NodePool node shapes.
- Change the ALB listener idle timeout and expect Karpenter to acquire Spot pools in otherwise excluded AZs.
- Raise the container memory request above the permitted node size to force a smaller EC2 instance to schedule it.
Explanation
Correct Answer
A:Karpenter provisions only nodes permitted by NodePool constraints, pod scheduling rules, limits, and available capacity; diversified allowed pools address this.
Incorrect Answers
B:HPA raises desired pod count but cannot override the NodePool constraints that exclude viable EC2 capacity.
C:Load-balancer timeouts do not modify allowed instance types, capacity types or zones for node provisioning.
D:Overstating pod requests makes matching harder and does not permit additional machine shapes.
Question 438
The EKS control plane is managed by AWS and remains healthy, but all production application pods are scheduled onto one small node in one AZ. That node fails and customer requests stop. Which statement accurately identifies responsibility?
- Delete the application deployment and trust the EKS control plane itself to serve its customer HTTP requests.
- EKS management guarantees that any one application pod automatically becomes multi-AZ without replica or node planning.
- Convert the EKS worker node's EBS volume to encrypted status because encryption alone provides application multi-AZ uptime.
- EKS control-plane availability is managed, but workload placement, node resilience and pod redundancy still need architect design.
Explanation
Correct Answer
D:A resilient Kubernetes API does not ensure that customer applications have multiple replicas spread across independent fault domains.
Incorrect Answers
A:The control plane manages cluster resources but does not replace the application's serving pods or business logic.
B:Pod placement and replacement depend on workload/controller definitions and available compatible infrastructure.
C:Storage confidentiality is not a substitute for scheduling redundant application replicas across failure domains.
Question 439
An ECS service has tasks replaced several times per day. Another private service stores the current task IP addresses in its configuration file and experiences intermittent connection failures. What removes that static-IP dependency?
- Assign every transient ECS task a permanent manually configured IP and disable all task replacement.
- Register and discover ECS service endpoints through Service Connect or AWS Cloud Map as appropriate.
- Publish the container's current process ID as a public DNS name for every other service.
- Increase S3 object retention to keep old task IP addresses resolvable by callers.
Explanation
Correct Answer
B:Managed service discovery lets consumers use stable names or endpoints while underlying task addresses change during deployments and scaling.
Incorrect Answers
A:Task lifecycle is dynamic; hardcoded IP maintenance undermines scheduler recovery and normal deployment behavior.
C:A process identifier is not a stable network service-discovery record and cannot survive task replacement.
D:S3 retention has no relationship to changing container network endpoints or client service discovery.
Question 440
A private service's DNS discovery record continues directing clients to an instance after the service has stopped responding. The provider supports health-aware discovery. Which mechanism should the architect examine?
- Delete all healthy service records and preserve only the failed instance's DNS address.
- Change EBS IOPS only, which updates Cloud Map DNS health status without any discovery integration.
- Configure appropriate service-discovery health checks or health status integration so unhealthy endpoints are excluded.
- Increase every service record's TTL to twenty-four hours so clients keep using failed addresses longer.
Explanation
Correct Answer
C:Discovery health information can remove failing targets from eligible responses, provided the checks and client caching behavior are designed correctly.
Incorrect Answers
A:Publishing only a broken endpoint defeats the objective of steering callers to viable service members.
B:Volume performance settings do not establish service health for DNS registration or endpoint selection.
D:Longer stale DNS caching generally delays removal of unhealthy endpoints and worsens failed connection attempts.
