improve docs (#823)

Author: Brian969

docs/installation/installation.md

@@ -333,7 +333,9 @@ Issues in Older Releases:
 **Release Specific Upgrade Considerations:**
 
 - Upgrades to `v1.3.9 and above` from `v1.3.8-b and below`:
-  - Requires the removal of any interface endpoints containing a period (sub-domain) either before or during the upgrade process (ecr.dkr, ecr.api, transfer.server, sagemaker.api, sagemaker.runtime in the full config.json example)
+  - All interface endpoints containing a period must be removed from the config.json file either before or during the upgrade process 
+    - i.e. ecr.dkr, ecr.api, transfer.server, sagemaker.api, sagemaker.runtime in the full config.json example
+    - If you remove them on a pre-upgrade State Machine execution, you can put them back during the upgrade, if you remove them during the upgrade, you can put them back post upgrade.
 - Upgrades to `v1.3.3 and above` from `v1.3.2 and below`:
   - Requires mandatory config file schema changes as documented in the [release notes](https://github.com/aws-samples/aws-secure-environment-accelerator/releases).
     - These updates cause the config file change validation to fail and require running the state machine with the following input to override the validation checks on impacted fields: `{"scope": "FULL", "mode": "APPLY", "configOverrides": {"ov-ou-vpc": true, "ov-ou-subnet": true, "ov-acct-vpc": true }}`

reference-artifacts/SAMPLE_CONFIGS/sample_snippets.md

@@ -33,19 +33,26 @@ In vpc section, under interface endpoints:
 
 ---
 
-## - Create a role with trust policies
+## - Cross Account Role Example with trust policies (trust policies not supported until v1.5.0+)
 
 ```
 {
             "role": "Demo-Role",
-            "type": "other",
+            "type": "account",
             "policies": ["AdministratorAccess"],
             "boundary-policy": "Default-Boundary-Policy",
             "source-account": "operations",
-            "source-account-role": "TempAdmin",
-            "trust-policy": "none"
+            "source-account-role": "Admin",
+            "trust-policy": "role-trust-policy.txt"
 }
 ```
+Notes:
+- if "source-account" and "source-account-role" are specified, a cross-account role will be created
+- "type" can be any value if "source-account" and "acource-account-role" are specified (not used, but required)
+- "type" is the AWS service name if creating a service role (i.e. ec2)
+- "trust-policy" is only applied to cross-account roles and not service roles
+- the trust policy is interpreted, not all custom trust policy values may be implemented
+  - for example, we always use the action sts:AssumeRole
 
 ---
 
@@ -344,20 +351,7 @@ This is typically only deployed in the perimeter account, but could be used else
 
 ---
 
-## - Cross Account Role Example
-
-```
-          {
-            "role": "Test-Role",
-            "type": "account",
-            "policies": ["AdministratorAccess"],
-            "boundary-policy": "Default-Boundary-Policy",
-            "source-account": "security",
-            "source-account-role": "AWSLandingZoneSecurityAdministratorRole",
-            "trust-policy": "role-trust-policy.txt"
-          }
-```
-
+xx
 ---
 
 ## - Very basic workload account example and "per account" exceptions example