Prerequisites & resources - DevOps & Cloud Engineer simulation
Nothing to install and nothing to upload. Both tickets are answered in the browser: five questions and a written note each. No repository is submitted, no cluster is provisioned, and no code of yours is executed.
Everything needed is printed in the tickets - the pipeline definition, the rollout config, the pod and database metrics, the application log, the alert rules and a Terraform plan.
This one is harder than our fresher simulations
Most OneRoadmap simulations are pitched at someone applying for their first role. This one is Medium → Hard and assumes you have operated something, or studied as though you had. The difficulty is not obscure syntax - it is that several answers look defensible and only one manages the risk properly, and that the numbers have to be read rather than skimmed.
If you have not worked with containers, pipelines and cloud infrastructure before, the three portable certifications are the faster route in: Linux & Shell Fundamentals, Containers & Orchestration, and Cloud Fundamentals.
What you should already know
You do not need to have run a production platform. You need to read evidence carefully and reason about what a change does to a system that is already under load.
- Connection pools - that a pool belongs to a process, and what happens when the sum of the pools exceeds what the database will accept
- Rolling deployments - surge, unavailability, and why "the deploy succeeded" is not the same as "the release is healthy"
- Liveness vs readiness - which one decides restarts and which one decides traffic
- Rollback - when it is cheap, and what makes it stop being cheap
- Artifact promotion - why the thing you tested and the thing you deployed should be the same bytes
- Infrastructure as Code - desired state, drift, and how to read a plan that proposes to destroy something
- Observability - logs, metrics and traces, percentiles versus averages, and what makes an alert worth waking someone for
- Horizontal vs vertical scaling - and when adding instances makes a bottleneck worse
- Secret handling - why a credential in a log is disclosed rather than at risk
You do not need Kubernetes operator internals, service meshes, or any single cloud vendor's product names. Tools appear as recognisable examples; the reasoning is meant to transfer.
Reference material
Looking things up is expected. Nobody diagnoses an incident from memory.
- Kubernetes - Configure Liveness, Readiness and Startup Probes https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
- Kubernetes - Rolling updates https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
- PostgreSQL - Connections and Authentication (
max_connections) https://www.postgresql.org/docs/current/runtime-config-connection.html - PgBouncer - connection pooling https://www.pgbouncer.org/features.html
- Terraform - the plan command and resource replacement https://developer.hashicorp.com/terraform/cli/commands/plan
- Google SRE Book - Monitoring Distributed Systems (symptoms vs causes, and the four signals) https://sre.google/sre-book/monitoring-distributed-systems/
- Google SRE Workbook - Alerting on SLOs https://sre.google/workbook/alerting-on-slos/
- OWASP - Secrets Management Cheat Sheet https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
How you are marked
Each ticket is scored out of 100 and you need 70 to clear the simulation.
- DVO-101 - 60 points from the five questions (12 each), 40 from your incident note.
- DVO-102 - 50 points from the five questions (10 each), 50 from your action plan.
The questions have a fixed answer key. The written notes are read against a published rubric: an evaluator reports what your writing demonstrates, and the marks are calculated in code from that rubric. Length is never rewarded. A short note that names the constraint, the evidence and the next action scores above a long one that describes the incident back to us.