Planning, Design, and Configuration
Design questions reward candidates who translate business requirements into measurable technical targets before choosing products.
Requirements first
Start with who consumes the service, what availability it needs, and what data it handles. Convert vague goals into SLIs (the measurement, such as request success rate) and SLOs (the target, such as 99.9% over 30 days). Availability targets have a cost curve: each additional nine roughly multiplies redundancy and operational effort.
Recovery objectives
RPO is how much data you can afford to lose - it drives backup frequency and replication mode. RTO is how long you can be down - it drives architecture: warm standby, pilot light, active-active, or restore-from-backup. A design that meets an RTO of one hour cannot rely on restoring tapes from offsite storage.
Capacity and structure
Size for peak with headroom, not for the average, and state the assumption explicitly. Plan addressing and naming before deployment, because renumbering a live network is a migration project. Choose redundancy patterns (N+1, active-passive, active-active) and document the failure each one actually survives. Every design should include a configuration baseline so that drift is detectable later.
Traps
- Swapping RTO and RPO - memorise: RPO = data loss, RTO = downtime.
- Treating a backup as a disaster-recovery plan without testing restore time.
- Designing to a single SLO without identifying the dependency chain behind it.
Worked example
Business says: "We can lose at most 15 minutes of transactions and must be back within 2 hours." That sets RPO = 15 minutes (continuous or near-continuous replication, not nightly backups) and RTO = 2 hours (a warm standby that can be promoted, not a rebuild from scratch).