Note: Doc team updates the current version of the documentation and the
two previous versions (n-2), but we address *only high-priority, or
customer-reported issues* for -2 releases in support.
Describe the changes in the doc and link to your dev story:

1. - [X] Mandatory: Add the required version to the Fix version/s field.

ACM 2.16

2. - [X] Mandatory: Choose the type of documentation change or review.

• [X] We need to update to an existing topic

https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.15/html/gitops/gitops-overview#secret-gitops

1.4.4. Red Hat OpenShift GitOps token

• Update the second paragraph to this

The OpenShift GitOps controller needs this secret to sync resources to the managed cluster. By default, the service account application-manager works with the cluster administrator permissions on the managed cluster to generate the secure OpenShift GitOps cluster secret in the OpenShift GitOps instance server namespace. The default namespace is openshift-gitops.

• Then append a new paragraph after the second one

The secure OpenShift GitOps cluster secret in the OpenShift GitOps instance server namespace is rendered by the following priority orders

1. By cluster proxy service.

This is default option as the cluster-proxy addon is always enabled in MCE. The secure ArgoCD cluster secrets rendered by the cluster proxy service can be used in OCP and Non-OCP clusters. 

• server URL: The cluster-proxy URL for that managed cluster
• caData: The service CA from the openshift-service-ca ConfigMap in the managed cluster’s namespace for TLS

• bearer Token: the ManagedServiceAccount (MSA) application-manager token

2. By managed cluster client configs.

If cluster proxy is unavailable (e.g. the cluster-proxy addon is disabled in MCE),  the managed cluster’s own API server endpoint and CA are detected automatically. The secure ArgoCD cluster secrets rendered by the managed cluster client configs can only be used in OCP clusters. 

• Both server URL and caData are from the client configuration in the managed cluster specification.
• bearer Token is from the same ManagedServiceAccount (MSA) application-manager token

• [ ] We need to add a new document to an existing section

• [ ] We need a whole new section; this is a function not
  documented before and doesn't belong in any current section

• [ ] We need an Operator Advisory review and approval

• [ ] We need a z-Stream (Errata) Advisory and Release note for
  MCE and/or ACM

3. - [ ] Mandatory: Find the link to where the documentation update
should go and add it to the recommended changes. You can either use the
published doc or the staged repo for this step:

Note: As the feature and doc is understood, this recommendation may
change. If this is new documentation, link to the section where you think
it should be placed.

Customer Portal published version

https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12

Doc staged repo within the ACM Workspace:
https://github.com/stolostron/rhacm-docs

4. - [ ] Mandatory for GA content:

• [ ] Add steps, the diff, known issue, and/or other important
  conceptual information in the following space:

• [ ] *Add Required access level *(example, *Cluster
  Administrator*) for the user to complete the task:

• [ ] Add verification at the end of the task, how does the user
  verify success (a command to run or a result to see?)

• [ ] Add link to dev story here:

5. - [ ] Mandatory for bugs: What is the diff? Clearly define what the
problem is, what the change is, and link to the current documentation. Only
use this for a documentation bug.