Create an informative issue (See each section, incomplete templates/issues won't be triaged)

Using the current documentation as a model, please complete the issue template. 

Note: Doc team updates the current version and the two previous versions (n-2). For earlier versions, we will address only high-priority, customer-reported issues for releases in support.

Prerequisite: Start with what we have

Always look at the current documentation to describe the change that is needed. Use the source or portal link for Step 4:

 - Use the Customer Portal: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes

 - Use the GitHub link to find the staged docs in the repository: https://github.com/stolostron/rhacm-docs 

Describe the changes in the doc and link to your dev story

Provide info for the following steps:

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

2. - [x] Mandatory Choose the type of documentation change.

      - [x] New topic in an existing section or new section

Under Governance - Policy controllers introduction (https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.9/html/governance/governance#policy-controllers), the new content would likely be a new section like "Operator Policy controller (technical preview)"

      - [ ] Update to an existing topic

3. - [ ] Mandatory for GA content:
            
       - [ ] Add steps and/or other important conceptual information here: 

You can use the operator policy controller to monitor or install Operator Lifecycle Manager (OLM) operators across your clusters. You can monitor the health of various pieces of the operator, and you can specify how to automatically handle updates to the operator. You can distribute an operator policy to managed clusters using the governance framework by adding it to the `policy-templates` field of a policy on the hub cluster.

When the `remediationAction` for the operator policy is set to enforce, the controller will create resources on the target managed cluster to install the operator, and approve updates based on the versions specified in the policy. When it is set to inform, the controller will only report on the status of the operator, including whether any upgrades are available.

The primary field in an operator policy is `spec.subscription`, which must contain the information required to create an operator subscription. In particular, the "channel", "name", "namespace", "source", and "sourceNamespace" must be provided. For more information, see the OLM documentation (NOTE TO WRITER: I don't know the policy on references like this, but this doc is the kind of thing I would like to link to somehow: https://docs.openshift.com/container-platform/4.12/operators/understanding/olm/olm-understanding-olm.html#olm-subscription_olm-understanding-olm )

The `spec.versions` field in an operator policy can be used to declare which versions of the operator will be considered compliant. If the field is empty, then any version running on the cluster will be considered compliant. If any are specified, then the version on the cluster must exactly match one of the versions in the list in order for the policy to be compliant. When the policy is in "enforce" mode, it will only approve updates to versions that would be considered compliant.

1. subsection: Operator policy sample

```

apiVersion: policy.open-cluster-management.io/v1beta1
kind: OperatorPolicy
metadata:
  name: quay-policy
spec:
  remediationAction: inform
  severity: medium
  complianceType: musthave
  operatorGroup: # optional
    name: scoped-operator-group
    namespace: quay-opns
    targetNamespaces:
      - quay-opns
  subscription:
    channel: stable-3.10
    name: quay-operator
    namespace: quay-opns
    installPlanApproval: Automatic
    source: redhat-operators
    sourceNamespace: openshift-marketplace
  versions:
    - quay-operator.v3.10.3

```

(I don't know if a YAML table is required or helpful in the documentation. We have them for the other policies, but they don't seem to fully describe all of the fields. I think that the sample and summary are more helpful. But I can build a table if wanted.)

       - [ ] Add Required access level for the user to complete the task here:
       

       - [ ] Add verification at the end of the task, how does the user verify success (a command to run or a result to see?)
     
     
       - [x] Add link to dev story here: https://issues.redhat.com/browse/ACM-1156

4. - [ ] Mandatory for bugs: What is the diff? Clearly define what the problem is, what the change is, and link to the current documentation: