Deploying workloads on EKS in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

EKS Pod Scheduling Behavior

You deploy a pod with a nodeSelector that matches no nodes in your EKS cluster. What will happen to the pod?

A The pod will remain in Pending state indefinitely until a matching node is available.

B The pod will be scheduled on any available node ignoring the nodeSelector.

C The pod will be immediately deleted by the Kubernetes control plane.

D The pod will run but with reduced resource limits.

💡 Hint

Think about how Kubernetes respects nodeSelector constraints when scheduling pods.

Kubernetes will not schedule a pod if no nodes match the nodeSelector. The pod stays Pending until a suitable node appears.

❓ Configuration

intermediate

IAM Role for Service Account (IRSA) Setup

You want to allow a pod in EKS to access AWS S3 securely without using node IAM roles. Which configuration is required?

A Create an IAM user and embed its access keys in the pod container.

B Attach the S3 permissions directly to the EC2 worker node IAM role.

C Add AWS credentials as environment variables in the pod spec.

D Create an IAM role with S3 permissions and annotate the Kubernetes service account with its ARN.

💡 Hint

Consider how IRSA allows pods to assume IAM roles securely.

IRSA uses IAM roles linked to Kubernetes service accounts via annotations, enabling pods to get temporary credentials.

❓ Architecture

advanced

High Availability for EKS Control Plane

Which statement best describes the availability of the EKS control plane?

A You must deploy multiple control plane nodes manually in different AZs.

B EKS control plane runs on a single EC2 instance in one AZ.

C EKS control plane is managed by AWS and runs across multiple Availability Zones automatically.

D You need to configure a load balancer to distribute traffic to control plane nodes.

💡 Hint

Think about how AWS manages the control plane for EKS clusters.

AWS manages the EKS control plane as a highly available service running across multiple AZs, so you don't manage it directly.

❓ security

advanced

Securing EKS Worker Nodes

What is the best practice to minimize security risks on EKS worker nodes?

A Run all pods as root user to avoid permission issues.

B Use the latest Amazon EKS-optimized AMI with minimal privileges and enable automatic security updates.

C Allow all inbound traffic to worker nodes for easier debugging.

D Disable the Kubernetes network policies to improve network performance.

💡 Hint

Consider how to reduce attack surface and keep nodes secure.

Using the EKS-optimized AMI ensures security patches and minimal privileges. Automatic updates help keep nodes secure.

✅ Best Practice

expert

Scaling EKS Worker Nodes Efficiently

You want to optimize cost and performance by scaling EKS worker nodes based on workload demand. Which approach is best?

A Use Cluster Autoscaler with multiple node groups having different instance types and spot instances.

B Manually add or remove EC2 instances in the worker node Auto Scaling Group.

C Set a fixed number of worker nodes and scale pods only.

D Use a single large instance type for all workloads to simplify management.

💡 Hint

Think about how to balance cost and availability with autoscaling.

Cluster Autoscaler dynamically adjusts node counts. Using multiple node groups with spot instances optimizes cost and performance.