The scenario requires a storage mechanism that is shared across multiple CloudHub workers to synchronize state for "exactly once" processing. In a CloudHub deployment, the default Object Store (OSv2) is persistent and automatically shared among all workers assigned to a Mule application. This allows each worker to check for and store identifiers of processed records in a common, distributed location. Using the built-in Object Store connector is the most straightforward approach, satisfying the "minimal development effort" requirement for implementing an idempotent message validation pattern.

B. Runtime Fabric Object Store: This is incorrect because the question explicitly states the deployment target is CloudHub, not Runtime Fabric. These are distinct deployment models with different underlying architectures.

C. Non-persistent Object Store: A non-persistent (in-memory) object store is not shared across CloudHub workers. Each worker maintains its own separate in-memory store, making it impossible to synchronize state between them.

D. In-memory Mule Object Store: This is another term for a non-persistent object store and is incorrect for the same reason as option C; it is not distributed or shared across workers in a CloudHub cluster.

1. MuleSoft Documentation, "Object Store v2": "In CloudHub, the default object store for an application uses Object Store v2. This object store is persistent and is available to all workers of an application." This directly confirms that the persistent object store is shared across workers. The same document also states, "You can also create in-memory object stores that are not persistent and are available only to the worker where they are created," which invalidates the non-persistent options.

Source: MuleSoft Docs > Connectors > Object Store Connector > Object Store v2.

2. MuleSoft Documentation, "Idempotent Message Validator": This component is a primary use case for a shared object store to achieve "exactly once" processing. The documentation states, "The Idempotent Message Validator filter checks the value of an expression against a list of unique IDs from all previous messages. If the ID is new, the message is processed. If the ID is a duplicate, the message is discarded... The validator requires an object store to keep track of the IDs."

Source: MuleSoft Docs > Mule Runtime > Validation Module > Idempotent Message Validator.

3. MuleSoft Documentation, "Deploy to CloudHub": This documentation describes the architecture of CloudHub applications, including the concept of deploying an application to one or more workers for scalability and reliability, which is the foundational context of the question.

Source: MuleSoft Docs > CloudHub > Deploy to CloudHub.