@kensio/yulin 1.21.5 → 1.21.7

package/docs/services/cloudformation/README.md

@@ -1055,8 +1055,15 @@ simulated CloudFront hostname, such as `e123example.cloudfront.net`.
 #### Values from a skipped Resource
 
 A Resource that was skipped, because its type is outside the simulation or because there is no
-simulated Resource to create at all, still answers both intrinsics. `Ref` returns the logical ID, and
-`Fn::GetAtt` returns the string `<logical ID>.<attribute name>`.
+simulated Resource to create at all, still answers both intrinsics.
+
+What `Ref` answers with follows how far the refusal got. A service that had already worked out the
+Resource's name answers with that name. That is the name real CloudFormation would have produced,
+and the simulation holds it whether or not the Resource behind it was created. Sim Lambda declining
+a function on its `Runtime` is the case to know about, and it covers CDK's own Python providers. A
+Resource refused before any name existed answers with the logical ID.
+
+`Fn::GetAtt` answers with the string `<logical ID>.<attribute name>` for either of them.
 
 ```typescript sim-cloudformation-skipped-resource-values
 /**
@@ -1071,28 +1078,31 @@ const stack = await simAws.cloudFormation().deployTemplate({
   stackName: "stand-in-stack",
   template: {
     Resources: {
-      AlarmRule: {
-        Type: "AWS::CloudWatch::Alarm",
+      SearchApi: {
+        Type: "AWS::AppSync::GraphQLApi",
+        Properties: {
+          Name: "search",
+        },
       },
     },
     Outputs: {
-      AlarmRef: { Value: { Ref: "AlarmRule" } },
-      AlarmArn: { Value: { "Fn::GetAtt": ["AlarmRule", "Arn"] } },
+      SearchApiRef: { Value: { Ref: "SearchApi" } },
+      SearchApiArn: { Value: { "Fn::GetAtt": ["SearchApi", "Arn"] } },
     },
   },
 });
 
 await stack.waitForDeployComplete();
 
-console.log(stack.output("AlarmRef"));
-// "AlarmRule"
+console.log(stack.output("SearchApiRef"));
+// "SearchApi"
 
-console.log(stack.output("AlarmArn"));
-// "AlarmRule.Arn"
+console.log(stack.output("SearchApiArn"));
+// "SearchApi.Arn"
 
 for (const skipped of stack.skippedResources) {
   console.log(skipped.logicalId, skipped.skippedReason);
-  // "AlarmRule Unsupported sim CloudFormation Resource service CloudWatch"
+  // "SearchApi Unsupported sim CloudFormation Resource service AppSync"
 }
 ```
 
@@ -1101,7 +1111,7 @@ every Resource holding a `Ref` or `Fn::GetAtt` to a skipped Resource would fail
 every Resource depending on those, until one EventBridge rule took the whole stack down with it. The skip
 stays where it happened.
 
-A stand-in is deliberately shaped unlike an ARN. It fails closed wherever the simulator reads it.
+A logical ID is deliberately shaped unlike an ARN. It fails closed wherever the simulator reads it.
 
 - In an IAM policy `Resource` it matches no ARN, so a caller relying on that statement is denied.
 - In a property that is parsed as an ARN it is refused as malformed, and that Resource fails.
@@ -1112,9 +1122,58 @@ A stand-in is deliberately shaped unlike an ARN. It fails closed wherever the si
   SDK call fails the way a call for a missing resource does. A `PutItem` naming the skipped table
   gets `ResourceNotFoundException: No DynamoDB Table named Orders`.
 
-A stand-in stands in for something absent, and is never a value to rely on. A test asserting against
-one is asserting on a Resource that was never created. `stack.skippedResources` is where to find out
-which Resources those are and why, under
+A generated name behaves differently, and is meant to. It is the name an account would have held, so
+anything reading it reads a well-formed name. CDK writes a function's log group name as
+`/aws/lambda/` joined to a `Ref` of the function, and the log group is created under
+`/aws/lambda/<stack>-<logical ID>-<suffix>` even where the function was declined. A deploy Role
+scoped to `<stack>-*` and `/aws/lambda/<stack>-*` covers the deployment, the way it does on AWS.
+
+```typescript sim-cloudformation-skipped-resource-generated-name
+/**
+ * A function skipped on its Runtime, and the Log Group named after it.
+ */
+
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws();
+
+const stack = await simAws.cloudFormation().deployTemplate({
+  stackName: "ReportStack",
+  template: {
+    Resources: {
+      ReportFunction: {
+        Type: "AWS::Lambda::Function",
+        Properties: {
+          Role: "arn:aws:iam::111111111111:role/ReportRole",
+          Handler: "index.handler",
+          Runtime: "python3.13",
+          Code: { ZipFile: "def handler(event, context): return 'report'" },
+        },
+      },
+      ReportFunctionLogGroup: {
+        Type: "AWS::Logs::LogGroup",
+        Properties: {
+          LogGroupName: {
+            "Fn::Join": ["", ["/aws/lambda/", { Ref: "ReportFunction" }]],
+          },
+        },
+      },
+    },
+  },
+});
+
+await stack.waitForDeployComplete();
+
+console.log(stack.getResource("ReportFunction")?.refValue);
+// "ReportStack-ReportFunction-42d643ca8338"
+
+console.log(simAws.logs().allLogGroups()[0]?.logGroupName);
+// "/aws/lambda/ReportStack-ReportFunction-42d643ca8338"
+```
+
+The Resource is absent all the same, and the name is no evidence that it is there. Invoking the
+function above fails with `ResourceNotFoundException`. `stack.skippedResources` is where to find out
+which Resources were left out and why, under
 [Inspecting stacks and resources](#inspecting-stacks-and-resources).
 
 ### `Fn::Join`
@@ -3976,8 +4035,11 @@ const stack = await simAws.cloudFormation().deployTemplate({
           BucketName: "skipped-site-bucket",
         },
       },
-      AlarmRule: {
-        Type: "AWS::CloudWatch::Alarm",
+      SearchApi: {
+        Type: "AWS::AppSync::GraphQLApi",
+        Properties: {
+          Name: "search",
+        },
       },
     },
   },
@@ -3986,10 +4048,10 @@ const stack = await simAws.cloudFormation().deployTemplate({
 await stack.waitForDeployComplete();
 
 console.log(stack.skippedResources.map((resource) => resource.logicalId));
-// ["AlarmRule"]
+// ["SearchApi"]
 
-console.log(stack.getResource("AlarmRule")?.skippedReason);
-// "Unsupported sim CloudFormation Resource service CloudWatch"
+console.log(stack.getResource("SearchApi")?.skippedReason);
+// "Unsupported sim CloudFormation Resource service AppSync"
 ```
 
 A skipped Resource is still there for `stack.getResource(...)`, and still answers `Ref` and `Fn::GetAtt` with
@@ -4033,8 +4095,11 @@ const stack = await simAws.cloudFormation().deployTemplate({
           Description: "/opt/awscli/aws",
         },
       },
-      AlarmRule: {
-        Type: "AWS::CloudWatch::Alarm",
+      SearchApi: {
+        Type: "AWS::AppSync::GraphQLApi",
+        Properties: {
+          Name: "search",
+        },
       },
     },
   },
@@ -4043,7 +4108,7 @@ const stack = await simAws.cloudFormation().deployTemplate({
 await stack.waitForDeployComplete();
 
 console.log(stack.skippedResources.map((resource) => resource.logicalId));
-// ["AlarmRule"]
+// ["SearchApi"]
 
 console.log(stack.inertResources.map((resource) => resource.logicalId));
 // ["AwsCliLayer"]

package/docs/services/cloudfront/README.md

@@ -259,6 +259,11 @@ with a 200 for a URL the Bucket has no object for. It is one of the same error c
 CloudFront allows. Where the response page is itself missing, the viewer gets the status from
 fetching it, as in CloudFront.
 
+Behind an origin access control, a response page the Bucket does not hold answers 403 where a public
+Bucket answers 404. The Bucket policy an origin access control is written with grants `s3:GetObject`
+and no `s3:ListBucket`, and S3 refuses a key whose absence it may not report. A test whose Bucket
+was never loaded with the site's error page sees that refusal in place of the page.
+
 A viewer-response function never sees a custom error page. CloudFront runs no viewer-response
 function once the Origin has answered 400 or higher, and simulated CloudFront does the same, for a
 CloudFront Function and a Lambda@Edge function alike. The status the Origin returned is what decides
@@ -3781,6 +3786,110 @@ A CDK stack needs no hand-editing.
 other store. Handing back an empty store would let a Function that lost its association run to
 completion and quietly take every default.
 
+## Permissions
+
+Every CloudFront command goes through simulated IAM. So does every CloudFront Resource a
+CloudFormation Stack creates, decided as the principal the deployment runs as. Stand a project's own
+execution policy up as a deploy Role and the Stack finds out what the policy leaves out. A
+deployment naming no principal is decided as the Account root.
+
+The action is the `cloudfront:` name of the operation. A Distribution action is decided against
+`arn:aws:cloudfront::<account>:distribution/<id>`, a Function action against `function/<name>` and a
+key value store action against `key-value-store/<id>`. A create action has nothing to name until it
+succeeds and is decided against `*`. A policy granting one has to write the wildcard.
+
+These are the actions the simulation asks about:
+
+- `CreateDistribution`, `GetDistribution`, `UpdateDistribution` and `DeleteDistribution`
+- `CreateFunction`, `ListFunctions`, `DescribeFunction`, `GetFunction` and `DeleteFunction`
+- `CreateInvalidation`, `GetInvalidation` and `ListInvalidations`
+- `CreateKeyValueStore`, `ListKeyValueStores`, `DescribeKeyValueStore`, `UpdateKeyValueStore` and
+  `DeleteKeyValueStore`, alongside the data API's own `cloudfront-keyvaluestore:` actions on the
+  keys inside a store
+- `CreateCachePolicy` and `DeleteCachePolicy`
+- `CreateOriginRequestPolicy` and `DeleteOriginRequestPolicy`
+- `CreateResponseHeadersPolicy` and `DeleteResponseHeadersPolicy`
+- `CreateOriginAccessControl` and `DeleteOriginAccessControl`
+
+The last four pairs reach IAM through CloudFormation alone, since a template is the only way to make
+one of those four here. Each delete is decided against the ARN of the thing it names, such as
+`arn:aws:cloudfront::<account>:cache-policy/<id>`.
+
+```typescript sim-cloudfront-deploy-permissions
+/**
+ * A deploy Role refused the cache policy its Stack declares.
+ */
+
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws();
+
+// A deploy Role allowed CloudFormation and S3, and no CloudFront action.
+const { Role } = await simAws.iam().createRole({
+  input: {
+    RoleName: "DeployRole",
+    AssumeRolePolicyDocument: JSON.stringify({
+      Version: "2012-10-17",
+      Statement: [
+        {
+          Effect: "Allow",
+          Principal: { Service: "cloudformation.amazonaws.com" },
+          Action: "sts:AssumeRole",
+        },
+      ],
+    }),
+  },
+});
+
+await simAws.iam().putRolePolicy({
+  input: {
+    RoleName: "DeployRole",
+    PolicyName: "DeployPolicy",
+    PolicyDocument: JSON.stringify({
+      Version: "2012-10-17",
+      Statement: [
+        {
+          Effect: "Allow",
+          Action: ["cloudformation:*", "s3:*"],
+          Resource: "*",
+        },
+      ],
+    }),
+  },
+});
+
+try {
+  await simAws.cloudFormation().deployTemplate({
+    stackName: "site-stack",
+    caller: { kind: "arn", arn: Role.Arn },
+    template: {
+      Resources: {
+        SiteCachePolicy: {
+          Type: "AWS::CloudFront::CachePolicy",
+          Properties: {
+            CachePolicyConfig: {
+              Name: "site-caching",
+              MinTTL: 0,
+              ParametersInCacheKeyAndForwardedToOrigin: {
+                EnableAcceptEncodingGzip: false,
+                CookiesConfig: { CookieBehavior: "none" },
+                HeadersConfig: { HeaderBehavior: "none" },
+                QueryStringsConfig: { QueryStringBehavior: "none" },
+              },
+            },
+          },
+        },
+      },
+    },
+  });
+} catch (error) {
+  // Sim CloudFormation Resource SiteCachePolicy creation failed: User:
+  // arn:aws:iam::...:role/DeployRole is not authorized to perform:
+  // cloudfront:CreateCachePolicy on resource: *
+  console.log((error as Error).message);
+}
+```
+
 ## Available functionality
 
 Sim CloudFront currently supports:

package/docs/services/dynamodb/README.md

@@ -2443,6 +2443,123 @@ console.log(output.Responses[1]); // {}
 That is the difference from `BatchGetItem`, which leaves a missing item out of its answer
 altogether. Here the answers stay lined up with the Gets that asked for them.
 
+### Transactions through the document client
+
+`TransactWriteCommand` and `TransactGetCommand` from `@aws-sdk/lib-dynamodb` reach the same two
+operations. Every action's `Item`, `Key` and `ExpressionAttributeValues` are converted on the way in,
+and the `Item` of each `Responses` entry on the way out.
+
+```typescript sim-dynamodb-document-transactions
+/**
+ * Writing an order and the claim on its code together, in plain JavaScript.
+ */
+
+import { CreateTableCommand, DynamoDBClient } from "@aws-sdk/client-dynamodb";
+import {
+  DynamoDBDocumentClient,
+  TransactGetCommand,
+  TransactWriteCommand,
+} from "@aws-sdk/lib-dynamodb";
+
+import { SimSdk } from "@kensio/yulin/sdk";
+
+using simSdk = new SimSdk();
+
+const documents = DynamoDBDocumentClient.from(
+  new DynamoDBClient({ region: "eu-west-2" }),
+);
+simSdk.intercept(documents);
+
+for (const [tableName, keyName] of [
+  ["OrdersTable", "orderId"],
+  ["ClaimsTable", "code"],
+] as const) {
+  await documents.send(
+    new CreateTableCommand({
+      TableName: tableName,
+      KeySchema: [{ AttributeName: keyName, KeyType: "HASH" }],
+      AttributeDefinitions: [{ AttributeName: keyName, AttributeType: "S" }],
+      BillingMode: "PAY_PER_REQUEST",
+    }),
+  );
+}
+await simSdk.simAws.backgroundTasksComplete();
+
+const claim = {
+  TableName: "ClaimsTable",
+  ConditionExpression: "attribute_not_exists(code)",
+};
+
+// The order and the claim on its code go in together.
+await documents.send(
+  new TransactWriteCommand({
+    TransactItems: [
+      {
+        Put: {
+          TableName: "OrdersTable",
+          Item: { orderId: "order-1", total: 42, lines: [{ sku: "widget" }] },
+        },
+      },
+      { Put: { ...claim, Item: { code: "ABC123", orderId: "order-1" } } },
+    ],
+  }),
+);
+
+const read = await documents.send(
+  new TransactGetCommand({
+    TransactItems: [
+      { Get: { TableName: "OrdersTable", Key: { orderId: "order-1" } } },
+      { Get: { TableName: "ClaimsTable", Key: { code: "ABC123" } } },
+    ],
+  }),
+);
+
+const lines = read.Responses?.[0]?.Item?.["lines"] as { sku: string }[];
+console.log(lines[0]?.sku); // widget
+console.log(read.Responses?.[1]?.Item?.["orderId"]); // order-1
+
+// A second order wanting the same code loses the claim, and loses the order
+// with it.
+try {
+  await documents.send(
+    new TransactWriteCommand({
+      TransactItems: [
+        {
+          Put: {
+            TableName: "OrdersTable",
+            Item: { orderId: "order-2", total: 7 },
+          },
+        },
+        { Put: { ...claim, Item: { code: "ABC123", orderId: "order-2" } } },
+      ],
+    }),
+  );
+} catch (error) {
+  const cancelled = error as {
+    name: string;
+    CancellationReasons?: { Code: string }[];
+  };
+
+  console.log(cancelled.name); // "TransactionCanceledException"
+  console.log(cancelled.CancellationReasons?.map((reason) => reason.Code));
+  // ["None", "ConditionalCheckFailed"]
+}
+
+const second = await documents.send(
+  new TransactGetCommand({
+    TransactItems: [
+      { Get: { TableName: "OrdersTable", Key: { orderId: "order-2" } } },
+    ],
+  }),
+);
+
+console.log(second.Responses?.[0]); // {}
+```
+
+`CancellationReasons` arrive as the low-level Command reports them. There is one per action, in
+`TransactItems` order. A reason's `Item` holds AttributeValues, because a cancelled transaction is
+thrown, and the real document client converts nothing on the way out of a transactional write.
+
 ## Expiring items with time to live
 
 `UpdateTimeToLive` names the attribute a table expires items by, and `DescribeTimeToLive` reports
@@ -2930,8 +3047,11 @@ console.log(tags.has("priority")); // true
 ```
 
 `PutCommand`, `GetCommand`, `DeleteCommand`, `UpdateCommand`, `QueryCommand`, `ScanCommand`,
-`BatchWriteCommand` and `BatchGetCommand` are converted. A document Command with no route here, such
-as `TransactWriteCommand`, is refused by name before anything tries to convert its values.
+`BatchWriteCommand`, `BatchGetCommand`, `TransactWriteCommand` and `TransactGetCommand` are
+converted. The two transactional ones have
+[a section of their own](#transactions-through-the-document-client). A document Command with no route
+here, such as the PartiQL `ExecuteStatementCommand`, is refused by name before anything tries to
+convert its values.
 
 Intercept the document client itself. `DynamoDBDocumentClient.from(client)` builds a separate object
 outside the `DynamoDBClient` class, so intercepting the base client leaves Commands sent through the
@@ -3621,15 +3741,15 @@ Arn`, `Fn::GetAtt … StreamArn` and `Fn::GetAtt … TableId` answering. A CDK `
 - SDK interception, and an intercepted `DynamoDBClient` or `DynamoDBStreamsClient` reaches the
   simulation.
 - The `@aws-sdk/lib-dynamodb` document client, with `PutCommand`, `GetCommand`, `DeleteCommand`,
-  `UpdateCommand`, `QueryCommand`, `ScanCommand`, `BatchWriteCommand` and `BatchGetCommand`
-  converting native JavaScript values on the way in and out, and `paginateQuery` and `paginateScan`
-  paging through a simulated table.
+  `UpdateCommand`, `QueryCommand`, `ScanCommand`, `BatchWriteCommand`, `BatchGetCommand`,
+  `TransactWriteCommand` and `TransactGetCommand` converting native JavaScript values on the way in
+  and out, and `paginateQuery` and `paginateScan` paging through a simulated table.
 
 ## Limitations
 
-- The document client's transaction and PartiQL Commands go unconverted. PartiQL is an operation
-  this simulation lacks yet. The transactions are simulated as operations, so only the document form
-  of them is missing. Both are refused by name, never half converted.
+- The document client's PartiQL Commands go unconverted, because PartiQL is an operation this
+  simulation lacks yet. `ExecuteStatementCommand`, `BatchExecuteStatementCommand` and
+  `ExecuteTransactionCommand` are refused by name, never half converted.
 - A document client's translate config goes unread. The marshalling options it was built with do not
   apply. See [the SDK docs](https://yulinsim.dev/sdk/#limitations).
 - `Expected`, `ConditionalOperator`, `AttributeUpdates`, `KeyConditions`, `QueryFilter` and

package/docs/services/eventbridge/README.md

@@ -919,6 +919,12 @@ at deploy time naming the property and the Resource. The alternative is a rule t
 event where one field was asked for. Tearing the stack down removes the buses, rules and targets it
 created.
 
+`Tags` is the one difference from the commands, which refuse it outright. A template's tags are
+usually the whole stack's (a CDK app calling `Tags.of(app).add(...)` tags every rule and bus in it),
+and a rule routes the same events whether it carries them or not. They are recorded as an ignored
+property and the deploy stands. Nothing reads them back. A rule or a bus deployed with tags behaves
+as though the template had never named them.
+
 ## Reading back a failed delivery
 
 Real EventBridge tells the caller nothing about a failed delivery. A `PutEvents` that matched a rule
@@ -1101,7 +1107,8 @@ no permission for.
 - EventBridge Scheduler is a separate service, simulated separately. See
   [simulated Scheduler](https://yulinsim.dev/services/scheduler/).
 - Rule tags, a rule `RoleArn`, managed rules and the `ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS`
-  state are all refused.
+  state are all refused at `PutRule`. An `AWS::Events::Rule` carrying `Tags` deploys with the tags
+  dropped and the property recorded.
 - Deleting an event bus deletes its rules, and deleting a rule deletes its targets. Real EventBridge
   refuses to delete either while it still has what hangs off it.
 - `AWS::Events::EventBusPolicy`, `AWS::Events::Archive`, `AWS::Events::Connection` and
@@ -1113,6 +1120,7 @@ no permission for.
   stricter than real AWS.
 - Putting an event onto another account's or region's bus is refused.
 - Partner event buses and partner event sources are refused, as are event bus tags, encryption with
-  a customer managed key, dead letter queues, logging configuration and global endpoints.
+  a customer managed key, dead letter queues, logging configuration and global endpoints. An
+  `AWS::Events::EventBus` carrying `Tags` deploys with the tags dropped and the property recorded.
 - Archives, replay, schema registry and discovery, API destinations and connections are not
   simulated.

package/docs/services/iam/README.md

@@ -260,6 +260,11 @@ from the resolved caller and `aws:RequestedRegion` from the Region the request w
 service supplies under either name is overwritten by the derived one. Context-key names are matched
 case-insensitively, while string values remain case-sensitive.
 
+IAM's own requests carry two service keys. A Role handed to a service carries
+[`iam:PassedToService`](#passing-a-role-to-a-service), and a `CreateRole` request carries the
+boundary it declares as
+[`iam:PermissionsBoundary`](#creating-a-role-under-a-permissions-boundary).
+
 Every simulated service supplies its own Region. A policy conditioned on `aws:RequestedRegion`
 therefore sees the Region of the service that handled the request, whichever Region the caller was
 in, and a CloudFormation deployment carries the Region of the Stack it is deploying. IAM, CloudFront
@@ -1045,6 +1050,115 @@ await simAws.backgroundTasksComplete();
 A request naming no caller is decided as the Account root, which may pass any Role. A test that never
 mentions IAM keeps working.
 
+## Creating a Role under a permissions boundary
+
+An account that requires every Role to carry a permissions boundary allows `iam:CreateRole` only
+under `StringEquals` on `iam:PermissionsBoundary`. Its CloudFormation execution policy is written
+that way, and the CDK `PermissionsBoundary.fromName(...)` aspect puts the boundary ARN on every Role
+the app synthesizes. A `CreateRoleCommand` carrying `PermissionsBoundary` supplies the key, and
+`AWS::IAM::Role` supplies it from the template property of the same name.
+
+A request that leaves the property out leaves the key unset. A positive operator over an unset key
+matches nothing, and the guard refuses the Role. A request naming some other policy is refused the
+same way. A test can assert both refusals, and that is what makes the policy worth standing up as a
+deploy Role.
+
+`CreateRole` and `GetRole` then describe the boundary the Role carries, in the attachment shape IAM
+answers with (`PermissionsBoundaryType` and `PermissionsBoundaryArn`). `ListRoles` leaves the field
+out, as IAM does, and points a caller at `GetRole`. The boundary is not yet evaluated as a policy
+source of its own, and does not narrow what the Role may then do
+(see [Limitations](#limitations)).
+
+```typescript sim-iam-permissions-boundary
+/**
+ * Deploying into an account that requires a permissions boundary.
+ */
+
+import { GetRoleCommand } from "@aws-sdk/client-iam";
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws({ defaultAccountId: "123456789012" });
+const boundaryArn = "arn:aws:iam::123456789012:policy/DeveloperBoundary";
+
+const deployer = await simAws.iam().makeDeployRole({
+  roleName: "cfn-exec",
+  policyDocument: {
+    Version: "2012-10-17",
+    Statement: [
+      {
+        Effect: "Allow",
+        Action: "iam:CreateRole",
+        Resource: "*",
+        Condition: {
+          StringEquals: { "iam:PermissionsBoundary": boundaryArn },
+        },
+      },
+      {
+        Effect: "Allow",
+        Action: ["cloudformation:*", "iam:PutRolePolicy", "iam:PassRole"],
+        Resource: "*",
+      },
+    ],
+  },
+});
+
+const jobRoleTrust = {
+  Version: "2012-10-17",
+  Statement: {
+    Effect: "Allow",
+    Action: "sts:AssumeRole",
+    Principal: { Service: "lambda.amazonaws.com" },
+  },
+};
+
+const stack = await simAws.cloudFormation().deployTemplate({
+  stackName: "guarded-stack",
+  template: {
+    Resources: {
+      JobRole: {
+        Type: "AWS::IAM::Role",
+        Properties: {
+          RoleName: "JobRole",
+          PermissionsBoundary: boundaryArn,
+          AssumeRolePolicyDocument: jobRoleTrust,
+        },
+      },
+    },
+  },
+  caller: deployer,
+});
+
+// CREATE_COMPLETE
+console.log(stack.getResource("JobRole")?.status);
+
+const roleRead = await simAws
+  .iam()
+  .getRole(new GetRoleCommand({ RoleName: "JobRole" }));
+
+// arn:aws:iam::123456789012:policy/DeveloperBoundary
+console.log(roleRead.Role.PermissionsBoundary?.PermissionsBoundaryArn);
+
+try {
+  await simAws.cloudFormation().deployTemplate({
+    stackName: "unguarded-stack",
+    template: {
+      Resources: {
+        BareRole: {
+          Type: "AWS::IAM::Role",
+          Properties: {
+            RoleName: "BareRole",
+            AssumeRolePolicyDocument: jobRoleTrust,
+          },
+        },
+      },
+    },
+    caller: deployer,
+  });
+} catch (error) {
+  console.error("A Role declaring no boundary was refused", error);
+}
+```
+
 ## A Role for a CloudFormation deployment
 
 `makeDeployRole(...)` creates a Role from a policy document and hands back a caller. Pass it as
@@ -1241,6 +1355,11 @@ the logical ID when it is omitted, and inline `Policies` declared on a Role are
 Role's inline policies. The `ReadOnlyAccess` policy above is attached to `LambdaExecutionRole`.
 Authorization for that Role reads the policy document the template gave it.
 
+A Role's `PermissionsBoundary` reaches the authorization decision the deployment is made under, and
+is recorded on the Role it names.
+[Creating a Role under a permissions boundary](#creating-a-role-under-a-permissions-boundary) covers
+the guard it exists for.
+
 ### Users
 
 An `AWS::IAM::User` creates a User in the Stack's Account. `UserName` names it and falls back to the
@@ -1534,6 +1653,8 @@ Sim IAM currently supports:
 - IAM authorization at simulated service boundaries, such as Route53 actions
 - `iam:PassRole` authorization of a Role handed to simulated Lambda, Scheduler, EventBridge, Step
   Functions, ECS or Firehose, with `iam:PassedToService` supplied
+- `iam:CreateRole` authorization against `iam:PermissionsBoundary`, from the `PermissionsBoundary`
+  a request or an `AWS::IAM::Role` declares
 - Resolving the caller of an HTTP request, from an `x-sim-aws-caller` header or a verified SigV4
   signature, defaulting to anonymous, and the resource it is made on behalf of from
   `x-sim-aws-source-arn` and `x-sim-aws-source-account`
@@ -1551,8 +1672,10 @@ Sim IAM models the policy behaviour that multi-service tests most commonly need.
 
 - Groups are absent. An `AWS::IAM::User` naming one fails, and an `AWS::IAM::Policy` naming one
   fails too
-- Permissions boundaries and session policies are not evaluated. Service control policies are, and
-  are attached through [simulated Organizations](https://yulinsim.dev/services/organizations/ "Simulated Organizations service control policies usage docs")
+- Permissions boundaries and session policies are not evaluated. A boundary a `CreateRole` request
+  declares is authorized against `iam:PermissionsBoundary` and described by `GetRole`, and stops
+  there. Service control policies are evaluated, and are attached through
+  [simulated Organizations](https://yulinsim.dev/services/organizations/ "Simulated Organizations service control policies usage docs")
 - Managed Policies have a single version, and the policy version commands are absent
 - A policy document is measured against IAM's character limit one document at a time. The
   20,480-character cap on the sum of a User's inline policies is absent, and so is the cap on how

package/docs/services/lambda/README.md

@@ -1702,6 +1702,10 @@ Reporting individual failures can be tested against a made event too. The handle
 a template naming one is refused. The same Resource deploys a
 [stream mapping](#stream-mappings-in-templates), which has to have one.
 
+`Tags` is the one property recorded rather than refused. A template's tags are usually the whole
+stack's (a CDK app calling `Tags.of(app).add(...)` tags every mapping in it), and a mapping delivers
+the same records whether it carries them or not. The deploy stands and nothing reads them back.
+
 ## Triggering a function from a DynamoDB stream
 
 An event source mapping also connects a [simulated table's stream](https://yulinsim.dev/services/dynamodb/#capturing-changes-with-a-stream "Simulated DynamoDB streams docs")
@@ -4268,7 +4272,9 @@ Current documented limitations:
 - SQS queues, DynamoDB streams and Kinesis streams are the only event sources. Kafka, DocumentDB and
   Kinesis enhanced fan-out consumers are refused outright, and so are `FilterCriteria`,
   `ScalingConfig`, `DestinationConfig`, `BisectBatchOnFunctionError`, `ParallelizationFactor`,
-  `TumblingWindowInSeconds` and the other mapping inputs this simulation has no behaviour for.
+  `TumblingWindowInSeconds` and the other mapping inputs this simulation has no behaviour for. An
+  `AWS::Lambda::EventSourceMapping` carrying `Tags` is the exception, and deploys with the tags
+  dropped and the property recorded.
 - A failed stream batch waits 1, 2, 4, 8 and 16 seconds between attempts, where AWS documents no
   delay. That is deliberate. A delay of zero falls due at the instant the clock already reads, and a
   handler that always throws would leave `advanceBy` with work falling due forever. A mapping that