Update config-policy-management-overview.adoc (#9438)

* Update config-policy-management-overview.adoc

Updated input.compiled to be input._compiled_

* correct escapes

---------

Co-authored-by: Rosie Yohannan <[email protected]>

Author: HennaAbbas

jekyll/_cci2/config-policy-management-overview.adoc

@@ -377,7 +377,7 @@ Writing policies for CircleCI `version 2.1` configuration introduces some challe
 
 Before executing any pipelines, config `version 2.1` is compiled into config `version 2.0`. This compilation expands all parameters and reusable config blocks (jobs, executors, commands, orbs) into workflows and jobs.
 
-To write highly effective policies, it is essential to reference the _compiled_ version of the config (`input.compiled`).
+To write highly effective policies, it is essential to reference the _compiled_ version of the config (`++input._compiled_++`).
 
 [#example]
 === Example
@@ -463,13 +463,13 @@ To resolve both of these issues, it is important to acknowledge that we want to
 ----
 # check all jobs in the compiled config and if any use a resource_class equal to "large" return a violation message.
 enforce_not_large_resource[reason] {
-  some job_name, job in input.compiled.jobs
+  some job_name, job in input._compiled_.jobs
   job.resource_class == "large"
   reason = sprintf("job %s using banned large resource class", [job_name])
 }
 ----
 
-Notice the rule now validates `input.compiled.jobs`. Regardless of parameters or reusable blocks (executors in this example), the policy is applied to all compiled jobs and functions as intended.
+Notice the rule now validates `++input._compiled_.jobs++`. Regardless of parameters or reusable blocks (executors in this example), the policy is applied to all compiled jobs and functions as intended.
 
 [#policing-config-constructs]
 === Policing config 2.1 constructs
@@ -512,7 +512,7 @@ orbs:
 
 In the above example, the rule does not raise a violation because the string `<< pipeline.parameters.evil_orb >>` does not have the `bad/` prefix that the policy aims to detect.
 
-We cannot rely on `input.compiled` because orbs are compiled away at that stage.
+We cannot rely on `++input._compiled_++` because orbs are compiled away at that stage.
 
 The best approach here is to detect if an orb reference is a parameterized expression and raise a violation accordingly. To do this we can use the `is_parameterized_expression` xref:config-policy-reference#is_parameterized_expression[helper].
 
@@ -549,13 +549,13 @@ Policies and their rules can be categorized into two main types:
 
 When working with configuration `version 2.1` constructs and parameterization, it is crucial to understand how these two rule types interact with your policies.
 
-* **Banlist** rules are susceptible to being bypassed using parameterization and reusable constructs. This is because the literal parameter value is unlikely to match the banned value, and during config compilation, the values intended to be banned can be reintroduced. All parameterization examples provided above fall into this category. To address this, you can either utilize `input.compiled` or detect parameterization and handle it appropriately.
+* **Banlist** rules are susceptible to being bypassed using parameterization and reusable constructs. This is because the literal parameter value is unlikely to match the banned value, and during config compilation, the values intended to be banned can be reintroduced. All parameterization examples provided above fall into this category. To address this, you can either utilize `++input._compiled_++` or detect parameterization and handle it appropriately.
 
 * **Allowlist** rules are incompatible with parameterization. They reject configurations that could otherwise be considered valid but do not cause invalid configurations to pass.
 
 Consider an example to illustrate this:
 
-NOTE: This example is artificial and for illustration purposes only. The appropriate policy for enforcing job resource classes should target the compiled input (`input.compiled`). This ensures proper validation against the resolved values.
+NOTE: This example is artificial and for illustration purposes only. The appropriate policy for enforcing job resource classes should target the compiled input (`++input._compiled_++`). This ensures proper validation against the resolved values.
 
 **Policy using an allowlist to restrict resource classes**
 [source,rego]