In microservices architecture, where should the configurations for the services be stored?

Say I have services A, B and C that can perform long-running jobs are part of a larger workflow. In my system there are configurations per user that the services need to do their jobs per user. What I'm wondering is whether pieces of the configurations should be stored in each service or whether there should be a separate service X that deals with the configurations and overall workflow and plugs the pieces of the configurations into each service as it orchestrates the entire workflow.

More concretely, suppose for user 7020cf15-e5d4-433e-bfd3-ca7d529319a5 all the configurations look like

{
   foo: 99973618, // related to service A
   bar: 'Hello, world', // related to service B
   baz: [1, 2, 3] // related to service C
}

Should service A store

{
   userId: '7020cf15-e5d4-433e-bfd3-ca7d529319a5',
   foo: 99973618
}

and service B store

{
   userId: '7020cf15-e5d4-433e-bfd3-ca7d529319a5',
   bar: 'Hello, world'
}

and so forth? Or should there be a separate service X that stores

{
   userId: '7020cf15-e5d4-433e-bfd3-ca7d529319a5',
   foo: 99973618,
   bar: 'Hello, world',
   baz: [1, 2, 3]
}

and A, B, C don't store any configurations (although the services may be stateful and keep histories of the configurations that were inputted to them).

My intuition is in favor of the latter idea because

• It might not be the case that all the configurations can be categorized as belonging to a single service. There might be a configuration that spans the business domain of A and B.

• It is less complex to have everything in one place.

• When the overall workflow runs there is a fixed snapshot of the inputs that will be used.