OphirCloud Academy

60 days · 4 phases · 31 graded labs · 5 design briefs · $200

AI Platform Engineering Architecture

Build the platform an AI team actually runs on.

Four phases: the cloud-native baseline, infrastructure as code and orchestration, the GPU and network layer an inference platform needs, and whole-system design. Phases 1–2 are hands-on from day one; Phase 3 grades the manifests and policies you would apply to real accelerators; Phase 4 is design work against a rubric.

Start day 1Design briefsAll 31 labs

What runs in the sandbox

  • Linux, Git, networking, Docker and shell/Python labs — graded on real filesystem state.
  • Terraform and Kubernetes: parsed configuration and cluster objects, graded on state.
  • AWS compute, IAM and S3: the CLI writes a simulated account that the checks read back.
  • GPU serving manifests: image, model argument, accelerator request and Service.
  • The CI/CD workflow file itself — triggers, steps and what it applies.

What it cannot do

  • No GPU is provisioned. The scheduling request is graded; CUDA and the GPU operator are reading.
  • No VM boots, and nothing is pushed to a real registry or cloud account.
  • FSx for Lustre, EFA/RDMA and DCGM metrics are not simulated; the labs grade the policy around them.
  • No model weights are downloaded, so “serving” means the manifest is correct, not that tokens stream.
  • Phase 4 is not graded. The rubric is the check, and the drawing is yours.

Foundations & the control plane

Days 1–20

The cloud-native baseline every later phase assumes.

Compute: Linux, Docker and cloud sandboxes. The milestone registers a VM rather than booting one.

DaysTopicEnvironmentProve it
Days 1–3Pick an SDLC process, including the agentic variantA decision, not a keyboard skill — there is no graded lab. Write the process down; the criterion is that a new engineer could follow it.Reading + a written decision
No graded lab
Days 4–5Operating systems and Linux: files, permissions, processesLinux sandbox
Days 6–7Networking: TCP/IP, DNS, HTTP, load balancingLinux sandbox
Days 8–9Source control: branching, merging, pull requestsGit sandbox
Days 10–11Scripting: Bash first, then PythonLinux sandbox
Days 12–13Containers: images, containers, Docker ComposeDocker sandbox
Days 14–16Core cloud services: compute, storage, IAMCloud sandbox
Days 17–20Milestone: containerize an app and register it on a cloud VMThe sandbox grades the image and the instance/security-group record. It does not boot a VM or push the image to a registry.Docker + cloud sandbox

Core DevOps & orchestration

Days 21–40

Infrastructure as code, Kubernetes, pipelines and observability.

Compute: Terraform, Kubernetes and Git + terminal sandboxes. Nothing here needs a real cluster.

DaysTopicEnvironmentProve it
Days 21–25Terraform: provisioning infrastructure as codeTerraform sandbox
Days 26–31Kubernetes: pods, deployments, services, configK8s sandbox
Days 32–35CI/CD pipelines: GitHub Actions or GitLab CIGit + terminal
Days 36–38Monitoring and observability: Prometheus, Grafana, logsK8s sandbox
Days 39–40Milestone: automated CI/CD deployment to Kubernetes with TerraformOne lab spans all three: a namespace from Terraform, the workload in the cluster, and the workflow that redeploys on a tag. The runner is simulated — no job executes.Terraform + K8s + workflow file

AI infrastructure & specialised hardware

Days 41–50

The accelerator, storage and network layer an inference platform needs.

Compute: K8s and cloud sandboxes. No GPU is provisioned: these labs grade the scheduling request, the manifest, the storage policy and the network boundary.

DaysTopicEnvironmentProve it
Days 41–42GPU computing basics: CUDA architecture, NVIDIA GPU OperatorNo accelerator runs in the browser. The lab grades the GPU request a scheduler acts on; CUDA and the operator are reading.K8s sandbox
Days 43–44AI storage and data gravity: FSx for Lustre, MinIOS3 stands in for the object store. FSx/Lustre is reading — there is no parallel filesystem to mount.Cloud sandbox
Days 45–46AI networking: EFA, VPC topologiesEFAs and RDMA cannot be simulated. The lab grades the security-group boundary you would put around a training fleet.Cloud sandbox
Days 47–48Model serving and inference: vLLM, TritonThe Deployment, the model argument and the Service are graded. No weights are downloaded and no request is served.K8s sandbox
Day 49AI observability: DCGM exporter, TTFT, throughputThere are no GPU metrics here. The lab teaches the scrape-and-alert shape that the DCGM exporter feeds.K8s sandbox
Days 49–50AI security: model weight protection, secrets managementCloud + K8s sandbox
Day 50Milestone: serve an open-weight model on Kubernetes with vLLMThe two serving labs together are the milestone: request the GPU, then expose the OpenAI-compatible server.K8s sandbox

System design & whole systems

Days 51–60

Connecting the components at scale, on a whiteboard.

Compute: None. Design work, reviewed against a written rubric.

DaysTopicEnvironmentProve it
Days 51–53Core concepts: scalability, load balancing, caching, databases, queuesDesign brief
Days 54–55Design a URL shortenerDesign brief
Days 56–57Design a notification systemDesign brief
Days 58–59Design a file storage serviceDesign brief
Day 60Milestone: design an end-to-end LLM inference platformDesign brief

How to work through it

  1. Read the row's topic, then open the lab before reading anything else.
  2. Finish every activity. A lab is done when the checks pass against the sandbox state, not when the commands look right.
  3. Write down what the row cannot prove — for the GPU and network rows, that note is the interview answer.
  4. Phase 4: draw first, then check the drawing against the rubric, then redraw.

The syllabus is a map, not a certificate: nothing here is timed, and no row is signed off for you. A lab's green ticks are the only claim the product makes.

All labsWritten lessonsDesign briefs