What scenario can use the CloudHub Object Store connector to persist the cache’s state?

An organization is implementing a Quote of the Day API that caches today’s quote.

What scenario can use the CloudHub Object Store connector to persist the cache’s state?
A . When there is one deployment of the API implementation to CloudHub and another one to customer hosted mule runtime that must share the cache state.
B . When there are two CloudHub deployments of the API implementation by two Anypoint Platform business groups to the same CloudHub region that must share the cache state.
C . When there is one CloudHub deployment of the API implementation to three workers that must share the cache state.
D . When there are three CloudHub deployments of the API implementation to three separate
CloudHub regions that must share the cache state.

View Answer

Answer: C

Explanation:

Object Store Connector is a Mule component that allows for simple key-value storage.

Although it can serve a wide variety of use cases, it is mainly design for:

– Storing synchronization information, such as watermarks.

– Storing temporal information such as access tokens.

– Storing user information.

Additionally, Mule Runtime uses Object Stores to support some of its own components, for example:

– The Cache module uses an Object Store to maintain all of the cached data.

– The OAuth module (and every OAuth enabled connector) uses Object Stores to store the access and refresh tokens.

Object Store data is in the same region as the worker where the app is initially deployed. For example, if you deploy to the Singapore region, the object store persists in the Singapore region. MuleSoft Reference: https://docs.mulesoft.com/object-store-connector/1.1/ Data can be shared between different instances of the Mule application. This is not recommended for Inter Mule app communication. Coming to the question, object store cannot be used to share cached data if it is deployed as separate Mule applications or deployed under separate Business Groups. Hence correct answer is When there is one CloudHub deployment of the API implementation to three workers that must share the cache state.