Update articles/azure-arc/kubernetes/conceptual-workload-management.md

Co-authored-by: JH <[email protected]>

Author: eedorenko

articles/azure-arc/kubernetes/conceptual-workload-management.md

@@ -213,7 +213,7 @@ A simple and flexible way to implement configuration composition is the label ma
 
 :::image type="content" source="media/concept-workload-management/label-matching-approach.png" alt-text="Diagram showing label matching configuration composition model." lightbox="media/concept-workload-management/label-matching-approach.png":::
 
-On this diagram, there are a few configuration containers grouping configuration values at different levels such as Site, Line, Environment, Region and so on. Depending on the organization, the values in these containers may be provided by different personas, such as IT Global, Site IT, Equipment owners or it may be just Platform team. Each container is marked with a set of labels that define where values from this container are applicable. Besides the configuration containers, there are abstractions representing an application and a host where the application is to be deployed. Both of them are marked with the labels as well. The combination of the application's and host's labels composes instance's labels set. This set determines values of what configuration containers should be pulled into the application configuration snapshot. This snapshot is delivered to the host and fed to the application instance. The control plane iterates over the containers and evaluates if the container's labels match the instance's labels set. If so, the container's values are included in the final snapshot, if not the container is skipped. The control plane can be configured with different strategies of overriding and merging for the complex objects and arrays.
+In this diagram, configuration containers group configuration values at different levels such as **Site**, **Line**, **Environment**, and **Region**. Depending on the organization, the values in these containers may be provided by different personas, such as IT Global, Site IT, Equipment owners, or just the Platform team. Each container is marked with a set of labels that define where values from this container are applicable. Besides the configuration containers, there are abstractions representing an application and a host where the application is to be deployed. Both of them are marked with the labels as well. The combination of the application's and host's labels composes the instance's labels set. This set determines the values of configuration containers that should be pulled into the application configuration snapshot. This snapshot is delivered to the host and fed to the application instance. The control plane iterates over the containers and evaluates if the container's labels match the instance's labels set. If so, the container's values are included in the final snapshot; if not, the container is skipped. The control plane can be configured with different strategies of overriding and merging for the complex objects and arrays.
 
 One of the biggest advantages of this approach is scalability. The structure of configuration containers is abstracted away from the application instance. It doesn't really know where the values are coming from. It lets easily manipulate the configuration containers, introduce new levels and configuration groups without reconfiguring hundreds of application instances.