AWS EKS DevOps - Lab application deployment
Budget: $30 – $250 USD
A DevOps exercise that need to be Lab tested and run smoothy.
Time to get it done should be between 4-9 hours depends on you.
The Application
• A LiveView application (Provided in a Zip file) page that holds long-lived WebSocket connections.
• Latency-sensitive. Bursty traffic with sharp peaks; must stay responsive under load.
• CPU and memory only — no GPU, no specialized hardware.
• Backed by PostgreSQL. You may assume the database is provided externally (RDS)
and only need to wire connectivity.
• Cannot tolerate sudden node loss without graceful draining — open LiveView sockets
should not be dropped abruptly during a deploy or scale-down.
Deliverables:
Submit a zip fole containing the following:
1. Dockerfile
• A Dockerfile that produces a production image for the Phoenix application.
• I expect a multi-stage build, a non-root runtime user, a minimal runtime base, and no
secrets baked into layers.
• How you produce the production artifact — and what runs as PID 1 inside the container
— is a decision we want you to make and justify.
2. Kubernetes manifests
Helm chart or Kustomize overlays — your choice. Include at minimum:
• Deployment with appropriate replicas, probes, resource requests and limits, security
context, and graceful shutdown configuration.
• Service of the appropriate type (consider what LiveView needs to function correctly).
• HorizontalPodAutoscaler with scaling logic that fits the workload. Justify your choice of
scaling signal.
• PodDisruptionBudget tuned to the application’s tolerance for disruption — keeping in
mind that LiveView holds long-lived connections.
• ServiceAccount and any RBAC the workload actually needs.
• Any additional resources you decide are warranted (we leave this open intentionally).
3. Karpenter configuration
Provide NodePool and EC2NodeClass specs for this workload. We expect to see deliberate
choices about:
• Instance families and sizes, with reasoning.
• Capacity type strategy — on-demand, spot, or a weighted mix — and why that fits a
connection-holding workload.
• Consolidation policy and how it interacts with the application’s disruption tolerance.
• Any taints, tolerations, or affinity that you find warranted.
4. README
A README.md that explains your design. We read this carefully. Cover:
• How the production artifact is built and what runs inside the container.
• How a deploy or scale-down does not abruptly kill open WebSocket connections.
• Your choice of HPA signal and why CPU alone is or is not the right one here.
• Whether you addressed running the application as more than one replica, and what
implications that has for the application itself. If you deferred this, say so and explain.
• Why you chose the instance families and capacity types you did.
• GovCloud-specific considerations you accounted for or would account for in production.
• What you would add for production that you intentionally left out, and why.
• Anything you would do differently with more time.
5. Discovery log
A short section in the README (5 to 10 bullets is plenty) capturing what you did not know
coming into this assignment and how you figured it out. We want to see what you learned, what
surprised you, what you chose to investigate deeply, and what you chose to take on faith. This
is not a test of how little you can admit not knowing — the most useful submissions are honest
about both.
6. Optional bonus
• A short load-test plan, or a working load test, demonstrating scaling behavior under
bursty traffic.
• A custom-metrics HPA sketch using a signal more meaningful than CPU.
• A working multi-replica setup with the cross-pod implications addressed end-to-end.
Bonus items are genuinely optional. A strong core submission beats a sprawling one with
bonuses.
Constraints and Assumptions
• Target environment is AWS GovCloud (us-gov-west-1). You do not need to actually
deploy there; assume it as the target when making design choices.
• You do not need a live EKS cluster. Local kind or k3d is sufficient to verify that manifests
apply cleanly. Karpenter specs are evaluated as code, not by running them.
• You may use any tools you would normally use, including AI assistants and
documentation. We will discuss your choices in the walkthrough, so be ready to defend
them as your own.
• Prior Elixir or Phoenix experience is not expected. If you have it, great. If you do not, that
is the point — show us how you operate.
Time to get it done should be between 4-9 hours depends on you.
The Application
• A LiveView application (Provided in a Zip file) page that holds long-lived WebSocket connections.
• Latency-sensitive. Bursty traffic with sharp peaks; must stay responsive under load.
• CPU and memory only — no GPU, no specialized hardware.
• Backed by PostgreSQL. You may assume the database is provided externally (RDS)
and only need to wire connectivity.
• Cannot tolerate sudden node loss without graceful draining — open LiveView sockets
should not be dropped abruptly during a deploy or scale-down.
Deliverables:
Submit a zip fole containing the following:
1. Dockerfile
• A Dockerfile that produces a production image for the Phoenix application.
• I expect a multi-stage build, a non-root runtime user, a minimal runtime base, and no
secrets baked into layers.
• How you produce the production artifact — and what runs as PID 1 inside the container
— is a decision we want you to make and justify.
2. Kubernetes manifests
Helm chart or Kustomize overlays — your choice. Include at minimum:
• Deployment with appropriate replicas, probes, resource requests and limits, security
context, and graceful shutdown configuration.
• Service of the appropriate type (consider what LiveView needs to function correctly).
• HorizontalPodAutoscaler with scaling logic that fits the workload. Justify your choice of
scaling signal.
• PodDisruptionBudget tuned to the application’s tolerance for disruption — keeping in
mind that LiveView holds long-lived connections.
• ServiceAccount and any RBAC the workload actually needs.
• Any additional resources you decide are warranted (we leave this open intentionally).
3. Karpenter configuration
Provide NodePool and EC2NodeClass specs for this workload. We expect to see deliberate
choices about:
• Instance families and sizes, with reasoning.
• Capacity type strategy — on-demand, spot, or a weighted mix — and why that fits a
connection-holding workload.
• Consolidation policy and how it interacts with the application’s disruption tolerance.
• Any taints, tolerations, or affinity that you find warranted.
4. README
A README.md that explains your design. We read this carefully. Cover:
• How the production artifact is built and what runs inside the container.
• How a deploy or scale-down does not abruptly kill open WebSocket connections.
• Your choice of HPA signal and why CPU alone is or is not the right one here.
• Whether you addressed running the application as more than one replica, and what
implications that has for the application itself. If you deferred this, say so and explain.
• Why you chose the instance families and capacity types you did.
• GovCloud-specific considerations you accounted for or would account for in production.
• What you would add for production that you intentionally left out, and why.
• Anything you would do differently with more time.
5. Discovery log
A short section in the README (5 to 10 bullets is plenty) capturing what you did not know
coming into this assignment and how you figured it out. We want to see what you learned, what
surprised you, what you chose to investigate deeply, and what you chose to take on faith. This
is not a test of how little you can admit not knowing — the most useful submissions are honest
about both.
6. Optional bonus
• A short load-test plan, or a working load test, demonstrating scaling behavior under
bursty traffic.
• A custom-metrics HPA sketch using a signal more meaningful than CPU.
• A working multi-replica setup with the cross-pod implications addressed end-to-end.
Bonus items are genuinely optional. A strong core submission beats a sprawling one with
bonuses.
Constraints and Assumptions
• Target environment is AWS GovCloud (us-gov-west-1). You do not need to actually
deploy there; assume it as the target when making design choices.
• You do not need a live EKS cluster. Local kind or k3d is sufficient to verify that manifests
apply cleanly. Karpenter specs are evaluated as code, not by running them.
• You may use any tools you would normally use, including AI assistants and
documentation. We will discuss your choices in the walkthrough, so be ready to defend
them as your own.
• Prior Elixir or Phoenix experience is not expected. If you have it, great. If you do not, that
is the point — show us how you operate.