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.

Practice

1. What is the main purpose of Amazon EKS when deploying workloads?

easy

A. To run containerized applications using Kubernetes without managing servers

B. To store large amounts of data in the cloud

C. To create virtual machines for running applications

D. To manage user access and permissions

Solution

1. Step 1: Understand EKS functionality

   Amazon EKS is a managed Kubernetes service that lets you run containers without managing the underlying servers.

2. Step 2: Compare options

   Storing data relates to services like S3, creating VMs to EC2, and managing permissions to IAM--none of which is EKS's core purpose.

3. Final Answer:

   To run containerized applications using Kubernetes without managing servers -> Option A

4. Quick Check:

   EKS = Managed Kubernetes for containers [OK]

Hint: EKS = Kubernetes service for containers, not storage or VMs [OK]

Common Mistakes:

• Confusing EKS with storage services like S3
• Thinking EKS manages virtual machines directly
• Mixing EKS with IAM user management

2. Which of the following is the correct command to deploy an application using a YAML file named app-deployment.yaml on EKS?

easy

A. kubectl run app-deployment.yaml

B. eksctl create app app-deployment.yaml

C. aws eks deploy app-deployment.yaml

D. kubectl apply -f app-deployment.yaml

Solution

1. Step 1: Identify the kubectl command for applying YAML

   The correct command to deploy resources defined in a YAML file is kubectl apply -f filename.

2. Step 2: Evaluate other options

   kubectl run app-deployment.yaml is for running individual pods, not applying YAML manifests. eksctl create app app-deployment.yaml misuses eksctl, which is primarily for EKS cluster creation. aws eks deploy app-deployment.yaml is not a valid AWS CLI command.

3. Final Answer:

   kubectl apply -f app-deployment.yaml -> Option D

4. Quick Check:

   Deploy YAML with kubectl apply -f [OK]

Hint: Use kubectl apply -f for YAML deployment files [OK]

Common Mistakes:

• Using eksctl for direct YAML deployment
• Confusing kubectl run with apply
• Trying AWS CLI commands that don't exist

3. Given this YAML snippet for a Deployment on EKS:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: nginx:latest

What will be the number of running pods after applying this deployment?

medium

A. 1

B. 3

C. 0

D. Depends on the node capacity

Solution

1. Step 1: Read the replicas field in the Deployment spec

   The YAML specifies replicas: 3, which means Kubernetes will create 3 pods for this deployment.

2. Step 2: Understand pod creation behavior

   Unless there is a scheduling issue, Kubernetes will run 3 pods as requested.

3. Final Answer:

   3 -> Option B

4. Quick Check:

   replicas = number of pods running [OK]

Hint: replicas field sets pod count in Deployment spec [OK]

Common Mistakes:

• Assuming only 1 pod runs by default
• Thinking pods depend on node capacity without error
• Confusing selector labels with pod count

4. You tried to deploy a workload on EKS using kubectl apply -f deployment.yaml, but got an error: error: unable to recognize "deployment.yaml": no matches for kind "Deploy". What is the likely cause?

medium

A. The cluster is not running

B. kubectl is not installed

C. The YAML file has a typo in the kind field; it should be 'Deployment' not 'Deploy'

D. The image name in the YAML is incorrect

Solution

1. Step 1: Analyze the error message

   The error says no matches for kind "Deploy", which means Kubernetes does not recognize this resource kind.

2. Step 2: Check the YAML kind field

   The correct kind for workload deployment is "Deployment", not "Deploy". This typo causes the error.

3. Final Answer:

   The YAML file has a typo in the kind field; it should be 'Deployment' not 'Deploy' -> Option C

4. Quick Check:

   Kind field must be exact Kubernetes resource name [OK]

Hint: Check resource kind spelling in YAML for errors [OK]

Common Mistakes:

• Ignoring error details about resource kind
• Assuming cluster or kubectl issues without checking YAML
• Blaming image name for syntax errors

5. You want to deploy a stateless web app on EKS that automatically scales between 2 and 5 pods based on CPU usage. Which combination of Kubernetes resources should you define in your YAML files?

hard

A. A Deployment with replicas set to 2 and a Horizontal Pod Autoscaler targeting CPU usage with max replicas 5

B. A StatefulSet with replicas 5 and a LoadBalancer service

C. A DaemonSet to run pods on every node and a Cluster Autoscaler

D. A Deployment with replicas fixed at 5 and a NodePort service

Solution

1. Step 1: Identify resource for managing pod replicas with scaling

   A Deployment manages stateless pods and can be combined with a Horizontal Pod Autoscaler (HPA) to scale pods based on CPU.

2. Step 2: Understand autoscaling setup

   Set Deployment replicas to minimum 2, and HPA to scale up to max 5 pods based on CPU usage.

3. Step 3: Evaluate other options

   StatefulSet is for stateful apps, DaemonSet runs pods on all nodes (not scaling pods), fixed replicas do not autoscale.

4. Final Answer:

   A Deployment with replicas set to 2 and a Horizontal Pod Autoscaler targeting CPU usage with max replicas 5 -> Option A

5. Quick Check:

   Deployment + HPA = autoscaling pods [OK]

Hint: Use Deployment + HPA for CPU-based pod autoscaling [OK]

Common Mistakes:

• Using StatefulSet for stateless apps
• Confusing DaemonSet with autoscaling pods
• Setting fixed replicas without autoscaler