Epic Goal

When Policy controls a Kubernetes resource, the configuration controller will overwrite data based on the desired config of the policy itself.
- It can also merge...
In particular, when Policy interacts with a ConfigMap, it cannot parse structured data (e.g. YAML) that is stored as a string in a ConfigMap field. Instead, it will overwrite all of the data.
This leads to problems when an Operator, for example the Multicluster Observability Operator, needs to update the structured data stored as a string in the ConfigMap and meanwhile there is a control in place via a Policy, the Operator will apply its changes but then a Policy will overwrite it with what's defined in the policy.

Why is this important?

We need a consistent approach to create/update/maintain a ConfigMap with structured data stored as a string, given that there are some bad practices out there, we are looking for ACM Policy to be a unifier in this space.

CI - MUST be running successfully with tests automated
Release Technical Enablement - Provide necessary release enablement details and documents.
ACM ZTP deployment should be able to play well with MulticlusterObservability Operator

CI - CI is running, tests are automated and merged.
Release Enablement <link to Feature Enablement Presentation>
DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
DEV - Downstream build attached to advisory: <link to errata>
QE - Test plans in Polarion: <link or reference to Polarion>
QE - Automated tests merged: <link or reference to automated tests>
DOC - Downstream documentation merged: <link to meaningful PR>

is triggered by

OCPBUGS-1025 [tracker]cluster-monitoring-config race condition between Observability and du profile