edits

Author: anupras-mohapatra-arm

content/learning-paths/servers-and-cloud-computing/rafay-eks/_index.md

@@ -12,12 +12,12 @@ who_is_this_for: >
 learning_objectives:
     - Connect your AWS account to the Rafay platform using a cross-account IAM role
     - Provision an Amazon EKS cluster with an AWS Graviton-based node group using Rafay
-    - Deploy and verify NGINX on arm64 nodes and clean up all cloud resources
+    - Deploy and verify workloads on arm64 nodes and clean up all cloud resources
 
 prerequisites:
-    - An Amazon Web Services (AWS) [account](https://aws.amazon.com/)
-    - A [Rafay account](https://rafay.co)
-    - The [AWS CLI](/install-guides/aws-cli/) installed and configured
+    - An Amazon Web Services (AWS) [account](https://aws.amazon.com/) with sufficient IAM permissions to create roles, EKS clusters, EC2 instances, CloudFormation stacks, and related resources.
+    - A [Rafay account](https://rafay.co).
+    - The [AWS CLI](/install-guides/aws-cli/) installed and configured.
 
 # START generated_summary_faq
 generated_summary_faq:
@@ -49,7 +49,7 @@ generated_summary_faq:
   - question: Which fields in the Rafay cluster manifest must match existing configuration?
     answer: >-
       The project, blueprint name and version, and the cloud credential must already exist in
-      Rafay. If any of these do not match, the cluster won't be created.
+      Rafay. If any of these don't match, the cluster won't be created.
   - question: What result should I expect when the EKS cluster is ready to use?
     answer: >-
       A running cluster with a Graviton-based (`arm64`) node group will be available for workloads.
@@ -60,7 +60,7 @@ generated_summary_faq:
       The provided manifest pins the pods using `nodeSelector: kubernetes.io/arch: arm64`. After
       deployment, the pod should schedule and run on nodes labeled `arm64`. If it remains `Pending`,
       verify the node group is active and the selector matches node labels.
-  - question: What should I cleanup to avoid ongoing AWS charges?
+  - question: What should I clean up to avoid ongoing AWS charges?
     answer: >-
       Delete the NGINX workload and namespace created for the test, then deprovision the EKS cluster
       from Rafay. This releases the associated AWS resources.

content/learning-paths/servers-and-cloud-computing/rafay-eks/cluster.md

@@ -1,5 +1,5 @@
 ---
-title: Create an Amazon EKS cluster
+title: Create an Amazon EKS cluster using a Rafay cluster manifest
 description: Create and apply a Rafay cluster manifest to provision an Amazon EKS cluster with an AWS Graviton-based node group, then download kubeconfig and verify the nodes report arm64.
 weight: 3
 
@@ -83,10 +83,10 @@ spec:
 
 Key fields to note:
 
-- `cloudCredentials` — must exactly match the credential name you entered in the Rafay console
-- `project` - must be the project you attached the credential to
-- `instanceType: m7g.large` — a Graviton3-based instance with Arm Neoverse processors
-- `publicAccess: false` — the Kubernetes API server has no public endpoint. You reach the cluster exclusively through RCTL, which routes traffic through the Rafay control plane.
+- `cloudCredentials` must exactly match the credential name you entered in the Rafay console.
+- `project` must be the project you attached the credential to.
+- `instanceType` must be a Graviton-based EC2 instance type with Arm Neoverse processors. In this manifest, it's Graviton3-based `m7g.large`.
+- `publicAccess` must be `false`. The Kubernetes API server has no public endpoint. You reach the cluster exclusively through RCTL, which routes traffic through the Rafay control plane.
 
 ## Apply the cluster manifest
 

content/learning-paths/servers-and-cloud-computing/rafay-eks/nginx.md

@@ -162,5 +162,5 @@ rctl delete cluster demo-eks-graviton
 
 You've now deployed NGINX using a manifest that pins pods to `arm64` nodes, verified the pod reaches a `Running` state, and tested connectivity from inside the cluster. You then cleaned up all provisioned resources.
 
-Rafay's control plane handles cluster access without requiring a public Kubernetes API endpoint, making it straightforward to run private, Graviton-based EKS clusters at scale.
+Rafay's control plane handles cluster access without requiring a public Kubernetes API endpoint, so you can use Rafay to run private, Graviton-based EKS clusters at scale.
 

content/learning-paths/servers-and-cloud-computing/rafay-eks/setup.md

@@ -16,7 +16,7 @@ In this Learning Path, you'll use Rafay to provision an Amazon EKS cluster with
 You need the following accounts and tools before starting this Learning Path:
 
 - An [AWS account](https://aws.amazon.com/) with sufficient IAM permissions to create roles, EKS clusters, EC2 instances, CloudFormation stacks, and related resources.
-- A [Rafay account](https://console.rafay.dev). You can [sign up](https://console.rafay.dev/#/signup) if you do not have an account.
+- A [Rafay account](https://console.rafay.dev). You can [sign up](https://console.rafay.dev/#/signup) if you don't have an account.
 - The AWS CLI installed and configured with credentials that have the required permissions. For setup instructions, see the [AWS CLI](/install-guides/aws-cli/) and the [AWS Credentials](/install-guides/aws_access_keys/) install guides.
 
 Confirm your AWS CLI is working by running the following command, which prints your account and user information:
@@ -27,7 +27,7 @@ aws sts get-caller-identity
 
 ## Install kubectl
 
-Install the Kubernetes command-line tool, by following the [kubectl install guide](/install-guides/kubectl/).
+Install the Kubernetes command-line tool by following the [kubectl install guide](/install-guides/kubectl/).
 
 Confirm the installation:
 
@@ -114,8 +114,8 @@ The output lists your account information, including the endpoints, keys, projec
 
 Rafay provisions EKS resources in your AWS account using a cross-account IAM role. You need two values from the Rafay console before running the script:
 
-1. Log in to the Rafay console
-2. Select **defaultproject** (or another project) from the project selector in the top navigation bar
+1. Log in to the Rafay console.
+2. Select **defaultproject** (or another project) from the project selector in the navigation bar.
 3. Navigate to **Infrastructure** > **Cloud Credentials** > **New Credential**.
 4. Select **AWS** as the provider, then select **ROLE**. Copy the **Rafay Account ID** and **External ID** displayed on the screen. You'll pass these values to the script that follows.
 
@@ -427,20 +427,20 @@ Attaching inline policy to role
 Role ARN (copy this value into the Rafay console):
 arn:aws:iam::111122223333:role/Proj-RafayEKSProvisioner
 ```
-The `Account ID`, `External ID`, and `Role ARN` are sample values.
+The `Account ID`, `External ID`, and `Role ARN` in this output are sample values.
 
 Copy the `Role ARN` from the output.
 
 ## Register the cloud credential in Rafay
 
 With the `Role ARN` copied, complete the credential registration in the Rafay console:
 
-1. Return to **Infrastructure** > **Cloud Credentials** > **New Credential** in the Rafay console
+1. Return to **Infrastructure** > **Cloud Credentials** > **New Credential** in the Rafay console.
 2. Paste the `Role ARN` into the **Role ARN** field.
 3. Enter `aws-cloud-credential` as the credential name.
 4. Select **Save**.
 
-![Screenshot of the Rafay console showing the cloud credential registration form with the AWS Role ARN field filled in #center](images/rafay-cloud-credential.webp "Registered AWS cloud credential in the Rafay console")
+![Screenshot of the Rafay Cloud Credentials page showing the aws-cloud-credential entry with provider AWS, credential type ROLE, and a masked RafayEKSProvisioner role detail#center](images/rafay-cloud-credential.webp "Registered AWS cloud credential in the Rafay console")
 
 ## What you've accomplished and what's next