@kensio/yulin 1.21.7 → 1.21.9

package/docs/services/logs/README.md

@@ -1,20 +1,15 @@
 # Simulated CloudWatch Logs
 
-Yulin includes a simulated Amazon CloudWatch Logs for tests and local development. It holds log
-groups, the streams inside them and the events written to those streams. A test can put log events
-and read them back with `GetLogEvents`, or search them with `FilterLogEvents`, without an AWS
-account.
-
-The point of it is to make log data addressable. Code that writes to CloudWatch Logs is code teams
-already have, and the alternative for a test is capturing process output.
+Yulin simulates CloudWatch Logs in memory. It stores log groups, streams, and events. Application
+code can write events through the normal SDK commands, and tests can read one stream with
+`GetLogEvents` or search a group with `FilterLogEvents`.
 
 CloudWatch Logs specific types are imported from the `@kensio/yulin/logs` subpath.
 
 ## Writing and searching log events
 
-A log group holds streams, a stream holds events, and `FilterLogEvents` searches across every
-stream in a group. A test can therefore name the group and leave the stream out, without knowing
-which execution environment wrote the line.
+`FilterLogEvents` searches every stream in a group. A test can find an event without knowing which
+execution environment wrote it.
 
 ```typescript sim-logs-write-and-search
 /**
@@ -86,11 +81,9 @@ set of alternatives, and a quoted phrase matches with its spaces intact.
 
 An omitted or empty pattern matches everything.
 
-The structured pattern syntaxes are refused. A JSON property pattern (`{ $.level = "ERROR" }`), a
+Yulin refuses structured pattern syntaxes. A JSON property pattern (`{ $.level = "ERROR" }`), a
 space delimited field pattern (`[level=ERROR, message]`) and a regular expression term
-(`%ERROR|WARN%`) each raise `SimLogsUnsupportedOperationException`. Approximating one would be
-worse. A pattern quietly treated as matching everything would turn an assertion about one log line
-into an assertion about any log line at all, and the test would keep passing while testing nothing.
+(`%ERROR|WARN%`) each raise `SimLogsUnsupportedOperationException`.
 
 ## Reading one stream
 
@@ -166,10 +159,8 @@ console.log(read);
 
 ## Retention
 
-Retention is held as a property to assert on. Events stay where they are, and seeing one go would
-mean moving the clock by months. What teams get wrong about retention is the value they deployed,
-ahead of the deletion that eventually follows from it. A log group with no retention keeps its
-events forever, the AWS default.
+Retention is stored and reported but leaves events in place. A log group without a retention setting
+keeps events forever, matching the AWS default.
 
 The accepted values are a fixed set. A reasonable-looking `retentionInDays: 10` is refused here
 exactly as it is by an account.
@@ -210,9 +201,8 @@ console.log(
 
 ## Lambda handler output
 
-A Lambda function's output is recorded into `/aws/lambda/<function name>` as it runs, whether its
-code is a zip archive or a real in-process handler. A test can then assert on what a handler logged
-by searching its log group.
+A simulated Lambda function writes its output to `/aws/lambda/<function name>`, whether it runs from
+a zip archive or an in-process handler. Search that group to assert on handler output.
 
 ```typescript sim-logs-lambda-output
 /**
@@ -256,11 +246,9 @@ const found = await simAws.logs().filterLogEvents(
 console.log(found.events?.[0]?.message);
 ```
 
-The output still reaches the terminal as well. Real Lambda sends it to CloudWatch Logs and nowhere
-else, but a test tool that swallowed it would make a failing test harder to debug. Recording is a
-tee.
+Output also remains visible in the terminal to help diagnose failing tests.
 
-An invocation that ends in an error nothing caught leaves an `ERROR Invoke Error` line in the group
+An invocation that ends in an uncaught error leaves an `ERROR Invoke Error` line in the group
 after whatever it printed, carrying the error's type, its message and its stack. The
 [simulated Lambda docs](https://yulinsim.dev/services/lambda/ "Simulated Lambda usage docs") show
 one.
@@ -272,8 +260,8 @@ shape in a test, and leave the value alone.
 
 Writing on this path is unconditional. A real function needs `logs:CreateLogGroup` and
 `logs:PutLogEvents` on its execution Role, and one without them produces no logs at all, in silence.
-Simulating that would leave nearly every function in a test logging nothing, with no failure to
-explain why.
+Yulin always captures this output so missing log permissions do not hide diagnostic messages in
+tests.
 
 ## Declaring a log group in a template
 
@@ -308,12 +296,11 @@ Two divergences to know about:
 
 ## Delivering logs from another service
 
-CloudWatch Logs delivery carries the logs of another service somewhere. CloudFront standard logging
-v2 is the clearest case. A distribution has no logging property of its own, and turning logging on
-means three CloudWatch Logs resources.
+CloudWatch Logs delivery connects a service's log source to a destination. CloudFront standard
+logging v2 uses a delivery source, a delivery destination, and a delivery.
 
-A delivery source names what is being logged and which of its logs. A delivery destination names
-where they land and in what form. A delivery joins one to the other.
+The source identifies the resource and log type. The destination identifies where logs would go and
+their output format. The delivery joins them.
 
 ```typescript sim-logs-delivery
 /**
@@ -418,7 +405,7 @@ rules from real AWS are modelled here, each of them a deploy that looks fine unt
 - **A delivery holds both its ends.** Deleting the source or the destination while a delivery joins
   them fails with `ConflictException`. The delivery goes first, and CloudFormation orders that
   itself when a stack is deleted.
-- **CloudFront delivers `ACCESS_LOGS` and nothing else.** Any other `logType` over a distribution is
+- **CloudFront supports only `ACCESS_LOGS`.** Any other `logType` over a distribution is
   refused.
 - **CloudFront delivery is set up from `us-east-1`**, whatever region the destination bucket is in.
   A CloudFront delivery source put from anywhere else is refused.
@@ -441,10 +428,9 @@ bare variables and let delivery name them.
 
 ### Declaring delivery in a template
 
-The same three resources in a template, which is the whole of what a CDK construct for CloudFront
-logging synthesises, alongside the distribution they are for. The source's `ResourceArn` is built
-around a `Ref` to that distribution, the way CDK builds it. A pinned distribution id fails the
-deploy (see [the rules above](#delivering-logs-from-another-service)).
+A CloudFormation template can declare the same three resources alongside the CloudFront distribution.
+The source's `ResourceArn` can use `Ref` to include the generated distribution ID. A hard-coded ID
+for a missing distribution fails deployment (see [the rules above](#delivering-logs-from-another-service)).
 
 ```yaml
 SiteDistribution:
@@ -501,9 +487,9 @@ The template carries the S3 layout as two flat properties, and the API takes the
 delivery. CloudWatch Logs issues that ID. A template cannot predict it.
 
 `Fn::GetAtt` gives `Arn` on all three. The source also publishes `Service` and `ResourceArns`, and
-the delivery publishes `DeliveryId` and `DeliveryDestinationType`. The destination publishes nothing
-else, and `DeliveryDestinationType` is a property of it rather than an attribute, so read that one
-off the delivery. Anything outside this set is refused here, as CloudFormation refuses it.
+the delivery publishes `DeliveryId` and `DeliveryDestinationType`. The destination publishes only
+`Arn`. Read `DeliveryDestinationType` from the delivery rather than the destination. CloudFormation
+refuses attributes outside this set.
 
 `Tags` and `DeliveryDestinationPolicy` are recorded as ignored properties, and the stack still
 deploys.
@@ -732,7 +718,8 @@ function is. `UpdateAlias` moves what the filter reaches, and the filter stays a
 
 ## Metric filters
 
-A metric filter turns matching log events into CloudWatch metric datapoints. It is how a log line becomes something an alarm can watch, with no handler publishing a metric of its own.
+A metric filter converts matching log events into CloudWatch metric datapoints. An alarm can then
+watch the metric without application code calling `PutMetricData`.
 
 ```typescript sim-logs-metric-filter
 /**
@@ -916,7 +903,9 @@ console.log(MetricAlarms?.[0]?.StateValue);
 
 ## Embedded Metric Format
 
-A log event that is itself an Embedded Metric Format document publishes the metrics it declares. This is how AWS Lambda Powertools counts anything. Its `Metrics` writes an EMF document to the handler's stdout and calls no CloudWatch API at all, and a CDK `NodejsFunction` bundling Powertools does the same in a deployed account.
+A log event containing an Embedded Metric Format (EMF) document publishes its declared metrics.
+AWS Lambda Powertools uses this path. It writes EMF to standard output instead of calling the
+CloudWatch API.
 
 ```typescript sim-logs-embedded-metric-format
 /**
@@ -997,7 +986,9 @@ A log event is read as a document only where it parses as JSON, comes out as an
 
 Three things go on `simAws.logs().metricPublicationFailures` rather than passing quietly. A metric the metadata declares and the document body carries no number under, a metric asking for `StorageResolution: 1`, which simulated CloudWatch has no period short enough for, and a directive that asked for dimensions and got no usable set of them.
 
-A dimension set is taken whole or dropped whole. One naming a key the body lacks, and one carrying anything but strings, are both dropped, because publishing part of a set would put the datapoint under a narrower identity than the document declared. A directive left with no usable set publishes nothing at all. Falling back to no dimensions would land the datapoint on the undimensioned metric, and that is one an alarm may well be watching.
+A dimension set is accepted or dropped as a whole. Yulin drops a set when the body lacks one of its
+keys or a value has a type other than string. Publishing only part of the set would create the wrong
+metric identity. A directive without a usable set produces no datapoint.
 
 Each entry on the ledger names its `source`, which is `{ kind: "metricFilter", filterName }` or `{ kind: "embeddedMetricFormat" }`. The two are told apart by kind rather than by name, because a metric filter may be called anything.
 
@@ -1132,7 +1123,7 @@ console.log(described.logGroups?.[0]?.logGroupArn);
 - **Events never expire.** Retention is stored and reported, never acted on.
 - **A metric filter reading a field of the log event.** A `metricValue` or a dimension value
   beginning `$` is refused where the filter is put. Both need a structured filter pattern, and
-  neither structured syntax is simulated.
+  both require a structured syntax, which Yulin refuses.
 - **How far back a `defaultValue` looks.** A filter remembers the most recent minute it matched
   something in. A later write into that same minute publishes no default over the top, and a write
   landing in an earlier minute a match was already seen in does publish one. Events
@@ -1143,21 +1134,21 @@ console.log(described.logGroups?.[0]?.logGroupArn);
   read, which is how it reaches CloudWatch in an account.
 - **`AWS::Logs::SubscriptionFilter`.** Recorded as a gap. The log group, the metric filter and the
   three delivery resource types are what simulated CloudFormation deploys here.
-- **`ApplyOnTransformedLogs` and `EmitSystemFieldDimensions` on a metric filter.** Recorded and
-  acted on by nothing. Log transformers are absent, so there is no transformed event to read.
-- **Nothing is actually delivered.** A delivery records that a source was joined to a destination
+- **`ApplyOnTransformedLogs` and `EmitSystemFieldDimensions` on a metric filter.** Recorded as
+  ignored properties. Log transformers are absent.
+- **Delivery resources store configuration only.** A delivery records that a source was joined to a destination
   and how the records would be written. No access log file ever reaches the bucket.
 - **`GetDeliverySource`, `GetDeliveryDestination` and `GetDelivery`.** Absent as SDK operations. The
   three `Describe` operations report the same resources. The three action names are authorized where
   CloudFormation reads a delivery Resource back.
 - **Delivery resource tags and cross-account delivery.** `PutDeliverySource`,
   `PutDeliveryDestination` and `CreateDelivery` refuse tags outright. `DeliveryDestinationPolicy` in
-  a template is recorded and acted on by nothing.
+  a template is recorded as an ignored property.
 - **An `=` in a suffix path with Hive compatible paths off.** Taken. Whether real CloudWatch Logs
   takes one is unverified. A path hand-rolling its own partition keys without the option is left
   alone here, and refused with the option on.
-- **Log types for services other than CloudFront.** Any `logType` is taken over a resource that is
-  not a distribution, because the valid set varies by service and this simulation does not carry it.
+- **Log types for services other than CloudFront.** Yulin accepts any `logType` for resources other
+  than distributions because the valid set varies by service.
 - **Logs Insights, export tasks, tags, encryption and data protection policies.** Absent. Tags and
   `kmsKeyId` on `CreateLogGroup` are refused outright. A property cannot look set here and behave
   differently in an account.

package/docs/services/organizations/README.md

@@ -1,18 +1,14 @@
 # Simulated Organizations
 
-Yulin simulates AWS Organizations service control policies. A test can find out that the
-organization around an account forbids something before a deployment does.
+Yulin simulates AWS Organizations service control policies (SCPs) and organization structure.
 
-A service control policy filters what an account's principals may do and grants nothing. Policies
-attach to the organization root, to an organizational unit, or to one account, and an account
-inherits every policy on the path down to it. Sim IAM evaluates them ahead of that account's
-identity and resource policies. An SCP therefore applies to a CloudFormation deployment, an
-intercepted SDK client, and a direct service call alike.
+An SCP limits permissions granted by identity and resource policies. Attach one to the organization
+root, an organizational unit or an account. An account inherits policies from every node on its path
+from the root. Simulated IAM applies them to direct calls, intercepted clients and CloudFormation.
 
 ## Attach a policy to an organizational unit
 
-A policy is usually attached to an organizational unit rather than to one account, and every account
-under that unit inherits it. Units nest, and the root sits above all of them.
+Create an organizational unit and attach an SCP to it. Accounts below the unit inherit the policy.
 
 ```typescript sim-organizations-organizational-unit
 /**
@@ -44,16 +40,13 @@ const decision = simAws.account("123456789012").iam().authorize({
 console.log(decision.value); // "ExplicitDeny"
 ```
 
-The policy hangs two levels above the account and still reaches it. `createOrganizationalUnit` takes
-a parent unit as its second argument, and leaves the unit under the root without one.
-`organizations.root()` is the node above everything, and a policy attached there covers every
-account in the organization.
+Pass a parent as the second argument to `createOrganizationalUnit` to nest units. With no parent, the
+new unit sits below `organizations.root()`.
 
 ## Every level has to allow the action
 
-An account is filtered by each node on the path from the root down to it, and each one has to allow
-an action on its own. A root allowing S3 and a unit allowing DynamoDB leave an account beneath them
-able to do neither.
+Every node on the path must allow the action. An allow at one level cannot supply an allow missing
+at another. A deny at any level rejects the request.
 
 ```typescript sim-organizations-every-level-allows
 /**
@@ -89,15 +82,12 @@ console.log(decision.value); // "ImplicitDeny"
 console.log(decision.serviceControlPolicy.unallowedLevels); // [ "Workloads" ]
 ```
 
-`unallowedLevels` names the nodes that allowed nothing matching. That is the part of a real SCP
-denial that takes longest to track down.
-
-A `Deny` at any level ends the request whatever another level allows.
+`unallowedLevels` identifies the nodes with no matching allow.
 
 ## The management account
 
-`setManagementAccount` names the account AWS exempts from every service control policy. That account
-is decided by its identity and resource policies alone, whatever is attached above it.
+Use `setManagementAccount` to exempt one account from SCP evaluation. Its identity and resource
+policies still apply.
 
 ```typescript sim-organizations-management-account
 /**
@@ -126,9 +116,8 @@ console.log(decision.serviceControlPolicy.isApplied); // false
 
 ## Attach a service control policy to an Account
 
-A policy attached straight to an account applies to that account alone. An organization spans
-accounts, so it belongs to the whole simulated environment and is reached as
-`simAws.organizations()`, not from an account scope.
+An SCP attached directly to an account applies only to that account. Organization state belongs to
+the whole `SimAws` instance and is available through `simAws.organizations()`.
 
 ```typescript sim-organizations-attach-scp
 /**
@@ -159,17 +148,15 @@ console.log(decision.serviceControlPolicy.isDenied); // true
 console.log(decision.serviceControlPolicy.denyStatements[0]?.Sid); // "DenyBucketCreation"
 ```
 
-The account also gets AWS's own `FullAWSAccess` policy, as it would in a real organization. One
-`Deny` statement therefore denies that one action and leaves the rest of the account working.
+New organization nodes receive the AWS-managed `FullAWSAccess` policy. A deny-list SCP can then
+block one action while leaving other actions allowed.
 
-An account with no policy attached to it stays outside the organization's reach, and its identity
-and resource policies decide its requests as they did before.
+An account outside the organization is unaffected by SCPs.
 
 ## Catch a deployment the policy denies
 
-Sim CloudFormation creates each resource through the owning service's command handler, and that
-handler authorizes. A deployment that names no principal is decided as the account root. An SCP
-applies to a member account's root the same way AWS does.
+CloudFormation creates resources through each service's authorized command path. A deployment with
+no caller runs as the account root, and SCPs apply to that root.
 
 ```typescript sim-organizations-scp-deployment
 /**
@@ -213,14 +200,13 @@ const failed = simAws
 console.log(failed?.status); // "CREATE_FAILED"
 ```
 
-The resource is left `CREATE_FAILED` and the deployment rejects. A test asserting that a stack
-deploys then fails on the policy, with the policy named in the message.
+When an SCP denies creation, the resource enters `CREATE_FAILED` and the deployment rejects. The
+error names the policy.
 
 ## Name the principal a deployment runs as
 
-An organization that denies its accounts' root principals is ordinary, and a deployment decided as
-the root fails under one. `caller` says which principal the resources are created as, and a
-statement conditioned on `aws:PrincipalArn` then has a deploy role to match against.
+Pass `caller` when the deployment should run as a role. SCP conditions on `aws:PrincipalArn` then
+evaluate against that role.
 
 ```typescript sim-organizations-scp-deploy-role
 /**
@@ -285,17 +271,15 @@ const stack = await simAws.cloudFormation().deployTemplate({
 console.log(stack.getResource("ReportsBucket")?.status); // "CREATE_COMPLETE"
 ```
 
-The Role is created before the policy is attached. Creating it afterwards is a call the policy
-denies the root, and the account root is who a bare `createRole` runs as.
+Create the role before attaching a policy that would deny the setup call.
 
 ## Name the caller the rest of a test reads as
 
-A deployment names its own principal. Every other call in the test still names none, and each one is
-the account root. Under a policy denying that root, a test reading back what a stack made is denied
-on every read.
+A deployment caller applies only to that deployment. Other calls still use the account root unless
+the simulation has a default caller.
 
-`defaultCaller` on `SimAws` says who those calls are. A test then reads the account as the person or
-role that would really be looking at it, and an explicit `caller` still wins wherever one is given.
+Set `defaultCaller` on `SimAws` to choose the principal for unattributed calls. An explicit `caller`
+still takes precedence.
 
 ```typescript sim-organizations-scp-default-caller
 /**
@@ -369,17 +353,13 @@ console.log(read.Parameter?.Value); // "reports-bucket"
 console.log(identity.Arn); // "arn:aws:iam::123456789012:role/Administrator"
 ```
 
-Setup runs before the policy is attached, for the same reason the deploy Role above does. The Role a
-simulation reads as has to exist and hold a policy, and creating it is itself a call.
-
-Naming a default caller says who an unattributed call comes from, and leaves the root's own identity
-access where it was. A test about root behaviour names `simAws.account().rootPrincipal` and gets the
-root. Under the policy above that call is denied, which is what the statement is written to do.
+Create and configure the default caller before attaching policies that would deny those setup calls.
+Pass `simAws.account().rootPrincipal` explicitly when a test needs to make a request as root.
 
 ## Write an allow list instead of a deny list
 
-`detachFullAwsAccess` takes AWS's own policy off an account. What remains has to allow an action
-for the account to be allowed it. That is an organization run as an allow list.
+Call `detachFullAwsAccess` to use an allow-list SCP. The remaining policies must explicitly allow an
+action.
 
 ```typescript sim-organizations-scp-allow-list
 /**
@@ -407,16 +387,13 @@ console.log(decision.denialReason);
 // "because no service control policy allows the s3:GetObject action"
 ```
 
-An account root holds unrestricted access in sim IAM, and this denies it anyway. That is what an
-SCP does in AWS, and it is why an allow list is worth writing in a test at all.
-
-Detaching `FullAWSAccess` on its own leaves the account holding no policy, and every action is then
-denied. AWS behaves the same way, and warns about it.
+SCPs still limit an account root. Removing `FullAWSAccess` without adding another allow policy denies
+every action.
 
 ## Deploy an organization from CloudFormation
 
-A template's `AWS::Organizations::*` resources build the organization they describe, so a stack
-already managing the org chart is the same one a test deploys.
+Simulated CloudFormation supports the organization, organizational unit, account and policy
+resource types.
 
 ```typescript sim-organizations-cloudformation
 /**
@@ -470,17 +447,13 @@ const decision = simAws.account("123456789012").iam().authorize({
 console.log(decision.value); // "ExplicitDeny"
 ```
 
-`Content` takes the policy document inline or as JSON text. `TargetIds` takes a list or a single
-value, and each entry names the root, a unit, or an Account. A policy reaches every target it names
-or none of them. A target this organization has never heard of fails the resource before anything is
-attached.
+`Content` accepts an object or JSON text. `TargetIds` accepts one target or a list of roots, units and
+accounts. An unknown target fails the resource before the policy is attached anywhere.
 
-A simulated environment has one organization from the start, so
-`AWS::Organizations::Organization` records the one already there rather than making another. It is
-worth declaring for `RootId`, which is what a unit hangs off.
+A `SimAws` instance starts with one organization. `AWS::Organizations::Organization` adopts it and
+exposes its `RootId`.
 
-`AWS::Organizations::Account` creates an Account with an id nobody chose, as AWS does. Read that id
-back with `Ref` or `Fn::GetAtt AccountId`.
+`AWS::Organizations::Account` generates an account ID. Read it with `Ref` or `Fn::GetAtt AccountId`.
 
 These are the properties read from each resource:
 
@@ -491,10 +464,8 @@ These are the properties read from each resource:
 | `AWS::Organizations::Account`            | `AccountName`, `Email`, `ParentIds`    | `Tags`, `RoleName`    |
 | `AWS::Organizations::Policy`             | `Name`, `Type`, `Content`, `TargetIds` | `Tags`, `Description` |
 
-Tearing the stack down takes its own policies off the nodes they were attached to, removes the
-units, and takes any Account the stack created back out of the organization. A node holding
-policies from more than one stack keeps the others. A unit that still holds something when it goes
-hands what it holds to its parent, so every Account keeps a path to the root.
+Stack teardown removes resources created by that stack. Policies from other stacks remain attached.
+Accounts and child units move to the deleted unit's parent.
 
 ## Reading a denial
 
@@ -510,21 +481,16 @@ sides, through `decision.serviceControlPolicy`:
 | `denyStatements`  | The matching `Deny` statements.                             |
 | `allowStatements` | The matching `Allow` statements.                            |
 
-`decision.denialReason` carries the wording AWS puts on the `AccessDenied` message, and every
-simulated service passes it through to the error it throws.
+`decision.denialReason` contains the text used by service access-denied errors.
 
-`simAws.organizations().serviceControlPoliciesFor(accountId)` returns the policies in force for an
-account, in the order they were evaluated, including `FullAWSAccess` where it is still attached.
+`serviceControlPoliciesFor(accountId)` returns the policies in evaluation order.
 
-`serviceControlPolicySetFor(accountId).levels` keeps the policies grouped by the node they hang on,
-root first. That grouping is what sim IAM evaluates.
+`serviceControlPolicySetFor(accountId).levels` groups policies by node, starting at the root.
 
-The flattened list is empty in three cases that behave differently. An account that was never named
-sits outside the organization and stays unrestricted. The management account is exempt and equally
-unrestricted. An account left holding no policy is denied everything. `applies` separates the last
-of those from the other two.
-`serviceControlPolicySetFor(accountId).applies` tells the two apart, and so does
-`decision.serviceControlPolicy.isApplied`.
+An empty policy list can mean that the account is outside the organization, is the management
+account or has no policies. The first two are exempt. The last is denied every action. Check
+`serviceControlPolicySetFor(accountId).applies` or `decision.serviceControlPolicy.isApplied` to
+distinguish them.
 
 ## Available functionality
 
@@ -567,7 +533,6 @@ Simulated Organizations supports:
 | Service-linked roles        | Evaluated like any other principal. AWS exempts a service-linked role from SCPs.                                                    |
 | Other policy types          | Resource control policies, declarative policies, tag policies, backup policies and AI services opt-out policies are not simulated.  |
 | The Organizations SDK       | `CreatePolicy`, `AttachPolicy`, `ListAccounts` and the rest of the API are not handled. Policies are attached through the accessor. |
-| CloudFormation              | `AWS::Organizations::Organization`, `::OrganizationalUnit`, `::Account` and `::Policy` are not created from a template.             |
 | Organization condition keys | `aws:PrincipalOrgID` and `aws:PrincipalOrgPaths` are not populated. A condition naming either fails to match.                       |
 | Service principals          | A request whose caller is a service principal or anonymous belongs to no Account and is subject to no policy.                       |
 | Condition operator coverage | The operators above are evaluated. Anything else fails closed and the statement holding it matches nothing.                         |