new wording for whats new and intro

new wording for whats new

applied PM suggestions and removed the comment out content

feature GA now so agreed with PM to commit

test

remove test

_topic_maps/_topic_map_rosa.yml

@@ -313,9 +313,8 @@ Topics:
   File: index
 - Name: Managing your cluster resources
   File: managing-cluster-resources
-# Removing until OSDOCS-10209 is GA
-#- Name: Approved Access
-#  File: approved-access
+- Name: Approved Access
+  File: approved-access
 - Name: Getting support
   File: getting-support
   Distros: openshift-rosa

rosa_release_notes/rosa-release-notes.adoc

@@ -18,10 +18,9 @@ toc::[]
 
 * **ROSA CLI update.** The ROSA CLI (`rosa`) was updated to a new version. For information about what has changed in this release, see the link:https://github.com/openshift/rosa/releases/tag/v1.2.41[ROSA CLI release notes]. For more information about the ROSA CLI (`rosa`), see xref:../cli_reference/rosa_cli/rosa-get-started-cli.adoc#rosa-about_rosa-getting-started-cli[About the ROSA CLI].
 
-// Removed until OSDOCS-10209 is GA - please note that xref is broken and in backticks because prow doesn't understand what comments are
-// * **Approved Access for ROSA clusters.** Red{nbsp}Hat Site Reliability Engineering (SRE) managing and proactively supporting ROSA Clusters will typically not require access to customer Data as part of the normal operations. In the unlikely event should Red{nbsp}Hat SRE (Site Reliability Engineer) need access to customer data, the _Approved Access_ functionality provides an interface for customers to review and _approve_ or _deny_ access requests.
-// +
-// Access requests to customer data on ROSA clusters and the corresponding cloud accounts can be created by Red{nbsp}Hat SRE either in response to a customer-initiated support ticket or in response to alerts received by a Red{nbsp}Hat SRE, as part of the standard incident response process. For more information, see `xref:` `../support/approved-access.adoc#approved-access[Approved Access]`. This is applicable to ROSA and Red{nbsp}Hat OpenShift Service on AWS (classic architecture).
+* **Approved Access for ROSA clusters.** Red{nbsp}Hat Site Reliability Engineering (SRE) managing and proactively supporting ROSA Clusters will typically not require elevated access to customer clusters as part of the normal operations. In the unlikely event should Red{nbsp}Hat SRE (Site Reliability Engineer) need elevated access, the _Approved Access_ functionality provides an interface for customers to review and _approve_ or _deny_ access requests.
++
+Elevated access requests to ROSA clusters and the corresponding cloud accounts can be created by Red{nbsp}Hat SRE either in response to a customer-initiated support ticket or in response to alerts received by a Red{nbsp}Hat SRE, as part of the standard incident response process. For more information, see xref:../support/approved-access.adoc#approved-access[Approved Access]. This is applicable to ROSA and Red{nbsp}Hat OpenShift Service on AWS (classic architecture).
 
 * **ROSA command enhancement.** The `rosa describe` command has a new optional argument, `--get-role-policy-bindings`. This new argument allows users to view the policies attached to STS roles assigned to the selected cluster. For more information, see xref:../cli_reference/rosa_cli/rosa-manage-objects-cli.adoc#rosa-describe-cluster_rosa-managing-objects-cli[describe cluster].
 

support/approved-access.adoc

@@ -9,9 +9,9 @@ endif::[]
 
 toc::[]
 
-Red{nbsp}Hat Site Reliability Engineering (SRE) typically does not require access to systems containing customer data as part of normal operations to manage and support {product-title} clusters. In the unlikely event that SRE needs access to systems containing customer data, you can use the _Approved Access_ interface to review and _approve_ or _deny_ access to these systems.
+Red{nbsp}Hat Site Reliability Engineering (SRE) typically does not require a elevated access to systems as part of normal operations to manage and support {product-title} clusters. In the unlikely event that SRE needs elevated access to systems, you can use the _Approved Access_ interface to review and _approve_ or _deny_ access to these systems.
 
-Access requests to customer data on {product-rosa} clusters and the corresponding cloud accounts can be created by SRE either in response to a customer-initiated support ticket or in response to alerts received by SRE as part of the standard incident response process.
+Elevated access requests to clusters on {product-rosa} clusters and the corresponding cloud accounts can be created by SRE either in response to a customer-initiated support ticket or in response to alerts received by SRE as part of the standard incident response process.
 
 When _Approved Access_ is enabled and an SRE creates an access request, _cluster owners_ receive an email notification informing them of a new access request. The email notification contains a link allowing the cluster owner to quickly approve or deny the access request. You must respond in a timely manner otherwise there is a risk to your SLA for {product-rosa}.
 
@@ -22,7 +22,6 @@ When _Approved Access_ is enabled and an SRE creates an access request, _cluster
 ====
 Denying an access request requires you to complete the *Justification* field. In this case, SRE can not directly act on the resources related to the incident. Customers can still use the link:https://access.redhat.com/support/cases/#/case/list[*Customer Support*] to help investigate and resolve any issues.
 ====
-// Approved access
 
 include::modules/support-submitting-a-case-enable-approved-access.adoc[leveloffset=+1]
 include::modules/support-reviewing-an-access-request-from-an-email-notification.adoc[leveloffset=+1]