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

@@ -221,7 +221,7 @@ One of the biggest advantages of this approach is scalability. The structure of
 
 The control plane composes configuration snapshots for every application instance on every host. The variety of applications, hosts, the underlying technologies and the ways how applications are deployed can be very wide. Furthermore, the same application can be deployed completely differently on its way from dev to production environments. The concern of the control plane is to manage configurations, not to deploy. It should be agnostic from the underlying application/host technologies and generate configuration snapshots in a suitable format for each case. It can be a Kubernetes config map, properties file, Symphony catalog and so on.
 
-One way to do it is to assign different templates to different host types. These templates are used by the control plane when it generates configuration snapshots for the applications to be deployed on the host. It would be beneficial to apply a standard templating approach, which is well known in the developer community. For example, the following templates can be defined with the [Go Templates](https://pkg.go.dev/text/template), which are widely used across the industry:
+One option is to assign different templates to different host types. These templates are used by the control plane when it generates configuration snapshots for the applications to be deployed on the host. It would be beneficial to apply a standard templating approach, which is well known in the developer community. For example, the following templates can be defined with the [Go Templates](https://pkg.go.dev/text/template), which are widely used across the industry:
 
 ```yaml
 # Standard Kubernetes config map