Immediately after the new property values are applied in runtime manager, how is the current Mule application deployment affected and how will future web client requests to the Mule application be handled?

A mule application is deployed to a Single Cloudhub worker and the public URL appears in Runtime Manager as the APP URL.

Requests are sent by external web clients over the public internet to the mule application App url. Each of these requests routed to the HTTPS Listener event source of the running Mule application. Later, the DevOps team edits some properties of this running Mule application in Runtime Manager.

Immediately after the new property values are applied in runtime manager, how is the current Mule application deployment affected and how will future web client requests to the Mule application be handled?
A . Cloudhub will redeploy the Mule application to the OLD Cloudhub worker
New web client requests will RETURN AN ERROR until the Mule application is redeployed to the OLD Cloudhub worker
B . CloudHub will redeploy the Mule application to a NEW Cloudhub worker
New web client requests will RETURN AN ERROR until the NEW Cloudhub worker is available
C . Cloudhub will redeploy the Mule application to a NEW Cloudhub worker
New web client requests are ROUTED to the OLD Cloudhub worker until the NEW Cloudhub worker is available.
D . Cloudhub will redeploy the mule application to the OLD Cloudhub worker
New web client requests are ROUTED to the OLD Cloudhub worker BOTH before and after the Mule application is redeployed.

Answer: C

Explanation:

CloudHub supports updating your applications at runtime so end users of your HTTP APIs experience zero downtime. While your application update is deploying, CloudHub keeps the old version of your application running. Your domain points to the old version of your application until the newly uploaded version is fully started. This allows you to keep servicing requests from your old application while the new version of your application is starting.