[jtroup]

ENG-8864

what

Merges upstream cloud-custodian e4c099e03..bf0b50dbc into
stacklet/integration and restamps the workspace onto the new
upstream hash. The base and alpha are unchanged at 0.9.53a1; only
the local version segment moves, to +bf0b50dbc. All thirteen
workspace packages are stamped uniformly, uv.lock agrees with
them, and no reference to the old hash remains.

Two commits: the upstream merge on its own, then the stamp. The
merge's combined diff (git show --cc) is empty, so there is no
hand-written content in it to review — every conflict was resolved
by taking upstream's side verbatim.

Conflicts were tests/test_tags.py,
tools/c7n_kube/c7n_kube/query.py,
tools/c7n_kube/tests/test_query_pagination.py and uv.lock. In
the three source files upstream was a strict superset of the branch:
the k8s pagination fix (cloud-custodian#11081) picked up a second
continuation-token key in cloud-custodian#11083, and test_tags.py gained a
ClientError import. uv.lock was rebuilt by just append-hash bf0b50dbc.

Upstream content picked up:

• core: a --vars-file parameter for injecting policy variables.
• aws: tag actions tolerate resources deleted mid-run;
  cloudwatch-dashboard tagging moves to the native cloudwatch APIs;
  a new apigwv2 route resource for authorization-type filtering; a
  deployments filter on bedrock-custom-model; kms and route53
  actions now skip AWS-managed resources.
• gcp: audit mode for dataproc-clusters, and an update action on
  kms-cryptokey.
• k8s: a custom-resource type for dynamic CRD discovery.
• releng: a python-requirements dependency group bump.

No Stacklet code changed.

why

Keeps stacklet/integration current with upstream so the prerelease
builds carry the latest fixes.

git log stacklet/integration..HEAD lists 34 commits, but only the
ten summarised above are new content. The previous upstream merge
(#23) was squash-merged, so upstream history never entered the
ancestry and the merge base was still a83dda5c9 — everything #23
had already brought in looked like an independent addition on both
sides, which is why files carrying no Stacklet changes conflicted at
all.

Landing this as a merge commit rather than a squash is what stops
that repeating: the first commit's second parent is bf0b50dbc, and
preserving it makes the next merge base bf0b50dbc instead of
a83dda5c9. Rebase is already disabled on the repo, so merge commit
and squash are the only two buttons.

testing

The upstream commits bring their own tests, which arrive with the
merge: placebo and terraform fixtures for the new apigwv2 route, the
bedrock deployments filter and native cloudwatch-dashboard tagging;
ec2 and elasticache cases for tagging a resource deleted mid-run;
and flight data for k8s custom-resource discovery and the gcp
dataproc and kms additions. No Stacklet code changed, so Stacklet CI
and upstream CI running on this PR is the verification.

docs

No docs needed.

---

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 1/5

The PR is not safe to merge until the Azure compatibility mismatch and the three policy-execution correctness gaps are addressed.

Findings

1.  Cosmos Version Range Is Incompatible ▶
2.  Managed Keys Remain Mutable ▶
3.  CRD Failures Return Partial Results ▶
4.  Dashboard Deletion Aborts Tagging ▶

Fix with agent prompt

### Issue 1
tools/c7n_azure/pyproject.toml:12
The dependency still allows azure-cosmos 3.x, but the updated implementation imports the v4 exception module and uses the v4 client interface. An unlocked installation can legally resolve 3.x and then fail while importing `cosmos_db.py`, making Cosmos DB resources unusable. The lower bound should require 4.x.

```suggestion
    "azure-cosmos>=4.0.0,<5.0.0",
```

### Issue 2
c7n/resources/kms.py:162-176
The new AWS-managed-key guard does not cover the existing `rename-tag` action. Because `kms-key` remains universally taggable, that action directly uses unguarded `UniversalTag` and `UniversalUntag` operations. If a policy selects an AWS-managed key, `rename-tag` still attempts forbidden mutations and fails instead of skipping the key like the newly wrapped tag actions.

### Issue 3
tools/c7n_kube/c7n_kube/resources/custom_resource.py:54-64
This catches every error while listing an individual CRD, including authorization failures, transient API failures, and implementation errors. The policy then reports success with only the resources collected before or after that failure, so governance checks can silently miss noncompliant custom resources. Only explicitly tolerated conditions should be skipped; unexpected failures need to surface.

### Issue 4
c7n/resources/cw.py:759-761
If a dashboard is deleted after augmentation but before mutation, the new `TagResource` call propagates `ResourceNotFound` and aborts the entire policy run. The new read path already treats this race as benign, but both the tag action here and the remove-tag action at lines 784–787 leave it unhandled. These actions should skip a dashboard that disappeared and continue processing the rest.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR merges upstream Cloud Custodian changes and restamps the prerelease workspace to +bf0b50dbc.

• Adds policy-variable file support and new AWS API Gateway v2 route, Bedrock deployment, tagging, KMS, and Route 53 behavior.
• Adds GCP Dataproc audit lookup and KMS CryptoKey updates.
• Adds dynamic Kubernetes custom-resource discovery.
• Updates Azure Cosmos and Terraform/HCL dependency integrations.
• Four correctness gaps remain in Azure dependency compatibility, KMS managed-key handling, Kubernetes failure reporting, and CloudWatch dashboard mutation races.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  U[Upstream bf0b50dbc] --> M[Merge into stacklet/integration]
  M --> C[Core and AWS features]
  M --> G[GCP provider updates]
  M --> K[Kubernetes CRD discovery]
  M --> A[Azure and dependency updates]
  M --> V[Workspace restamp]
  V --> P[0.9.53a1+bf0b50dbc packages]
  V --> L[uv.lock]

Loading

_{Reviews (1) · Last reviewed commit: "chore: bump version suffix to a1+bf0b50d..."}

[greptile-apps]

Cosmos version range is incompatible

The dependency still allows azure-cosmos 3.x, but the updated implementation imports the v4 exception module and uses the v4 client interface. An unlocked installation can legally resolve 3.x and then fail while importing cosmos_db.py, making Cosmos DB resources unusable. The lower bound should require 4.x.

Suggested change

	"azure-cosmos>=3.1.2,<5.0.0",
	"azure-cosmos>=4.0.0,<5.0.0",

Prompt To Fix With AI

This is a comment left during a code review.
Path: tools/c7n_azure/pyproject.toml
Line: 12

Comment:
**Cosmos version range is incompatible**

The dependency still allows azure-cosmos 3.x, but the updated implementation imports the v4 exception module and uses the v4 client interface. An unlocked installation can legally resolve 3.x and then fail while importing `cosmos_db.py`, making Cosmos DB resources unusable. The lower bound should require 4.x.

```suggestion
    "azure-cosmos>=4.0.0,<5.0.0",
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Managed keys remain mutable

The new AWS-managed-key guard does not cover the existing rename-tag action. Because kms-key remains universally taggable, that action directly uses unguarded UniversalTag and UniversalUntag operations. If a policy selects an AWS-managed key, rename-tag still attempts forbidden mutations and fails instead of skipping the key like the newly wrapped tag actions.

Prompt To Fix With AI

This is a comment left during a code review.
Path: c7n/resources/kms.py
Line: 162-176

Comment:
**Managed keys remain mutable**

The new AWS-managed-key guard does not cover the existing `rename-tag` action. Because `kms-key` remains universally taggable, that action directly uses unguarded `UniversalTag` and `UniversalUntag` operations. If a policy selects an AWS-managed key, `rename-tag` still attempts forbidden mutations and fails instead of skipping the key like the newly wrapped tag actions.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

CRD failures return partial results

This catches every error while listing an individual CRD, including authorization failures, transient API failures, and implementation errors. The policy then reports success with only the resources collected before or after that failure, so governance checks can silently miss noncompliant custom resources. Only explicitly tolerated conditions should be skipped; unexpected failures need to surface.

Prompt To Fix With AI

This is a comment left during a code review.
Path: tools/c7n_kube/c7n_kube/resources/custom_resource.py
Line: 54-64

Comment:
**CRD failures return partial results**

This catches every error while listing an individual CRD, including authorization failures, transient API failures, and implementation errors. The policy then reports success with only the resources collected before or after that failure, so governance checks can silently miss noncompliant custom resources. Only explicitly tolerated conditions should be skipped; unexpected failures need to surface.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Dashboard deletion aborts tagging

If a dashboard is deleted after augmentation but before mutation, the new TagResource call propagates ResourceNotFound and aborts the entire policy run. The new read path already treats this race as benign, but both the tag action here and the remove-tag action at lines 784–787 leave it unhandled. These actions should skip a dashboard that disappeared and continue processing the rest.

Prompt To Fix With AI

This is a comment left during a code review.
Path: c7n/resources/cw.py
Line: 759-761

Comment:
**Dashboard deletion aborts tagging**

If a dashboard is deleted after augmentation but before mutation, the new `TagResource` call propagates `ResourceNotFound` and aborts the entire policy run. The new read path already treats this race as benign, but both the tag action here and the remove-tag action at lines 784–787 leave it unhandled. These actions should skip a dashboard that disappeared and continue processing the rest.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[cubic-dev-ai]

16 issues found across 115 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="tests/terraform/ec2_instance_tag/main.tf">

<violation number="1" location="tests/terraform/ec2_instance_tag/main.tf:3">
P1: When the functional suite runs, this provider inherits `AWS_DEFAULT_REGION=us-east-2`, but `test_native_tag_skips_gone_instance` queries `us-east-1`. The test then finds zero of the provisioned instances and fails its `len(resources) == 2` assertion; pin the fixture to `us-east-1` to match the test and recorded state.</violation>
</file>

<file name="tests/terraform/bedrock_deployable_custom_model/README.md">

<violation number="1" location="tests/terraform/bedrock_deployable_custom_model/README.md:86">
P2: When rebuilding while `KEEP-c7n-deployable-test-fixture` still exists, `setup.py` submits the same `customModelName` and Bedrock rejects the duplicate name. Document deleting the existing model with `DeleteCustomModel` before rerunning the setup command.</violation>
</file>

<file name="tests/test_tags.py">

<violation number="1" location="tests/test_tags.py:840">
P2: This test does not verify that the surviving instances are actually included in either API call. The `DescribeInstances` responses are prerecorded state, so the tag assertions pass independently of `tag.process` and `remove_tag.process`; assert the `CreateTags`/`DeleteTags` request IDs or use a mutable/mock client for these calls.</violation>
</file>

<file name="tests/test_bedrock.py">

<violation number="1" location="tests/test_bedrock.py:1765">
P2: When the deployment does not become `Active`, the fixture still tries to delete it while it may be `Creating`, which Bedrock rejects and leaves the shared test deployment behind. Make teardown wait for a deletable terminal state and handle cleanup failures without masking the original test error.</violation>
</file>

<file name="tests/data/placebo/test_native_tag_skips_gone_instance/ec2.DescribeInstances_2.json">

<violation number="1" location="tests/data/placebo/test_native_tag_skips_gone_instance/ec2.DescribeInstances_2.json:145">
P2: After `tag.process`, this is the replay response used by the test's verification `describe_instances` call, but neither instance includes the `App=Custodian` tag. Add the expected `Tags` block to both instances so the fixture reflects the successful `CreateTags_2` response.</violation>
</file>

<file name="tests/terraform/bedrock_deployable_custom_model/setup.py">

<violation number="1" location="tests/terraform/bedrock_deployable_custom_model/setup.py:46">
P2: When the caller lacks `bedrock:CreateModelCustomizationJob`, AWS returns an `AccessDeniedException` containing `is not authorized`, so this predicate waits five minutes before surfacing the permanent failure. Match only assume-role propagation messages so permission errors fail immediately.</violation>
</file>

<file name="c7n/resources/cw.py">

<violation number="1" location="c7n/resources/cw.py:761">
P1: Handle `ResourceNotFound`/`ResourceNotFoundException` around both `tag_resource` and `untag_resource` calls. A dashboard deleted after augmentation currently aborts the action instead of skipping it and processing the remaining dashboards.</violation>

<violation number="2" location="c7n/resources/cw.py:791">
P2: Policies using `rename-tag` now fail validation for `cloudwatch-dashboard` because the explicit native action registrations omit it. Add a dashboard-specific rename action that performs the native tag and untag calls, or preserve equivalent rename support.</violation>
</file>

<file name="c7n/resources/kms.py">

<violation number="1" location="c7n/resources/kms.py:150">
P2: When `DescribeKey` is denied, `KeyManager` is absent and this guard treats the key as customer-managed. Treat missing or unknown `KeyManager` values as non-actionable, or resolve the metadata before allowing these mutations.</violation>

<violation number="2" location="c7n/resources/kms.py:164">
P2: When a `rename-tag` action receives an AWS-managed key carrying a stale or externally supplied old tag, it bypasses `SkipAwsManagedKey` and calls the tagging APIs, which reject the key. Register `rename-tag` with a guarded KMS wrapper as well.</violation>
</file>

<file name="tools/c7n_azure/c7n_azure/resources/cosmos_db.py">

<violation number="1" location="tools/c7n_azure/c7n_azure/resources/cosmos_db.py:8">
P1: The package still permits `azure-cosmos` 3.x, but this migration uses the v4 client and exception surface, so 3.x installations can no longer run Cosmos resources. Raise the dependency floor to `azure-cosmos>=4` or retain a v3-compatible code path.</violation>
</file>

<file name="c7n/element.py">

<violation number="1" location="c7n/element.py:42">
P2: When the package is type-checked, this closed annotation makes existing element subclasses invalid: several schemas use top-level `anyOf`/`oneOf`, and `AgeFilter.schema` is intentionally `None`. Broaden `ElementJSONSchema` to cover the supported JSON Schema keywords and nullable schemas, or use a general JSON-schema mapping type for `Element.schema`.</violation>
</file>

<file name="c7n/commands.py">

<violation number="1" location="c7n/commands.py:54">
P2: When a vars file supplies a typed policy value such as `max-resources: "{limit}"`, schema validation rejects the placeholder before `p.expand_variables` can restore the integer. Pass `vars=vars` to `policy_load`, or validate only after variable expansion.</violation>
</file>

<file name="tools/c7n_gcp/c7n_gcp/resources/kms.py">

<violation number="1" location="tools/c7n_gcp/c7n_gcp/resources/kms.py:218">
P2: When more than 20 keys are selected and an invalid-purpose key appears after the first chunk, this check raises only after earlier keys have been updated. Move the purpose validation before `MethodAction.process` starts chunking so the action fails without partially changing the selection.</violation>
</file>

<file name="tests/terraform/cloudwatch_dashboard_tag/main.tf">

<violation number="1" location="tests/terraform/cloudwatch_dashboard_tag/main.tf:3">
P2: When the Terraform environment selects a region other than `us-east-1`, this fixture creates the dashboard there but `test_cw_dashboard_tag` queries `us-east-1`, so the policy can find no dashboard. Set the provider region explicitly to `us-east-1` to match the test and fixture conventions.</violation>
</file>

<file name="tools/c7n_kube/c7n_kube/resources/custom_resource.py">

<violation number="1" location="tools/c7n_kube/c7n_kube/resources/custom_resource.py:56">
P1: Do not swallow every exception from `_list_instances`. RBAC, transient API, or implementation failures currently become partial success, so policies can miss noncompliant custom resources; let unexpected errors propagate and skip only known benign conditions.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: When the functional suite runs, this provider inherits AWS_DEFAULT_REGION=us-east-2, but test_native_tag_skips_gone_instance queries us-east-1. The test then finds zero of the provisioned instances and fails its len(resources) == 2 assertion; pin the fixture to us-east-1 to match the test and recorded state.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tests/terraform/ec2_instance_tag/main.tf, line 3:

<comment>When the functional suite runs, this provider inherits `AWS_DEFAULT_REGION=us-east-2`, but `test_native_tag_skips_gone_instance` queries `us-east-1`. The test then finds zero of the provisioned instances and fails its `len(resources) == 2` assertion; pin the fixture to `us-east-1` to match the test and recorded state.</comment>

<file context>
@@ -0,0 +1,36 @@
+# Copyright The Cloud Custodian Authors.
+# SPDX-License-Identifier: Apache-2.0
+provider "aws" {}
+
+data "aws_ami" "amazon_linux" {
</file context>

[cubic-dev-ai]

P1: The package still permits azure-cosmos 3.x, but this migration uses the v4 client and exception surface, so 3.x installations can no longer run Cosmos resources. Raise the dependency floor to azure-cosmos>=4 or retain a v3-compatible code path.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/c7n_azure/c7n_azure/resources/cosmos_db.py, line 8:

<comment>The package still permits `azure-cosmos` 3.x, but this migration uses the v4 client and exception surface, so 3.x installations can no longer run Cosmos resources. Raise the dependency floor to `azure-cosmos>=4` or retain a v3-compatible code path.</comment>

<file context>
@@ -5,7 +5,7 @@
 
 from azure.cosmos.cosmos_client import CosmosClient
-from azure.cosmos.errors import HTTPFailure
+from azure.cosmos.exceptions import CosmosHttpResponseError
 from azure.mgmt.cosmosdb.models import VirtualNetworkRule
 
</file context>

[cubic-dev-ai]

P1: Handle ResourceNotFound/ResourceNotFoundException around both tag_resource and untag_resource calls. A dashboard deleted after augmentation currently aborts the action instead of skipping it and processing the remaining dashboards.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At c7n/resources/cw.py, line 761:

<comment>Handle `ResourceNotFound`/`ResourceNotFoundException` around both `tag_resource` and `untag_resource` calls. A dashboard deleted after augmentation currently aborts the action instead of skipping it and processing the remaining dashboards.</comment>

<file context>
@@ -698,14 +727,71 @@ class resource_type(TypeInfo):
+
+    def process_resource_set(self, client, resource_set, tags):
+        for arn in self.manager.get_arns(resource_set):
+            self.manager.retry(client.tag_resource, ResourceARN=arn, Tags=tags)
+
+
</file context>

[cubic-dev-ai]

P1: Do not swallow every exception from _list_instances. RBAC, transient API, or implementation failures currently become partial success, so policies can miss noncompliant custom resources; let unexpected errors propagate and skip only known benign conditions.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/c7n_kube/c7n_kube/resources/custom_resource.py, line 56:

<comment>Do not swallow every exception from `_list_instances`. RBAC, transient API, or implementation failures currently become partial success, so policies can miss noncompliant custom resources; let unexpected errors propagate and skip only known benign conditions.</comment>

<file context>
@@ -0,0 +1,132 @@
+        for crd in self._discover_crds(session):
+            try:
+                instances.extend(self._list_instances(session, crd))
+            except Exception:
+                log.exception(
+                    "failed to list instances of CRD %s/%s %s (group=%s); "
</file context>

[cubic-dev-ai]

P2: When rebuilding while KEEP-c7n-deployable-test-fixture still exists, setup.py submits the same customModelName and Bedrock rejects the duplicate name. Document deleting the existing model with DeleteCustomModel before rerunning the setup command.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tests/terraform/bedrock_deployable_custom_model/README.md, line 86:

<comment>When rebuilding while `KEEP-c7n-deployable-test-fixture` still exists, `setup.py` submits the same `customModelName` and Bedrock rejects the duplicate name. Document deleting the existing model with `DeleteCustomModel` before rerunning the setup command.</comment>

<file context>
@@ -0,0 +1,139 @@
+cd tests/terraform/bedrock_deployable_custom_model
+tofu init
+tofu apply     # prerequisites only; no model yet
+../../../.venv/bin/python setup.py    # submits the customization job and exits
+```
+
</file context>

[cubic-dev-ai]

P2: When DescribeKey is denied, KeyManager is absent and this guard treats the key as customer-managed. Treat missing or unknown KeyManager values as non-actionable, or resolve the metadata before allowing these mutations.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At c7n/resources/kms.py, line 150:

<comment>When `DescribeKey` is denied, `KeyManager` is absent and this guard treats the key as customer-managed. Treat missing or unknown `KeyManager` values as non-actionable, or resolve the metadata before allowing these mutations.</comment>

<file context>
@@ -136,6 +137,46 @@ def alias_map(self):
+    warning so operators know why they were skipped."""
+
+    def process(self, resources):
+        excluded = [r for r in resources if r.get('KeyManager') == 'AWS']
+        if excluded:
+            self.manager.log.warning(
</file context>

[cubic-dev-ai]

P2: When the package is type-checked, this closed annotation makes existing element subclasses invalid: several schemas use top-level anyOf/oneOf, and AgeFilter.schema is intentionally None. Broaden ElementJSONSchema to cover the supported JSON Schema keywords and nullable schemas, or use a general JSON-schema mapping type for Element.schema.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At c7n/element.py, line 42:

<comment>When the package is type-checked, this closed annotation makes existing element subclasses invalid: several schemas use top-level `anyOf`/`oneOf`, and `AgeFilter.schema` is intentionally `None`. Broaden `ElementJSONSchema` to cover the supported JSON Schema keywords and nullable schemas, or use a general JSON-schema mapping type for `Element.schema`.</comment>

<file context>
@@ -16,7 +39,8 @@ class Element:
     executor_factory = ThreadPoolExecutor
 
-    schema = {'type': 'object'}
+    schema: ElementJSONSchema = {'type': 'object'}
+
     # schema aliases get hoisted into a jsonschema definition
</file context>

[cubic-dev-ai]

P2: When a vars file supplies a typed policy value such as max-resources: "{limit}", schema validation rejects the placeholder before p.expand_variables can restore the integer. Pass vars=vars to policy_load, or validate only after variable expansion.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At c7n/commands.py, line 54:

<comment>When a vars file supplies a typed policy value such as `max-resources: "{limit}"`, schema validation rejects the placeholder before `p.expand_variables` can restore the integer. Pass `vars=vars` to `policy_load`, or validate only after variable expansion.</comment>

<file context>
@@ -50,7 +51,7 @@ def _load_policies(options):
         for fp in options.configs:
             try:
-                collection = policy_load(options, fp, validate=validate, vars=vars)
+                collection = policy_load(options, fp, validate=validate)
             except IOError:
                 log.error('policy file does not exist ({})'.format(fp))
</file context>

Suggested change

	collection = policy_load(options, fp, validate=validate)
	collection = policy_load(options, fp, validate=validate, vars=vars)

[cubic-dev-ai]

P2: When more than 20 keys are selected and an invalid-purpose key appears after the first chunk, this check raises only after earlier keys have been updated. Move the purpose validation before MethodAction.process starts chunking so the action fails without partially changing the selection.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tools/c7n_gcp/c7n_gcp/resources/kms.py, line 218:

<comment>When more than 20 keys are selected and an invalid-purpose key appears after the first chunk, this check raises only after earlier keys have been updated. Move the purpose validation before `MethodAction.process` starts chunking so the action fails without partially changing the selection.</comment>

<file context>
@@ -134,6 +135,112 @@ def _get_location(cls, resource):
+        return self
+
+    def process_resource_set(self, client, model, resources):
+        if self.rotation_fields & self.data.keys():
+            invalid = [
+                r['name'] for r in resources
</file context>

[cubic-dev-ai]

P2: When the Terraform environment selects a region other than us-east-1, this fixture creates the dashboard there but test_cw_dashboard_tag queries us-east-1, so the policy can find no dashboard. Set the provider region explicitly to us-east-1 to match the test and fixture conventions.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At tests/terraform/cloudwatch_dashboard_tag/main.tf, line 3:

<comment>When the Terraform environment selects a region other than `us-east-1`, this fixture creates the dashboard there but `test_cw_dashboard_tag` queries `us-east-1`, so the policy can find no dashboard. Set the provider region explicitly to `us-east-1` to match the test and fixture conventions.</comment>

<file context>
@@ -0,0 +1,26 @@
+# Copyright The Cloud Custodian Authors.
+# SPDX-License-Identifier: Apache-2.0
+provider "aws" {}
+
+resource "random_id" "id" {
</file context>

[tvansteenburgh]

Thanks @jtroup