Merging divergent mainline branches.

Author: KristinaPeterson

v2/guide/attributes.txt

@@ -2,3 +2,6 @@
 :arn-aws: pass:q[[.shared]``region.arn``]
 :aws: pass:q[[.shared]``AWS``]
 :aws-management-console: pass:q[[.shared]``consolelong``]
+
+:tcx5-2025-waiver: pass:[		 	 	 ]
+

v2/guide/best-practices-security.adoc

@@ -52,7 +52,7 @@ To configure the IAM identities in your {aws} account with permission to assume
 [source,json,subs="verbatim,attributes"]
 ----
 {
-  "Version": "2012-10-17",
+  "Version": "2012-10-17",{tcx5-2025-waiver}
   "Statement": [{
     "Sid": "AssumeCDKRoles",
     "Effect": "Allow",
@@ -130,4 +130,4 @@ If you want to work around this feature by replacing the automatically generated
 * A common workaround to using wildcards is to mandate that all resources be given a predictable name. However, this interferes with CloudFormation`'s ability to replace resources when necessary and may slow down or block development. Because of this, we recommend that you allow CloudFormation to create unique resource names for you.
 * It will be impossible to perform continuous delivery since manual actions must be performed prior to every deployment.
 
-When organizations want to prevent the CDK from creating roles, it is usually to prevent developers from being able to create IAM roles. The concern is that by giving developers permission to create IAM roles using the {aws} CDK, they could possibly elevate their own privileges. To mitigate against this, we recommend using  _permission boundaries_ or _service control policies (SCPs)_. With permission boundaries, you can set limits for what developers and the CDK are allowed to do. For more information on using permission boundaries with the CDK, see xref:customize-permissions-boundaries[Create and apply permissions boundaries for the {aws} CDK].
+When organizations want to prevent the CDK from creating roles, it is usually to prevent developers from being able to create IAM roles. The concern is that by giving developers permission to create IAM roles using the {aws} CDK, they could possibly elevate their own privileges. To mitigate against this, we recommend using  _permission boundaries_ or _service control policies (SCPs)_. With permission boundaries, you can set limits for what developers and the CDK are allowed to do. For more information on using permission boundaries with the CDK, see xref:customize-permissions-boundaries[Create and apply permissions boundaries for the {aws} CDK].

v2/guide/bootstrapping-env.adoc

@@ -257,7 +257,7 @@ When bootstrapping an {aws} environment, the IAM identity performing the bootstr
 [source,json,subs="verbatim,attributes"]
 ----
 {
-    "Version": "2012-10-17",
+    "Version": "2012-10-17",{tcx5-2025-waiver}
     "Statement": [
         {
             "Effect": "Allow",

v2/guide/hello-world.adoc

@@ -1176,7 +1176,7 @@ Resources:
             Effect: Allow
             Principal:
               Service: lambda.amazonaws.com
-        Version: "2012-10-17"
+        Version: "2012-10-17"{tcx5-2025-waiver}
       ManagedPolicyArns:
         - Fn::Join:
             - ""
@@ -1662,4 +1662,4 @@ For additional resources, see the following:
 * Visit https://constructs.dev/search?q=&cdk=aws-cdk&cdkver=2&sort=downloadsDesc&offset=0[Construct Hub] to discover constructs created by {aws} and others.
 * Explore https://github.com/aws-samples/aws-cdk-examples[Examples] of using the {aws} CDK.
 
-The {aws} CDK is an open-source project. To contribute, see to  https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md[Contributing to the {aws} Cloud Development Kit ({aws} CDK)].
+The {aws} CDK is an open-source project. To contribute, see to  https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md[Contributing to the {aws} Cloud Development Kit ({aws} CDK)].

v2/guide/serverless_example.adoc

@@ -1191,7 +1191,7 @@ Resources:
             Effect: Allow
             Principal:
               Service: lambda.amazonaws.com
-        Version: "2012-10-17"
+        Version: "2012-10-17"{tcx5-2025-waiver}
       ManagedPolicyArns:
         - Fn::Join:
             - ""
@@ -1596,4 +1596,4 @@ $ aws lambda invoke --function-name CdkHelloWorldStack-HelloWorldFunctionunique-
 If `output.txt` shows a successful Lambda function response, the issue could be with how you defined your API Gateway REST API. The {aws} CLI invokes your Lambda directly, not through your endpoint. Check your code to ensure it matches this tutorial. Then, deploy again.
 +
 *Possible cause: Lambda resource is defined incorrectly in your stack file*:::
-If `output.txt` returns an error, the issue could be with how you defined your Lambda function. Check your code to ensure it matches this tutorial. Then deploy again.
+If `output.txt` returns an error, the issue could be with how you defined your Lambda function. Check your code to ensure it matches this tutorial. Then deploy again.

v2/guide/testing.adoc

@@ -869,7 +869,7 @@ TypeScript::
       "{aws}::IAM::Role",
       Match.objectEquals({
         AssumeRolePolicyDocument: {
-          Version: "2012-10-17",
+          Version: "2012-10-17",{tcx5-2025-waiver}
           Statement: [
             {
               Action: "sts:AssumeRole",
@@ -898,7 +898,7 @@ JavaScript::
       "{aws}::IAM::Role",
       Match.objectEquals({
         AssumeRolePolicyDocument: {
-          Version: "2012-10-17",
+          Version: "2012-10-17",{tcx5-2025-waiver}
           Statement: [
             {
               Action: "sts:AssumeRole",
@@ -930,7 +930,7 @@ from aws_cdk.assertions import Match
         Match.object_equals(
             {
                 "AssumeRolePolicyDocument": {
-                    "Version": "2012-10-17",
+                    "Version": "2012-10-17",{tcx5-2025-waiver}
                     "Statement": [
                         {
                             "Action": "sts:AssumeRole",
@@ -962,7 +962,7 @@ Java::
         // Fully assert on the state machine's IAM role with matchers.
         template.hasResourceProperties("{aws}::IAM::Role", Match.objectEquals(
                 Collections.singletonMap("AssumeRolePolicyDocument", Map.of(
-                        "Version", "2012-10-17",
+                        "Version", "2012-10-17",{tcx5-2025-waiver}
                         "Statement", Collections.singletonList(Map.of(
                                 "Action", "sts:AssumeRole",
                                 "Effect", "Allow",
@@ -988,11 +988,11 @@ C#::
             {
                 { "AssumeRolePolicyDocument", new ObjectDict
                     {
-                        { "Version", "2012-10-17" },
+                        { "Version", "2012-10-17"{tcx5-2025-waiver} },
                         { "Action", "sts:AssumeRole" },
                         { "Principal", new ObjectDict
                             {
-                                { "Version", "2012-10-17" },
+                                { "Version", "2012-10-17"{tcx5-2025-waiver} },
                                 { "Statement", new object[]
                                     {
                                         new ObjectDict {
@@ -1551,4 +1551,4 @@ Don't copy and paste setup lines or common assertions. Instead, refactor this lo
 
 Don't try to do too much in one test. Preferably, a test should test one and only one behavior. If you accidentally break that behavior, exactly one test should fail, and the name of the test should tell you what failed. This is more an ideal to be striven for, however; sometimes you will unavoidably (or inadvertently) write tests that test more than one behavior. Snapshot tests are, for reasons we've already described, especially prone to this problem, so use them sparingly.
 
-include::testing-locally.adoc[leveloffset=+1]
+include::testing-locally.adoc[leveloffset=+1]