Introduction

This course uses a single evolving project to teach practical system administration in a way that forces you to operate real services: you’ll build and run a Minecraft server on AWS Academy and progressively increase maturity: from manual operations, to containerization, to infrastructure as code, to Kubernetes, to observability.

These assignments are not tutorials. They are specifications. Your job is to make defensible engineering decisions, document them, and prove that your system works under real operational conditions.

The Sequence

You will complete the following five milestones in order:

1. Ops 1: Manual Minecraft Server
2. Ops 2: Containerized Minecraft Server
3. Ops 3: Infrastructure Automation
4. Ops 4: Container Orchestration
5. Ops 5: Observability and Incident Response

Each assignment builds on the last. You are expected to carry forward working artifacts and improve them rather than starting over.

What We’re Evaluating

Across all five assignments, you will be graded on the same operator-grade themes:

• Correctness: the service runs and clients can connect.
• Security posture: least privilege, minimal exposure, reasonable defaults.
• Recoverability: backups exist, restores work, failures are survivable.
• Operational maturity: clear procedures, safe change practices, evidence-based troubleshooting.
• Documentation: someone else can operate your system using what you wrote.

Shared Constraints (AWS Academy)

You must assume a real cloud billing model and treat cost as a design constraint.

• Prefer small instances and justify instance sizing.
• Restrict administrative access (SSH from known IPs or SSM if available).
• Minimize public ports (only what is required for Minecraft and administration).
• Use IAM instance profiles instead of long-lived access keys on servers.
• Include a teardown or “stop resources” plan in every submission.

Note

If an AWS service required by an assignment is unavailable in your AWS Academy environment, document the limitation and implement the closest viable alternative with the same operational intent.

Submission Expectations

Each assignment is submitted as exactly two deliverables:

1. PDF: all written documentation for the assignment: design notes, architecture diagrams, runbooks, evidence (screenshots, command output, logs), and cost controls. For assignments that include code (Terraform, Ansible, Kubernetes manifests, CI/CD workflows), include a link to your GitHub repository in the PDF rather than attaching code separately.
2. Narrated screen recording (max 3 minutes): a walkthrough of the checkpoints listed in the assignment. Your server MOTD must include your name or student ID and must be visible in the recording. Submit timestamps alongside the video (e.g., “Checkpoint 1: 0:00, Checkpoint 2: 0:38, …”).

Your PDF should be complete enough for a TA or operator to understand your system without private context.

Collaboration and Integrity

• You may discuss approaches and troubleshoot with classmates.
• Your infrastructure code, automation, and documentation must be your own work unless explicitly approved as shared starter code.
• If you use external references, cite them in your design note. Indicate GenAI tools used and how they contributed to your work.