Designing integration solutions to meet reliability requirements8% of the exam

High availability and disaster recovery by deployment

Separate high availability (surviving a component or zone failure with no loss of service) from disaster recovery (restoring to an acceptable earlier state within an RPO and RTO), then apply the standby types and the MuleSoft-versus-customer responsibility split on CloudHub 1.0, CloudHub 2.0, Runtime Fabric and customer-hosted runtimes.

Official exam objective
Differentiate between disaster recovery and high availability and the basic approaches to achieving either in all deployment options.

~8 min read · 7 practice questions

What the exam expects

  • Differentiate high availability from disaster recovery and record a business requirement as an RPO or an RTO.
  • Choose a cold, warm, hot or active-active standby from tolerated downtime, cost and control-plane dependence.
  • State what MuleSoft handles and what the customer owns on CloudHub 1.0, CloudHub 2.0, Runtime Fabric and customer-hosted runtimes.
  • Plan a DR design where the platform provides none.

High availability (HA): a system's ability to remain accessible when a component fails. Disaster recovery (DR): restoring a system to an acceptable previous state after a disaster. RPO: the maximum data loss a business accepts. RTO: the maximum downtime a business tolerates. Standby: how much of the backup environment runs before a disaster (HA and DR guide, CloudHub 2.0 HA and DR).

Sources for this section (2)

Key facts

RPO vs RTO
Detail
RPO: maximum data loss; RTO: maximum downtime.
99.9% uptime
Detail
10.1 minutes a week, 8.75 hours a year of downtime.
CloudHub 1.0 multi-worker
Detail
Separate AZs by default; single worker restarts elsewhere with downtime.
CloudHub 1.0 log buffer
Detail
Up to 1 GB while the control plane is unavailable.
CloudHub 2.0 replicas
Detail
Two or more AZs by default; restart in another AZ on failure.
Warm standby on CloudHub 2.0
Detail
Cannot start backups while the control plane is down.
Cold standby on CloudHub 2.0
Detail
Consumes no DR-region entitlements before the outage; longest RTO.
rtfctl backup scope
Detail
Cluster configuration only; not application state.
On-premises cluster across sites
Detail
Latency below 10 ms between nodes.
Sources for this section (5)
  • Why does HPA alone not keep Runtime Fabric replicas balanced across zones?
  • When the CloudHub 1.0 control plane is unavailable, how much log and telemetry data can a worker hold?
  • What does a cold standby mean for an on-premises deployment?
  • When does a CloudHub 2.0 hot standby still depend on the control plane during an outage?

The questions are free to read. Answers with their sources and self-grading are included with the pack.

Keep reading with the MuleSoft Platform Integration Architect pack

  • Core concepts
  • Exam traps
  • Worked scenario

The pack includes:

  • All 40 lessons of the MuleSoft Platform Integration Architect guide, with reading progress
  • Interactive decision walks and step-by-step sequence steppers
  • Practice exams purchase adds inline bank questions and topic practice (7 questions for this lesson)
  • An official source cited for every claim
  • An AI tutor that answers from the guide
  • Choose guide-only, practice-only, or save $4 with both

Practice for the MuleSoft Platform Integration Architect exam