Technical & Business Processes

Every process in this domain follows the same shape: a business or reliability objective is fixed first, and only then do you pick the mechanism that satisfies it at the lowest cost and effort. A disaster-recovery design starts from a recovery time objective (RTO, the maximum tolerable downtime) and a recovery point objective (RPO, the maximum tolerable data loss), and the architecture follows from those numbers, never the other way around. A delivery pipeline is judged against the four DORA keys (the DevOps Research and Assessment delivery metrics, defined in Technical Processes), not a hunch that it feels fast. A spend decision starts from "cost-optimal", meaning the cheapest option that still meets the requirement, not the cheapest option overall. The recurring exam trap is the answer that reaches for a tool before the objective is named, for example choosing a hot standby when the stated RTO permits a cheaper warm one, or capping spend with a budget when the requirement was actually to prevent overrun. Name the objective, then choose the mechanism that just meets it.

Technical processes covers how a change travels from a commit to production safely. Cloud Build runs continuous integration, building and testing the artifact in containers, and Cloud Deploy promotes that artifact across environments with release-time controls Cloud Build lacks, such as a required approval and one-command rollback. Validation is treated as a deploy-time gate too: Binary Authorization admits only attested container images. This half also owns disaster-recovery mechanics (the cold, warm, hot readiness spectrum) and governed self-service provisioning through Service Catalog. Business processes covers who decides a change is worth making and at what cost. It owns cost optimization as a continuous loop (sustained-use and committed-use discounts, rightsizing through Active Assist, Spot VMs for interruption-tolerant work), the CapEx-to-OpEx shift that makes spend a daily engineering concern, and the human side the exam tests deliberately: stakeholder management, change management, skills readiness, and matching a Customer Care support tier to the business need. The two halves meet at business continuity, where the business sets RTO and RPO and the technical half builds the DR posture that satisfies them.

The Well-Architected Framework cost optimization pillar names the default this domain rewards: align spend with business value, build a culture of cost awareness, optimize resource usage, and optimize continuously. Read across both halves, the same instinct decides ties. Prefer the option that is measured rather than assumed (DORA keys over gut feel, exported billing data over guesswork), continuous rather than one-time (a cost-optimization loop over a single cleanup, repeated DR drills over a written plan that is never tested), and just-enough rather than maximal (the cheapest DR posture and the leanest discount lever that meet the objective). When a managed service removes operational toil the team cannot otherwise carry, that is usually the architect's answer, because skills readiness is itself an architectural constraint.