@kensio/yulin 1.20.16 → 1.20.17

package/docs/services/cloudfront/README.md

@@ -1009,7 +1009,13 @@ A `viewer-response` Function runs for an Origin status below 400. CloudFront ski
 viewer-response event once the Origin has answered 400 or higher (see
 [Limitations](#limitations)), and so does this simulation.
 
-Use `makeCffFunctionCodeInput` to pass a JavaScript handler function to `CreateFunctionCommand`.
+Use `makeCffFunctionCodeInput` to pass a JavaScript handler function to `CreateFunctionCommand`, or
+[CloudFormation bindings](https://yulinsim.dev/services/cloudformation/#cloudfront-function-bindings "CloudFront Function bindings usage docs")
+to back a template Resource with one. A handler reference is what to reach for first. It stops on a
+breakpoint and can close over the test's own state. Publish the source itself where the test is
+about the code the Distribution carries, down to the 10 KB it has to fit in. A
+[Lambda@Edge](#simulated-lambdaedge) function is an ordinary simulated Lambda function, and the same
+choice covers it.
 
 The `host` header a function sees is the hostname the request was made to CloudFront with, being the
 Distribution domain name or one of its alternate domain names. Requests served on localhost arrive
@@ -1254,6 +1260,84 @@ service does. A test that deploys the Stack reports the overrun where the rest o
 ahead of `cdk deploy`. A handler passed as a function reference carries no source to count, and the
 limit leaves it alone.
 
+### Reading a Function back
+
+`ListFunctions` reports the Functions the Account holds. Each carries the `FunctionConfig` it was
+created with and the `FunctionMetadata` CloudFront gave it. `DescribeFunction` reports one by name,
+and `GetFunction` reports its code. A test that wants to know which Function a stack deployed, and
+on which runtime, asks one of these.
+
+```typescript sim-cloudfront-function-read
+/**
+ * Reading a deployed CloudFront Function back.
+ */
+
+import {
+  CreateFunctionCommand,
+  DescribeFunctionCommand,
+  GetFunctionCommand,
+  ListFunctionsCommand,
+} from "@aws-sdk/client-cloudfront";
+
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws();
+const simCloudFront = simAws.cloudFront();
+
+await simCloudFront.createFunction(
+  new CreateFunctionCommand({
+    Name: "beacon",
+    FunctionConfig: {
+      Comment: "Answers the analytics beacon",
+      Runtime: "cloudfront-js-2.0",
+    },
+    FunctionCode: Buffer.from(`
+      function handler(event) {
+        return { statusCode: 204, statusDescription: "No Content" };
+      }
+    `),
+  }),
+);
+
+// CloudFront publishes a new Function in the background.
+await simAws.backgroundTasksComplete();
+
+const listed = await simCloudFront.listFunctions(new ListFunctionsCommand({}));
+
+// cloudfront-js-2.0
+console.log(listed.FunctionList.Items[0]?.FunctionConfig.Runtime);
+
+const described = await simCloudFront.describeFunction(
+  new DescribeFunctionCommand({ Name: "beacon", Stage: "LIVE" }),
+);
+
+// Answers the analytics beacon
+console.log(described.FunctionSummary.FunctionConfig.Comment);
+
+const got = await simCloudFront.getFunction(
+  new GetFunctionCommand({ Name: "beacon" }),
+);
+
+// The source the Function was created with.
+console.log(Buffer.from(got.FunctionCode).toString());
+```
+
+`Stage` picks the copy to read. A Function is created into `DEVELOPMENT` and reaches `LIVE` once
+CloudFront has published it, and an omitted `Stage` means `DEVELOPMENT`, as it does on AWS. Asking
+for the `LIVE` copy of a Function still waiting to publish fails with `NoSuchFunctionExists`, and so
+does a name the Account holds no Function under.
+
+`CreatedTime` and `LastModifiedTime` come off the simulated clock. Freezing time before the deploy
+pins both to an instant the test picked (see
+[Controlling simulated time](https://yulinsim.dev/time/ "Simulated time usage docs")).
+
+A Function backed by a handler function reference was given no source to keep. `GetFunction` answers
+with that handler's own source text. That is the code the Function runs.
+
+The whole list comes back. `Marker` and `MaxItems` paging is left out, matching the paging left out
+of the other simulated listings. `UpdateFunction`, `PublishFunction` and `TestFunction` are not
+simulated.
+
 ### Calling a Function handler without a Distribution
 
 A test of the handler on its own, with no Distribution in front of it, still has to pass it a whole
@@ -2107,6 +2191,139 @@ Behavior is recorded under its `PathPattern`, the way a skipped Lambda@Edge asso
 `CreateDistribution` and `UpdateDistribution` still refuse the same ID, as real CloudFront refuses
 it.
 
+## Cache policies
+
+A cache policy decides what a cache Behavior keys its cache on and how long an object stays there.
+Declare one as `AWS::CloudFront::CachePolicy` and point a Behavior's `CachePolicyId` at it with a
+`Ref`, which is what CDK's `CachePolicy` construct synthesizes.
+
+```typescript sim-cloudfront-cache-policy
+/**
+ * Reading back the cache policy a Behavior was given.
+ */
+
+import { GetDistributionCommand } from "@aws-sdk/client-cloudfront";
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws();
+
+const stack = await simAws.cloudFormation().deployTemplate({
+  stackName: "site-stack",
+  template: {
+    Resources: {
+      SiteBucket: {
+        Type: "AWS::S3::Bucket",
+        Properties: { BucketName: "site-bucket" },
+      },
+      BeaconPolicy: {
+        Type: "AWS::CloudFront::CachePolicy",
+        Properties: {
+          CachePolicyConfig: {
+            Name: "BeaconPolicy",
+            MinTTL: 0,
+            DefaultTTL: 0,
+            MaxTTL: 0,
+            ParametersInCacheKeyAndForwardedToOrigin: {
+              EnableAcceptEncodingGzip: false,
+              CookiesConfig: { CookieBehavior: "none" },
+              HeadersConfig: { HeaderBehavior: "none" },
+              QueryStringsConfig: { QueryStringBehavior: "none" },
+            },
+          },
+        },
+      },
+      SiteDistribution: {
+        Type: "AWS::CloudFront::Distribution",
+        DependsOn: ["SiteBucket", "BeaconPolicy"],
+        Properties: {
+          DistributionConfig: {
+            DefaultRootObject: "index.html",
+            Origins: [
+              {
+                Id: "SiteOrigin",
+                DomainName: "site-bucket.s3.amazonaws.com",
+                S3OriginConfig: {},
+              },
+            ],
+            DefaultCacheBehavior: {
+              TargetOriginId: "SiteOrigin",
+              ViewerProtocolPolicy: "allow-all",
+              // CachingOptimized, one of CloudFront's managed policies.
+              CachePolicyId: "658327ea-f89d-4fab-a63d-7e88639e58f6",
+            },
+            CacheBehaviors: [
+              {
+                PathPattern: "/beacon",
+                TargetOriginId: "SiteOrigin",
+                ViewerProtocolPolicy: "allow-all",
+                CachePolicyId: { Ref: "BeaconPolicy" },
+              },
+            ],
+          },
+        },
+      },
+    },
+    Outputs: {
+      DistributionId: { Value: { Ref: "SiteDistribution" } },
+      BeaconPolicyId: { Value: { Ref: "BeaconPolicy" } },
+    },
+  },
+});
+
+await stack.waitForDeployComplete();
+
+const read = await simAws
+  .cloudFront()
+  .getDistribution(
+    new GetDistributionCommand({ Id: stack.output("DistributionId") }),
+  );
+const config = read.Distribution?.DistributionConfig;
+
+// The managed ID the default Behavior was given.
+console.log(config?.DefaultCacheBehavior?.CachePolicyId);
+
+// The ID of the policy the template created, which the path Behavior Refs.
+console.log(
+  config?.CacheBehaviors?.Items?.[0]?.CachePolicyId ===
+    stack.output("BeaconPolicyId"),
+);
+```
+
+A Behavior records the ID it was given, and `GetDistribution` reports it back for both the default
+Behavior and a named one. An update changing the policy is reported the same way.
+
+Nothing here reads the policy itself. The TTLs, the cache key and the compression settings need a
+cache, and sim CloudFront holds none. Every request reaches the Origin whatever the policy would
+have cached on real CloudFront.
+
+A policy name is unique within an account, as it is in CloudFront. A second
+`AWS::CloudFront::CachePolicy` claiming a name is refused with `CachePolicyAlreadyExists`.
+`Name` and `Comment` are the parts of `CachePolicyConfig` the policy carries.
+
+### Managed cache policies
+
+CloudFront's seven managed policies are here from the start, under the IDs AWS publishes, and a
+Behavior names one without a template creating anything. `CachingOptimized`
+(`658327ea-f89d-4fab-a63d-7e88639e58f6`), `CachingDisabled` (`4135ea2d-6df8-44a3-9df3-4b5a84be39ad`),
+`CachingOptimizedForUncompressedObjects` (`b2884449-e4de-46a7-ac36-70bc7f1ddd6d`), `Amplify`
+(`2e54312d-136d-493c-8eb9-b001f22f67d2`), `Elemental-MediaPackage`
+(`08627262-05a9-4f76-9ded-b50ca2e3a84f`), `UseOriginCacheControlHeaders`
+(`83da9c7e-98b4-4e11-a168-04f0df8e2c65`) and `UseOriginCacheControlHeaders-QueryStrings`
+(`4cc15a8a-d715-48a4-82b8-cc0b614638fe`) are each held under the name
+[AWS publishes](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-cache-policies.html)
+for it. CDK's `CachePolicy.CACHING_OPTIMIZED` and its six siblings synthesize those IDs. A stack
+reaching for one deploys.
+
+The managed policies sit in CloudFront's own namespace. A template may create a policy called
+`CachingDisabled` of its own, and deleting that stack leaves the managed one where it was.
+
+A CloudFormation Distribution whose Behavior names a policy that is neither managed nor created here
+deploys without one. The `CachePolicyId` lands on `stack.ignoredProperties` under that Behavior, the
+way an absent response headers policy does, and the Behavior reports no policy.
+
+`CreateDistribution` and `UpdateDistribution` still refuse the same ID with `NoSuchCachePolicy`, as
+real CloudFront refuses it.
+
 ## Origin access controls
 
 An origin access control is how a Distribution authenticates to a private Origin. The Origin then
@@ -2712,7 +2929,8 @@ Sim CloudFront currently supports:
 
 - `CreateDistributionCommand`, `GetDistributionCommand`, `UpdateDistributionCommand` and
   `DeleteDistributionCommand`
-- `CreateFunctionCommand` and `DeleteFunctionCommand`
+- `CreateFunctionCommand`, `ListFunctionsCommand`, `DescribeFunctionCommand`, `GetFunctionCommand`
+  and `DeleteFunctionCommand`
 - Refusing Function code over CloudFront's 10 KB size limit, with `FunctionSizeLimitExceeded`
 - Key value stores, through both the CloudFront client and the key value store data client
 - S3 Origins backed by sim S3 Buckets, reading them as the Bucket policy allows
@@ -2726,6 +2944,7 @@ Sim CloudFront currently supports:
 - `LambdaFunctionAssociations` on a template's Distribution, and CDK's `edgeLambdas`
 - CloudFront Functions reading an associated key value store through `cf.kvs()`
 - `AWS::CloudFront::ResponseHeadersPolicy`, for headers a cache Behavior sets on every response
+- `AWS::CloudFront::CachePolicy`, and a Behavior's `CachePolicyId` read back through `GetDistribution`
 - `AWS::CloudFront::KeyValueStore`, and `KeyValueStoreAssociations` on `AWS::CloudFront::Function`
 - `AWS::CloudFront::OriginAccessControl`, letting an Origin read a private Bucket as CloudFront
 - Viewer certificates from sim ACM, including CloudFront's `us-east-1` requirement
@@ -2868,7 +3087,12 @@ Where sim CloudFront knowingly behaves differently from AWS:
   share of real responses carry `Server-Timing`. This simulation adds it to every response once
   `Enabled` is true. A test asserting on it never depends on chance. The header's value is a
   fixed placeholder, since nothing here measures an Origin fetch the way CloudFront's edge does.
-- **`CachePolicyId` and `OriginRequestPolicyId` are accepted and ignored.** Sim CloudFront models no
-  edge caching. A Behavior's cache policy, including an AWS managed policy such as
-  `CachingOptimized`, is left unvalidated and unapplied to TTLs and the cache key. Every request
-  reaches the Origin, whatever the policy would have cached on real CloudFront.
+- **A cache policy is recorded and never applied.** Sim CloudFront models no edge caching. A
+  Behavior's `CachePolicyId` is checked against the policies this simulation holds and reported
+  back, and the TTLs, the cache key and the compression settings behind it decide nothing. Every
+  request reaches the Origin, whatever the policy would have cached on real CloudFront.
+- **A cache policy carries its name and its comment, and nothing else.** The TTLs and
+  `ParametersInCacheKeyAndForwardedToOrigin` of an `AWS::CloudFront::CachePolicy` are read past,
+  since nothing here would act on them.
+- **`OriginRequestPolicyId` is accepted and ignored.** A Behavior's origin request policy is left
+  unvalidated, and `AWS::CloudFront::OriginRequestPolicy` is skipped.

package/docs/services/cloudwatch/README.md

@@ -285,10 +285,12 @@ deploy the stack, publish a breaching datapoint, advance the clock and read the
 whatever is subscribed. Deleting the stack deletes the alarm and takes its scheduled evaluation back
 off the clock with it.
 
-`AlarmName` may be left out, and the alarm is then named after the stack and the logical ID. A test
-still has a name to pass to `DescribeAlarms`. Real CloudFormation generates a physical ID of the
-same shape with a random tail on the end. The tail is left off here, so the name is one a test can
-predict.
+`AlarmName` may be left out, and the alarm is then named after the stack, the logical ID and a tail
+derived from both. Real CloudFormation ends a physical ID of the same shape in twelve random
+characters, and the tail here comes from the name it follows, giving one alarm the same name at
+every deployment. `simAws.cloudWatch().allAlarms()` hands a test the name to pass to
+`DescribeAlarms`, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover how a long name is trimmed.
 
 These are the properties acted on: `AlarmName`, `AlarmDescription`, `ActionsEnabled`,
 `AlarmActions`, `OKActions`, `InsufficientDataActions`, `Namespace`, `MetricName`, `Dimensions`,

package/docs/services/cognito/README.md

@@ -3314,10 +3314,11 @@ same thing about the property and differ in what they do about it. A direct API
 request to fail, and a template has every other resource in it to think about.
 
 `UserPoolName` and `ClientName` are optional. A template that sets neither gets
-`<stack name>-<logical id>`, as real CloudFormation generates a name, trimmed to the 128 characters
-Cognito allows if the two are longer than that together. Real CloudFormation adds random characters
-on the end and this adds none. The name is the same on every deployment of the same template, and a
-test can assert it.
+`<stack name>-<logical id>-<tail>`, as real CloudFormation generates a name, trimmed to the 128
+characters Cognito allows if the parts are longer than that together. The tail is twelve characters
+derived from the other two, where real CloudFormation ends the name in twelve random ones. The name
+is the same on every deployment of the same template, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover how a long name is trimmed.
 
 ## Registering a pool with a chosen pool id
 
@@ -3461,13 +3462,13 @@ await stack.waitForDeployComplete();
 
 const userPoolId = stack.output("PoolId");
 
-// The pool is named after the stack and the logical id, as the template named
-// neither it nor the client.
+// The pool is named after the stack, the logical id and a tail derived from
+// both, as the template named neither it nor the client.
 const described = await simAws
   .cognitoIdentityProvider()
   .describeUserPool(new DescribeUserPoolCommand({ UserPoolId: userPoolId }));
 
-console.log(described.UserPool?.Name); // "app-stack-Pool"
+console.log(described.UserPool?.Name); // "app-stack-Pool-2c3041dc539d"
 
 // What the template declared is reported back. This one is acted on: it is
 // what says only an admin creates users in this pool.

package/docs/services/dynamodb/README.md

@@ -3107,11 +3107,12 @@ the template gets wrong fails the same way it would for an SDK caller.
 updates it. A specification the template got wrong is refused in the words `UpdateTimeToLive`
 refuses it in.
 
-A table with no `TableName` is named after the stack and its logical ID. The table above with its
-name left out would be `orders-stack-OrdersTable`. Real CloudFormation adds random characters to
-that, which a template cannot predict either way. Two stacks deploying the same template get two
-differently named tables. The generated name is trimmed to the 255 characters a table name allows,
-ending in a hash of the untrimmed name so two long names that start the same stay apart.
+A table with no `TableName` is named after the stack, its logical ID and a tail derived from both.
+The table above with its name left out would be `orders-stack-OrdersTable-` and twelve more
+characters, where real CloudFormation ends the name in twelve random ones. Two stacks deploying the
+same template get two differently named tables. The name is trimmed to the 255 characters a table
+name allows, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover how the stack name and the logical ID share what is left.
 
 `Fn::GetAtt … StreamArn` gives the ARN of the stream the table's `StreamSpecification` gave it. On a
 table with no `StreamSpecification` it is refused by name, naming the table, since an invented

package/docs/services/ecs/README.md

@@ -706,7 +706,8 @@ real ECS accepts for a parameter in the task's own region. A Secrets Manager ARN
 key, a version stage and a version id after the secret id, in the form
 `...:secret:orders/db-AbCdEf:password::` that a CDK construct given a field writes. The key selects
 one field of a secret holding a JSON object. A `SecureString` parameter is decrypted, as it is for a
-real task.
+real task. The decryption is made with the execution role's own permissions, and that role needs
+`kms:Decrypt` on top of `ssm:GetParameter`.
 
 A secret that cannot be resolved stops the task before any container runs, with a
 `ResourceInitializationError` reason naming the variable:
@@ -1431,7 +1432,9 @@ console.log(processedOrders); // ["outstanding orders"]
 
 A binding can name the task definition Resource instead, which is what a CDK stack gives a test to
 name. The construct ID is accepted as well as the synthesized logical ID, and the container name can
-be left out where the task definition declares one container. A binding naming an image repository
+be left out where the task definition declares one container. This is the form to use for a task
+definition the template declares no `Family` for, since the family CloudFormation generates for it
+ends in a tail a test would have to deploy the stack to learn. A binding naming an image repository
 matches any container running an image from it, whichever family declares it, which covers a tag
 that changes with every build.
 
@@ -1604,9 +1607,9 @@ const listed = await simAws
 console.log(listed.taskArns?.length); // 2
 ```
 
-An unnamed service is named after the stack and the logical ID, as a cluster and a family are. A
-service declaring no `DesiredCount` keeps one task running, which is what real CloudFormation gives
-a new service.
+An unnamed service is named after the stack, the logical ID and a tail derived from both, as a
+cluster and a family are. `Fn::GetAtt ... Name` answers with the generated name. A service declaring
+no `DesiredCount` keeps one task running, which is what real CloudFormation gives a new service.
 
 Updating the stack moves the service. A changed `DesiredCount` scales it, and a changed task
 definition moves it onto the revision the update registered, replacing the tasks it was keeping.
@@ -1645,6 +1648,10 @@ task definition revision it would run, `DescribeTasks` and `StopTask`, which tak
 and the service operations, which take the service's ARN. `CreateService` authorizes against the ARN
 the service is about to have, and a policy can therefore name one service by name before it exists.
 
+A registration carrying a `taskRoleArn` or an `executionRoleArn` hands ECS a Role it runs the task
+as, and `RegisterTaskDefinition` authorizes `iam:PassRole` against each of them. Either Role left out
+passes nothing. See [passing a Role to a service](https://yulinsim.dev/services/iam/#passing-a-role-to-a-service) in the IAM docs.
+
 ```typescript sim-ecs-iam-policy
 /**
  * A simulated IAM policy allowing a Role to register task definitions.
@@ -1782,7 +1789,8 @@ console.log(described.taskDefinition?.revision); // 1
 
 ## Available functionality
 
-- `RegisterTaskDefinitionCommand`, with revisions numbered per family from one
+- `RegisterTaskDefinitionCommand`, with revisions numbered per family from one, authorizing
+  `iam:PassRole` on the `taskRoleArn` and the `executionRoleArn` it names
 - `DeregisterTaskDefinitionCommand`, marking one revision `INACTIVE`
 - `DescribeTaskDefinitionCommand`, taking a family, a `family:revision` or a full ARN
 - `ListTaskDefinitionsCommand` and `ListTaskDefinitionFamiliesCommand`, with prefix, status and
@@ -1967,9 +1975,12 @@ Current documented limitations:
   `DescribeServices` and `ListTasks` are what report those.
 - Task definition and cluster tags are stored and reported, but `TagResource`, `UntagResource` and
   `ListTagsForResource` are absent.
-- An unnamed cluster, task definition or service gets a name composed from the stack name and the
-  logical ID, without the random part real CloudFormation adds, which makes it predictable in a
-  test. A stack deployed twice under different names therefore gets two different families.
+- An unnamed cluster, task definition or service gets a name composed from the stack name, the
+  logical ID and a tail derived from both, in place of the random characters real CloudFormation
+  ends one with. The same stack redeployed gets the same names, and a stack deployed twice under
+  different names gets two different families.
+  [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+  cover the tail and how a long name is trimmed.
 - A service that declares no `DesiredCount` keeps one task running. That is the default real
   CloudFormation documents for a new service. A `DesiredCount` written as the text of a number is
   taken as that number, since a String Parameter resolves to text, and anything else is refused

package/docs/services/elbv2/README.md

@@ -1421,8 +1421,12 @@ fails the deployment.
 - `TargetGroupArn`, `TargetGroupName` and `TargetGroupFullName` on a target group
 - `ListenerArn` on a listener, and `RuleArn` and `IsDefault` on a rule
 
-An unnamed load balancer or target group is named after the stack and the logical ID, trimmed to the
-32 characters ELB allows. A target group declaring `Targets` has them registered as part of creating
+An unnamed load balancer or target group is named after the stack, the logical ID and a tail derived
+from both, trimmed to the 32 characters ELB allows. The tail takes 13 of those. A name that has to
+be trimmed gives the stack name and the logical ID nine characters each, and either takes what the
+other leaves.
+[the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover the rule. A target group declaring `Targets` has them registered as part of creating
 it, and the group routes as soon as the stack has deployed.
 
 ```typescript sim-elbv2-cloudformation

package/docs/services/eventbridge/README.md

@@ -909,7 +909,10 @@ console.log(handled.length); // 1
 `Ref` returns the **name** of a bus or a rule, and never its ARN. That is what AWS returns, and it
 makes a bus `Ref` usable straight away as another resource's `EventBusName`. The ARN comes from
 `Fn::GetAtt ... Arn`, which an `AWS::Lambda::Permission` `SourceArn` needs. An unnamed rule gets a
-name generated from the stack name and the logical ID, as real CloudFormation generates one.
+name generated from the stack name, the logical ID and a tail derived from both, as
+[the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+describe. A rule name caps at 64 characters. A stack name and logical ID longer than that together
+are trimmed to 25 characters each, and either takes what the other leaves.
 
 A target property this simulation leaves out, such as `InputTransformer` or `InputPath`, is refused
 at deploy time naming the property and the Resource. The alternative is a rule that sends the whole
@@ -1005,6 +1008,10 @@ console.log(JSON.stringify(policy).length > 0); // true
 A caller refused by IAM gets `AccessDeniedException`. Permission is checked before the bus is looked
 up, and a caller who may not reach a bus is refused whether or not that bus exists.
 
+An ECS target carries a `RoleArn`, which the rule runs the task as. Adding one hands EventBridge that
+Role, and `PutTargets` authorizes `iam:PassRole` against it. See
+[passing a Role to a service](https://yulinsim.dev/services/iam/#passing-a-role-to-a-service) in the IAM docs.
+
 ## Scoping
 
 Buses belong to one account and region, as they do on real AWS:
@@ -1057,6 +1064,7 @@ no permission for.
   listings.
 - The event envelope EventBridge builds from an entry, reached through `eventsOn(...)`.
 - IAM authorization against the bus ARN.
+- `iam:PassRole` authorization of the `RoleArn` an ECS target carries.
 - SDK interception of `EventBridgeClient`.
 
 ## Limitations

package/docs/services/firehose/README.md

@@ -378,6 +378,10 @@ Deleting the delivery stream stops it reading. Records put afterwards stay on th
 Every Firehose operation authorizes against the `firehose:` action of the same name, on the ARN of
 the delivery stream it names. `ListDeliveryStreams` names none, and authorizes against `*`.
 
+Creating a delivery stream hands Firehose the destination `RoleARN`, and the source `RoleARN` too
+where it reads a Kinesis stream. `CreateDeliveryStream` authorizes `iam:PassRole` against each of
+them. See [passing a Role to a service](https://yulinsim.dev/services/iam/#passing-a-role-to-a-service) in the IAM docs.
+
 The delivery itself is a separate request, made as the delivery stream's `RoleARN`. The caller who
 put the record needs no S3 permission at all, and a Role that cannot write to the Bucket fails the
 delivery. Real
@@ -607,8 +611,10 @@ writes into the Bucket beside it, as the Role beside it, and a Role without `s3:
 delivery the same way one created through `CreateDeliveryStream` does. Deleting the stack deletes the
 delivery stream.
 
-A delivery stream the template does not name is named after the stack and the logical ID, as real
-CloudFormation names one. The name is trimmed to the 64 characters Firehose allows.
+A delivery stream the template does not name is named after the stack, the logical ID and a tail
+derived from both, as real CloudFormation names one. The name is trimmed to the 64 characters
+Firehose allows, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover how the two parts share what is left.
 
 `DeliveryStreamEncryptionConfigurationInput` and `DirectPutSourceConfiguration` are recorded against
 the resource as unsimulated, and the delivery stream deploys anyway. The destination properties this
@@ -737,7 +743,7 @@ console.log(Contents?.length);
 
 | Command                  | Notes                                                                                                   |
 | ------------------------ | ------------------------------------------------------------------------------------------------------- |
-| `CreateDeliveryStream`   | A name already in use raises `ResourceInUseException`.                                                  |
+| `CreateDeliveryStream`   | A name already in use raises `ResourceInUseException`. Authorizes `iam:PassRole` on each Role it names. |
 | `DeleteDeliveryStream`   | The name is free again at once. Whatever was buffered goes with it.                                     |
 | `ListDeliveryStreams`    | Sorted by name, paged with `Limit` and `ExclusiveStartDeliveryStreamName`.                              |
 | `DescribeDeliveryStream` | Reports the one destination, and a Kinesis source under `Source`.                                       |

package/docs/services/glue/README.md

@@ -131,6 +131,12 @@ Column names keep the case they were given, including partition keys. Real Glue
 and simulated [Athena](https://yulinsim.dev/services/athena/ "Simulated Athena usage docs") folds a
 column name only when it runs a query.
 
+A database or a table the template leaves unnamed is named from the stack name, the logical ID and a
+tail derived from both, folded the same way. A `LogTable` in `analytics-stack` becomes
+`analytics-stack-logtable-` and twelve more characters, where real CloudFormation ends the name in
+twelve random ones. The name is trimmed to the 255 bytes the catalog allows, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
+cover how the stack name and the logical ID share what is left.
+
 ## Reading the catalog back
 
 `GetDatabase`, `GetDatabases`, `GetTable` and `GetTables` answer through the SDK. A `SimGlue` also