Forem: quixoticmonk

Terraform 1.15 Alpha: Variable and Output Deprecation

quixoticmonk — Sat, 14 Feb 2026 14:25:02 +0000

Terraform has been iterating a lot more in the past few months introducing features or updates to the core binary which were always desired. Looking at the release notes of v1.15.0-alpha20260204 version , you see a few gems.

You can set a deprecated attribute on variable and output blocks to indicate that they are deprecated. This will produce warnings when passing in a value for a deprecated variable or when referencing a deprecated output.. Its been a wish to have an easy way to manage guidance around input and output deprecation between releases of a module than just via release notes.
Terraform Test: Allow functions within mock blocks

I will focus on the first one for this post. I have a few collegues who are pretty pumped about this as they manage public and private modules.

Note: This post covers features from Terraform 1.15.0-alpha20260204. As this is an alpha release, syntax, behavior, and functionality may change before the final release. I wouldn't reccommend using this in a production setup as is.

Why is this important ?

Module authors:

I have seen many a teams end up passing the entire resource objects than specific attributes from a module as output. I feel that is lazy, but I can understand why they had to do what they had to because of past experiences when the interface of their moodule changed due to some suboptimal initial decisions. Every one has good intentions and want to fix them as soon as possible. But what about the teams who use their module ?

Module users:

When a module interfaces change, you're left scrambling through release notes trying to figure out what broke and how to fix it. A module that worked yesterday suddenly requires different inputs, or worse - outputs you depend on have changed. Without clear deprecation warnings , you only discover these issues when terraform plan fails or produces unexpected results way later in a future release.

Deprecation-Guided Migration

The deprecation feature in 1.15-alpha allows module authors to guide users through interface changes gradually. Here's how it works:

Let's establish the Terraform version I am using currently.

$ terraform version
Terraform v1.15.0-alpha20260204
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v6.31.0

Variable Deprecation

Simple message

Lets start with a simple example. No providers. No modules. Just one variable.

# main.tf
variable "ref_id" {
  type        = string
  deprecated  = "This variable will be removed in v2.0"
  description = "Reference id for service 1"
}

Run Terraform plan :

terraform plan
var.ref_id
  Reference id for service 1

  Enter a value: 234dfeff-123213dsad-12dsad


No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no
differences, so no changes are needed.
╷
│ Warning: Deprecated variable got a value
│
│   on main.tf line 3, in variable "ref_id":
│    1: variable "ref_id" {
│    2:   type        = string
│    3:   deprecated  = "This variable will be removed in v2.0"
│
│ This variable will be removed in v2.0

This looks awfully similar to the provider attribute deprecations you may have seen between major versions, the .name vs .region one for aws_region datasource for example.

The only thing with this example is that when you run terraform validate with a default value set for the var, it doesn't show any deprecation messages.

variable "ref_id" {
  type        = string
  default     = "1213123"
  deprecated  = "This variable will be removed in v2.0"
  description = "Reference id for service 1"
}

On Validate

tf validate
Success! The configuration is valid.

Structured message

variable "ref_id" {
  type        = string
  deprecated  = <<-EOT
      ⚠️ This variable is deprecated and will be removed in v2.0.

      Migration steps:
      1. Replace with 'ref_name' for the primary value
      2. See release notes here: https://example.com
    EOT
  description = "Reference id for service 1"
}

Terraform plan gives you :


terraform plan
var.ref_id
  Reference id for service 1

  Enter a value: 234dfeff-123213dsad-12dsad

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no
differences, so no changes are needed.
╷
│ Warning: Deprecated variable got a value
│
│   on main.tf line 3, in variable "ref_id":
│    1: variable "ref_id" {
│    2:   type        = string
│    3:   deprecated  = <<-EOT
│    4:       ⚠️ This variable is deprecated and will be removed in v2.0.
│    5:       Migration steps:
│    6:       1. Replace with 'ref_name' for the primary value
│    7:       2. See release notes here: https://example.com
│    8:     EOT
│
│ ⚠️ This variable is deprecated and will be removed in v2.0.
│
│ Migration steps:
│ 1. Replace with 'ref_name' for the primary value
│ 2. See release notes here: https://example.com
│
╵

Function support ?

Let's test this. OK. I know I am pushing the example here :) But let's see how the feature behaves.

variable "ref_id" {
  type        = string
  deprecated  = title("This variable is deprecated and will be removed in v2.0.")
  description = "Reference id for service 1"
}

Terraform plan/validate :

terraform plan
╷
│ Error: Unsuitable value type
│
│   on main.tf line 3, in variable "ref_id":
│    3:   deprecated  = title("This variable is deprecated and will be removed in v2.0.")
│
│ Unsuitable value: value must be known
╵
╷
│ Error: Function calls not allowed
│
│   on main.tf line 3, in variable "ref_id":
│    3:   deprecated  = title("This variable is deprecated and will be removed in v2.0.")
│
│ Functions may not be called here.

Functions are not supported. But what about the Unsuitable value: value must be known message.

variable "ref_id" {
  type        = string
  deprecated  = null
  description = "Reference id for service 1"
}

Aaah, the use of a function left the deprecated value to be null. Supported by the result below.

terraform plan
╷
│ Error: Unsuitable value type
│
│   on main.tf line 3, in variable "ref_id":
│    3:   deprecated  = null
│
│ Unsuitable value: null value is not allowed
╵

Empty String:

variable "ref_id" {
  type        = string
  deprecated  = "" # empty string is supported
  description = "Reference id for service 1"
}

Empty string result:


terraform plan
var.ref_id
  Reference id for service 1

  Enter a value: 234dfeff-123213dsad-12dsad

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no
differences, so no changes are needed.
╷
│ Warning: Deprecated variable got a value
│
│   on main.tf line 3, in variable "ref_id":
│    1: variable "ref_id" {
│    2:   type        = string
│    3:   deprecated  = ""
│

So how have you handled deprecations of inputs in modules before ?

Module example

The usage doesn't change much for variables from within a module.

# modules/app/main.tf
variable "ref_id" {
  type        = string
  default     = null
  deprecated  = "⚠️ Pass 'ref_name' instead of the variable. This will be removed in v2.0"
  description = "Reference id for service 1"
}

variable "ref_name" {
  type        = string
  default     = null
  description = "Reference name for service 1"
}

# Handle both old and new patterns during transition
locals {
  actual_ref = var.ref_id != null ? var.ref_id : var.ref_name
}


# main.tf
module "app_with_deprecations" {
  source = "./modules/app"
  ref_id = "234dfeff-123213dsad-12dsad"
}

On Terraform plan:

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no
differences, so no changes are needed.
╷
│ Warning: Deprecated variable got a value
│
│   on main.tf line 3, in module "app_with_deprecations":
│    3:   ref_id = "234dfeff-123213dsad-12dsad"
│
│ ⚠️ Pass 'ref_name' instead of the variable. This will be removed in v2.0
╵

Outputs

Lets switch to how the outputs behave in this case.

Module outputs

# modules/app/main.tf
variable "ref_id" {
  type        = string
  default     = null
  deprecated  = "⚠️ Pass 'ref_name' instead of the variable. This will be removed in v2.0"
  description = "Reference id for service 1"
}

variable "ref_name" {
  type        = string
  default     = null
  description = "Reference name for service 1"
}

...

output "old_value" {
  value      = var.ref_id
  deprecated = "⚠️ Pass 'name_value' instead of the output. This will be removed in v2.0"
}

output "new_value" {
  value = var.ref_name
}

Terraform plan or apply:

You can apply this plan to save these new output values to the Terraform state, without changing
any real infrastructure.
╷
│ Warning: Deprecated variable got a value
│
│   on main.tf line 3, in module "app_with_deprecations":
│    3:   ref_id = "234dfeff-123213dsad-12dsad"
│
│ ⚠️ Pass 'ref_name' instead of the variable. This will be removed in v2.0
│
│ (and 2 more similar warnings elsewhere)
╵
╷
│ Warning: Deprecated value used
│
│   on main.tf line 7, in output "mod_out":
│    7:   value = module.app_with_deprecations.old_value
│
│   The deprecation originates from module.app_with_deprecations.old_value
│
│ ⚠️ Pass 'name_value' instead of the output. This will be removed in v2.0
│
│ (and one more similar warning elsewhere)
╵

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

mod_out = "234dfeff-123213dsad-12dsad"

What about root module outputs ?

# main.tf
output "mod_out" {
  value      = "Deprecated value"
  deprecated = "This is not supported :) "
}

Terraform plan or apply:

│ Error: Root module output deprecated
│
│   on main.tf line 3, in output "mod_out":
│    3:   deprecated = "This is not supported :) "
│
│ Root module outputs cannot be deprecated, as there is no higher-level module to inform of the
│ deprecation.
╵

Only module outputs can be deprecated, not root module outputs. And as the message indicates, it makes sense as there is no higher level module which should know.

Deprecation Suppression flag

I was a little confused at first on how this would work. It was a little bit of trial and error to see how the suppression works. And I did keep trying with the wrong flag too ( suppress_deprecations_warnigns based on the PR ) In short :

The ignore_nested_deprecations attribute lets you suppress these internal warnings while still being alerted when you use deprecated outputs from the module.

Understanding `Internal` vs `Your` Warnings

Let's create a module structure to demonstrate:

# modules/legacy/nested/main.tf
output "deprecated_output" {
  deprecated = "This nested output is deprecated"
  value      = "nested-value"
}

# modules/legacy/main.tf
output "old_api" {
  deprecated = "Use new_api instead"
  value      = "legacy-value"
}

output "new_api" {
  value = "new-value"
}

module "nested" {
  source = "./nested"
}

# This usage inside the module generates an "internal" warning
locals {
  internal_use = module.nested.deprecated_output
}

Lets test this across 4 scenarios

I am including both the responses from terraform validate and terraform plan on all these scenarios as the latter did show me the additional collapsed warning messages which I believe are due to my usage of the module output.

Scenario 1: No suppression, output defined

# main.tf
module "with_warnings" {
  source = "./modules/legacy"
}

output "test_output" {
  value = module.with_warnings.old_api
}

tf validate
╷
│ Warning: Deprecated value used
│
│   on main.tf line 10, in output "test_output":
│   10:   value = module.with_warnings.old_api
│
│   The deprecation originates from module.with_warnings.old_api
│
│ Use new_api instead
│
│ (and one more similar warning elsewhere)
╵
Success! The configuration is valid, but there were some validation warnings as shown above.


experiments/deprecation_notice/test-example via 💠 default
❯ tf plan

Changes to Outputs:
  + test_output = "legacy-value"

You can apply this plan to save these new output values to the Terraform state, without changing any real
infrastructure.
╷
│ Warning: Deprecated value used
│
│   on main.tf line 10, in output "test_output":
│   10:   value = module.with_warnings.old_api
│
│   The deprecation originates from module.with_warnings.old_api
│
│ Use new_api instead
│
│ (and 3 more similar warnings elsewhere)
╵

──────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these
actions if you run "terraform apply" now.

Result: validate shows 2 warnings - your usage of deprecated output + internal module usage while plan shows 4 in total.

Scenario 2: No suppression, output commented

# main.tf
module "with_warnings" {
  source = "./modules/legacy"
}

# output "test_output" {
#   value = module.with_warnings.old_api
# }

tf validate
╷
│ Warning: Deprecated value used
│
│   on modules/legacy/main.tf line 16, in locals:
│   16:   internal_use = module.nested.deprecated_output
│
│   The deprecation originates from module.nested.deprecated_output
│
│ This nested output is deprecated
╵
Success! The configuration is valid, but there were some validation warnings as shown above.


experiments/deprecation_notice/test-example via 💠 default
❯ tf plan

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no
changes are needed.
╷
│ Warning: Deprecated value used
│
│   on modules/legacy/main.tf line 16, in locals:
│   16:   internal_use = module.nested.deprecated_output
│
│   The deprecation originates from module.nested.deprecated_output
│
│ This nested output is deprecated
│
│ (and one more similar warning elsewhere)

Result: validate shows 1 warning - only the internal module's use of nested deprecated output. Plan shows 2.

Scenario 3: Suppression enabled, output commented

# main.tf
module "suppressed" {
  source                     = "./modules/legacy"
  ignore_nested_deprecations = true
}

# output "test_output" {
#   value = module.suppressed.old_api
# }

tf validate
Success! The configuration is valid.


experiments/deprecation_notice/test-example via 💠 default
❯ tf plan

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no
changes are needed.

Result: Shows 0 warnings - internal deprecation suppressed, no root usage

Scenario 4: Suppression enabled, output defined

# main.tf
module "suppressed" {
  source                     = "./modules/legacy"
  ignore_nested_deprecations = true
}

output "test_output" {
  value = module.suppressed.old_api
}

tf validate
╷
│ Warning: Deprecated value used
│
│   on main.tf line 11, in output "test_output":
│   11:   value = module.suppressed.old_api
│
│   The deprecation originates from module.suppressed.old_api
│
│ Use new_api instead
╵
Success! The configuration is valid, but there were some validation warnings as shown above.


experiments/deprecation_notice/test-example via 💠 default
❯ tf plan

Changes to Outputs:
  + test_output = "legacy-value"

You can apply this plan to save these new output values to the Terraform state, without changing any real
infrastructure.
╷
│ Warning: Deprecated value used
│
│   on main.tf line 11, in output "test_output":
│   11:   value = module.suppressed.old_api
│
│   The deprecation originates from module.suppressed.old_api
│
│ Use new_api instead
│
│ (and one more similar warning elsewhere)

Result: validate shows 1 warning - your usage still warned, internal deprecation suppressed. Plan shows 2 as it was previously.

I think it would come in handy if I am using third party modules with deprecations I can't fix or has changes which I don't technically use or care about in my usage. At the same time , I want deprecations in my own module to be surfaced to the users. Hopefully that helps to understand how the ignore_nested_deprecations functions.

Conclusion

Terraform 1.15's deprecation feature addresses a pain point in module upgrades and management. It provides module authors with the tools they need to improve their interfaces while maintaining backward compatibility and giving users clear guidance on module usage.

Adding agent skills for Terraform

quixoticmonk — Sat, 14 Feb 2026 14:09:23 +0000

MCP exploded. There is no better way to say that. Every developer I knew had at least a handful of those MCP servers running with their coding agents. But the context overload with all those was massive and I found myself seeing messages around context overflow a fair few times. I know for a fact that most of the MCP servers I have enabled and the tool definitions they have were not needed to be read by the agent all the time.

So how do I solve this context bloat while ensuring I can give all the necessary information required for the model to give me that desired result? I have been hearing or reading about a few things which could help:

Skills ( was a Claude-only thing till it was made an open spec)
Powers in kiro ( an IDE based approach and not yet in kiro CLI)
Code execution with MCP server ( Maybe for another post)

The curiosity around skills peaked with Anton's terraform skills and the official HashiCorp agent skills. My experience with using it with kiro CLI is documented here. But how do you create your own skill if one doesn't exist ? The process of testing and refining a new skill turned into a great learning experience about how these skills work in practice.

So what's the problem statement?

I need a mechanism to effectively inform my agent to create the desired configuration to help bring existing cloud resources under Terraform management. If you hear, the first thing that comes to mind ( and should ) is import statements or blocks. The terraform-search-import skill I am discussing here aims to address that challenge. I do feel there is a need for No so green field series on infrastructure management.

So how do did end up here ? Most organizations have infrastructure that wasn't originally created with Terraform:

Resources created through AWS Console, CLI, or other tools during some POC phase OR
Legacy infrastructure that predates Infrastructure as Code adoption

Traditionally, importing these resources into Terraform required:

Manual discovery - Finding all resources across your cloud accounts
Manual configuration writing - Creating HCL resource blocks for each resource
Manual import commands - Running terraform import for each resource individually
Trial and error - Getting the resource configuration exactly right

This process is time-consuming, error-prone, and doesn't scale when you have dozens or hundreds of resources. Terraform introduced a step by step improvement on this approach with the config driven imports and then with Terraform search. The intention with the skill is to handle these scenarios based on the user situation and version constraints they may have.

How does it work ?

Ideally, the pre-requisites around the version constraints are met and a user is able to leverage this skill to use Terraform's new Search functionality to automate the discovery and import:

Automated Discovery: Uses .tfquery.hcl files to query for existing resources. These are provider dependent and not every provider has every list provider possible. AWSCC provider is an exception with support for more than 100s of resources.
Automated Generation: Creates Terraform resource blocks with current configurations automatically
Config driven import method: Generates import blocks using the terraform query subcommands.

I already had documented some instructions which I was using my agents to help import existing resources. All it needed was identifying the agent skills structure and then porting the necessary instructions when needed.

Adding the Skill

For testing, I needed to set up the terraform-search-import skill in my local Kiro environment. Since this was a new skill which doesn't exist in the upstream package, I had to create it from scratch following the agent skill specification and using existing skills as reference. To be honest, the skills documentation is pretty straightforward when it comes to guiding you on what is expected.

Note : If your SKILL.md file is growing with examples and lots of external references, you should look at adding them under a directory called references. Agent skill specifications are able to load these reference documents in a lazy manner. Only when they are needed. This helps to reduce the context which is made available to the model. Overload of information doesn't always translate to the best results.

Below were some of the steps specifically for kiro as the CLI references the skill documents as Skill resources.

Create the skill directory structure:

   mkdir -p ~/.kiro/agents/terraform-search-import/references

Create the main skill file (SKILL.md) with proper YAML frontmatter:

   ---
   name: terraform-search-import
   description: Discover existing cloud resources using Terraform Search queries and bulk import them into Terraform management. Use when bringing unmanaged infrastructure under Terraform control, auditing cloud resources, or migrating to IaC.
   ---

Add any supporting documentation or examples in the references/ directory.

Let's be honest . Did I start this way ? Not really. I had 500+ lines of information in my original SKILL.md file. One of the redundant items in my original SKILL.md file were the scenarios I wanted to cover.

Scenario where the list resource existed for a provider.
- Follows the logic we outlined above.
Where a list resource didn't exist for the resource in a provider.
- Gather the information using the Cloud provider's CLI or API and use the resource identity in a config driven import.
Where the Terraform version if below the required 1.14.0 version.
- Gather the information using the Cloud provider's CLI or API and use the resource identity in a config driven import.

What list resources are supported ?

How can we solve this ?

Well, you could have the Terraform MCP server look for the resources everytime we needed against a provider. OR
Look at the supported list resources I maintain as an automated workflow. OR
Execute a deterministic script agains the providers in question.

If you look at the Agent Skills specification, there is an additional optional directory a skill can hold.

`/scripts`

The repository I linked above for my list of provider supported list resources were essentially banking on the terraform providers schema json file. The script in the repository identified the list/action resources for each provider schema we fed into the script. How do we get that ? Add a provider block into a .tf file and run terraform init.

So what if I moved the list resource discovery into a deterministic script ? So the MCP server doesn't need to do this either.

Testing the Skill in Practice

So we have the following resources in the directory kiro CLI is expecting them to be in :

SKILL.md file
/references for edge cases and additional scenarios
/scripts to hold scripts( if needed)

Copying this into the .kiro/agents/skills directory is all I needed to have kiro-cli identify it as an available skill on the next session. It helps that the agent configuration was using wild characters in the skills resource block.

"resources": ["skill://~/.kiro/skills/**/SKILL.md"]

Actual tests

Lets run through couple of scenarios.

Test 1 : Supported resources and TF version above 1.14.0

With the skill created and installed( or added to the directory ), I tested it with the request "Create the terraform configuration for importing the S3 buckets from my AWS account."

Here's the complete session log:

Create the terraform configuration for importing the S3 buckets from my AWS account.
I'll help you create Terraform configuration to import existing S3 buckets from your AWS account. Let me use the terraform-search-import skill to discover and import
your S3 buckets.
Reading file: /Users/user_name/.kiro/skills/terraform-search-import/SKILL.md, all lines (using tool: read)
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[iac] > t

✓ Successfully read 9116 bytes from /Users/user_name/.kiro/skills/terraform-search-import/SKILL.md

Completed in 0.1s
Now I'll create a minimal Terraform configuration to discover and import your S3 buckets. First, let me check what list resources are available for the AWS provider:
I'll create the following file: /Users/user_name/Documents/2026/experiments/agent-skills/terraform.tf (using tool: write)
Purpose: Create basic Terraform configuration with AWS provider

1: terraform {
2: required_version = ">= 1.14"
3: required_providers {
4: aws = {
5: source = "hashicorp/aws"
6: version = "~> 6.0"
7: }
8: }
9: }
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[iac] > t

Creating: /Users/user_name/Documents/2026/experiments/agent-skills/terraform.tf

Completed in 0.3s
I will run the following command: cd /Users/user_name/Documents/2026/experiments/agent-skills && terraform init (using tool: shell)
Purpose: Initialize Terraform to download AWS provider

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[iac] > t

Initializing the backend...
Initializing provider plugins...

Finding hashicorp/aws versions matching "~> 6.0"...
Installing hashicorp/aws v6.31.0...
Installed hashicorp/aws v6.31.0 (signed by HashiCorp)
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.
Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Completed in 25.674s
Now let me check what list resources are available for S3:
I will run the following command: cd /Users/user_name/Documents/2026/experiments/agent-skills && terraform providers schema -json | jq '.provider_schemas."registry.terraform.io/hashicorp/aws".list_resource_schemas | keys | .[]' | grep -i s3 (using tool: shell)
Purpose: Check if S3 bucket list resources are supported

"aws_s3_bucket"
"aws_s3_bucket_acl"
"aws_s3_bucket_policy"
"aws_s3_bucket_public_access_block"
"aws_s3_object"

Completed in 2.69s
Great! The AWS provider supports aws_s3_bucket list resources. Now I'll create the query file to discover your S3 buckets:
I'll create the following file: /Users/user_name/Documents/2026/experiments/agent-skills/discovery.tfquery.hcl (using tool: write)
Purpose: Create Terraform query file to discover all S3 buckets

1: provider "aws" {
2: region = "us-east-1"
3: }
4:
5: list "aws_s3_bucket" "all" {
6: provider = aws
7: }
Creating: /Users/user_name/Documents/2026/experiments/agent-skills/discovery.tfquery.hcl

Completed in 0.1s
Now let's run the query to discover your S3 buckets:
I will run the following command: cd /Users/user_name/Documents/2026/experiments/agent-skills && terraform query (using tool: shell)
Purpose: Execute Terraform query to discover S3 buckets

list.aws_s3_bucket.all account_id=############,bucket=agentcore-cicd-terraform-state-d1f38556,region=us-east-1 agentcore-cicd-terraform-state-d1f38556
list.aws_s3_bucket.all account_id=############,bucket=aws-glue-assets-############-us-east-1,region=us-east-1 aws-glue-assets-############-us-east-1
list.aws_s3_bucket.all account_id=############,bucket=awscc-tool-use-2fqr-assets,region=us-east-1 awscc-tool-use-2fqr-assets
list.aws_s3_bucket.all account_id=############,bucket=bedrock-s3-kb,region=us-east-1 bedrock-s3-kb
list.aws_s3_bucket.all account_id=############,bucket=bedrock-video-generation-us-east-1-ymeqc5,region=us-east-1 bedrock-video-generation-us-east-1-ymeqc5

Completed in 76.725s
Perfect! Now let's generate the Terraform configuration for importing all these S3 buckets:
I will run the following command: cd /Users/user_name/Documents/2026/experiments/agent-skills && terraform query -generate-config-out=s3-buckets.tf (using tool: shell)
Purpose: Generate Terraform configuration for importing S3 buckets

list.aws_s3_bucket.all account_id=############,bucket=agentcore-cicd-terraform-state-d1f38556,region=us-east-1 agentcore-cicd-terraform-state-d1f38556
list.aws_s3_bucket.all account_id=############,bucket=aws-glue-assets-############-us-east-1,region=us-east-1 aws-glue-assets-############-us-east-1
list.aws_s3_bucket.all account_id=############,bucket=awscc-tool-use-2fqr-assets,region=us-east-1 awscc-tool-use-2fqr-assets
list.aws_s3_bucket.all account_id=############,bucket=bedrock-s3-kb,region=us-east-1 bedrock-s3-kb
list.aws_s3_bucket.all account_id=############,bucket=bedrock-video-generation-us-east-1-ymeqc5,region=us-east-1 bedrock-video-generation-us-east-1-ymeqc5
list.aws_s3_bucket.all account_id=############,bucket=cdk-hnb659fds-assets-############-us-east-1,region=us-east-1 cdk-hnb659fds-assets-############-us-east-1
list.aws_s3_bucket.all account_id=############,bucket=cf-templates-1xfr5l1bee3rm-us-east-1,region=us-east-1 cf-templates-1xfr5l1bee3rm-us-east-1

Completed in 57.567s
Let me check the generated configuration file:
Reading file: /Users/user_name/Documents/2026/experiments/agent-skills/s3-buckets.tf, from line 1 to 50 (using tool: read)
✓ Successfully read 1221 bytes from /Users/user_name/Documents/2026/experiments/agent-skills/s3-buckets.tf

Completed in 0.0s
Perfect! I've successfully created a Terraform configuration to import all your S3 buckets. Here's what was generated:

Files Created:
terraform.tf - Provider configuration
discovery.tfquery.hcl - Query file to discover S3 buckets
s3-buckets.tf - Generated configuration with 36 S3 buckets and their import blocks
What's Included:
Resource blocks for all 36 S3 buckets in your account
Import blocks using identity-based import (Terraform 1.12+)
All current bucket configurations including tags, settings, and timeouts
Next Steps:
Review the generated configuration in s3-buckets.tf
Clean up the configuration by removing computed attributes and null values
Run the import:
bash
terraform plan
terraform apply
The configuration includes buckets for various services like:

Terraform state buckets
AWS service buckets (Glue, SageMaker, CodePipeline)
Application buckets
CDK and CloudFormation assets
All buckets are ready to be imported into Terraform state management using the modern identity-based import method.

The entire process took about 2 minutes and successfully discovered 36 S3 buckets across my account, generating complete Terraform configuration ready for import.

Test 2 : TF version below 1.14.0

Write the necessary Terraform configuration to import my existing S3 buckets from the AWS account into Terraform management. The S3 buckets to import have a prefix of awscc-tool. 

> I'll help you import your existing S3 buckets with the "awscc-tool" prefix into Terraform management. Let me use the terraform-search-import skill to discover and
import these resources.
Reading file: /Users/manuchn/.kiro/skills/terraform-search-import/SKILL.md, all lines (using tool: read)
 ✓ Successfully read 8591 bytes from /Users/manuchn/.kiro/skills/terraform-search-import/SKILL.md
 - Completed in 0.0s

> Now I'll check what list resources are available for S3 buckets and create the necessary configuration to discover and import your S3 buckets with the "awscc-tool"
prefix.
I will run the following command: terraform version (using tool: shell)
Purpose: Check Terraform version to ensure it supports Terraform Search (requires >= 1.14)

Terraform v1.13.0
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v6.31.0

Your version of Terraform is out of date! The latest version
is 1.14.4. You can update by downloading from https://developer.hashicorp.com/terraform/install
 - Completed in 0.136s

> Since your Terraform version is 1.13.0 (below the required 1.14 for Terraform Search), I'll use the AWS CLI approach to discover your S3 buckets and generate the
import configuration manually.
Running aws cli command (using tool: aws):

Service name: s3api
Operation name: list-buckets
Parameters:
Region: us-east-1
Label: List all S3 buckets to find ones with awscc-tool prefix - Completed in 2.165s

> Perfect! I found 3 S3 buckets with the "awscc-tool" prefix:
1. awscc-tool-use-2fqr-assets
2. awscc-tool-use-ezct-artifacts
3. awscc-tool-use-ezct-assets

It correctly identified that the Terraform version was below 1.14.0 and the query command wouldn't be supported in that case. I skipped the rest of the steps in the snippet above as kiro went on to add the config driven import blocks based on the names retrieved with the S3 API.

Effectiveness of what you wrote

As a non-native English speaker, I do struggle with finding the right balance in my writing- either over-explaniing or being too brief.So how do I make this effective ? This is an area I didn't have any experience or idea about. The HashiCorp blog about the agent-skills mentioned tessl being used to evaluate and improve the skills they had written. So after the initial bit of testing with the copied skill, I started looking at tessl.

You have a few ways to do this evaluation. If you use the tessl npm package, you can publish the skill on to the registry which is auto evaluated. Or as in my case, run the evaluation locally since I am submitting this as an additional skill to the existing agent-skills bundle under HashiCorp namespace.

As you would have figured, I went the latter route.

Installation

As with any npm library, it is as simple as :

npm install -g @tessl/cli

Review

Let's review using the tessl skill review command.


> tessl skill review  ~/.kiro/skills/terraform-search-import

Validation Checks

  ✔ skill_md_line_count - SKILL.md line count is 374 (<= 500)
  ✔ frontmatter_valid - YAML frontmatter is valid
  ✔ name_field - 'name' field is valid: 'terraform-search-import'
  ✔ description_field - 'description' field is valid (227 chars)
  ✔ description_voice - 'description' uses third person voice
  ✔ description_trigger_hint - Description includes an explicit trigger hint
  ✔ compatibility_field - 'compatibility' field is valid (104 chars)
  ✔ allowed_tools_field - 'allowed-tools' field not present (optional)
  ✔ metadata_version - 'metadata.version' is present: 0.1.0
  ✔ metadata_field - 'metadata' contains 2 entries
  ⚠ license_field - 'license' field is missing
  ✔ frontmatter_unknown_keys - No unknown frontmatter keys found
  ✔ body_present - SKILL.md body is present
  ✔ body_examples - Examples detected (code fence or 'Example' wording)
  ✔ body_output_format - Output/return/format terms detected
  ✔ body_steps - Step-by-step structure detected (ordered list)

Overall: PASSED (0 errors, 1 warnings)

Judge Evaluation

  Description: 100%
    specificity: 3/3 - Lists multiple specific concrete actions: 'Discover existing cloud resources', 'Terraform Search queries', 'bulk import them into Terraform management'. These are clear, actionable capabilities.
    trigger_term_quality: 3/3 - Includes natural keywords users would say: 'cloud resources', 'Terraform', 'import', 'unmanaged infrastructure', 'IaC', 'auditing', 'migrating'. Good coverage of terms for infrastructure-as-code workflows.
    completeness: 3/3 - Clearly answers both what ('Discover existing cloud resources using Terraform Search queries and bulk import them') AND when ('Use when bringing unmanaged infrastructure under Terraform control, auditing cloud resources, or migrating to IaC').
    distinctiveness_conflict_risk: 3/3 - Clear niche focused specifically on Terraform import/discovery workflows. The combination of 'Terraform Search', 'bulk import', and 'unmanaged infrastructure' creates distinct triggers unlikely to conflict with general Terraform or cloud skills.

    Assessment: This is a well-crafted skill description that excels across all dimensions. It provides specific actions (discover, search, bulk import), includes natural trigger terms users would actually say, explicitly states both capabilities and usage scenarios, and carves out a distinct niche within the Terraform ecosystem focused on import workflows.

  Content: 77%
    conciseness: 2/3 - The content is mostly efficient but includes some redundancy - the workflow is explained multiple times (overview section, then detailed sections, then complete example). Some sections like 'When to Use' list items that are somewhat obvious given the skill description.
    actionability: 3/3 - Excellent executable examples throughout - complete HCL configurations, bash commands, and a full end-to-end workflow example. Code is copy-paste ready with realistic values and clear syntax.
    workflow_clarity: 3/3 - Clear 5-step workflow with explicit sequence. Includes validation checkpoint ('Review and refine generated resource and import blocks') and the 'Best Practices' section emphasizes running plan before apply and backing up state. The complete example at the end reinforces the workflow.
    progressive_disclosure: 2/3 - Good structure with clear sections and a reference table, but the content is quite long (~300 lines) and could benefit from splitting detailed examples or the troubleshooting table into separate reference files. The external references at the top are appropriate but internal organization could be improved.

    Assessment: This is a well-structured, highly actionable skill with excellent executable examples and clear workflow guidance. The main weakness is length - the content could be more concise by removing some redundancy (workflow explained multiple times) and potentially splitting detailed reference material into separate files. The safety considerations around state management are appropriately emphasized.

    Suggestions:
      - Consider moving the detailed 'Query Examples' section to a separate EXAMPLES.md file and keeping only 1-2 examples inline
      - Remove the 'When to Use' section as it duplicates the skill description and is self-evident from the content

Average Score: 89%

✔ Skill evaluation completed successfully!

Not bad for an initial skill reference. Re-run after making some changes it suggested.

❯ tessl skill review  ~/.kiro/skills/terraform-search-import

Validation Checks

  ✔ skill_md_line_count - SKILL.md line count is 369 (<= 500)
  ✔ frontmatter_valid - YAML frontmatter is valid
  ✔ name_field - 'name' field is valid: 'terraform-search-import'
  ✔ description_field - 'description' field is valid (227 chars)
  ✔ description_voice - 'description' uses third person voice
  ✔ description_trigger_hint - Description includes an explicit trigger hint
  ✔ compatibility_field - 'compatibility' field is valid (104 chars)
  ✔ allowed_tools_field - 'allowed-tools' field not present (optional)
  ✔ metadata_version - 'metadata.version' is present: 0.1.0
  ✔ metadata_field - 'metadata' contains 2 entries
  ⚠ license_field - 'license' field is missing
  ✔ frontmatter_unknown_keys - No unknown frontmatter keys found
  ✔ body_present - SKILL.md body is present
  ✔ body_examples - Examples detected (code fence or 'Example' wording)
  ✔ body_output_format - Output/return/format terms detected
  ✔ body_steps - Step-by-step structure detected (ordered list)

Overall: PASSED (0 errors, 1 warnings)

Judge Evaluation

  Description: 100%
    specificity: 3/3 - Lists multiple specific concrete actions: 'Discover existing cloud resources', 'Terraform Search queries', 'bulk import them into Terraform management'. These are clear, actionable capabilities.
    trigger_term_quality: 3/3 - Includes natural keywords users would say: 'cloud resources', 'Terraform', 'import', 'unmanaged infrastructure', 'IaC', 'auditing', 'migrating'. Good coverage of terms for infrastructure-as-code workflows.
    completeness: 3/3 - Clearly answers both what ('Discover existing cloud resources using Terraform Search queries and bulk import them') AND when ('Use when bringing unmanaged infrastructure under Terraform control, auditing cloud resources, or migrating to IaC').
    distinctiveness_conflict_risk: 3/3 - Clear niche focused specifically on Terraform import/discovery workflows. The combination of 'Terraform Search', 'bulk import', and 'unmanaged infrastructure' creates distinct triggers unlikely to conflict with general Terraform or cloud skills.

    Assessment: This is a well-crafted skill description that excels across all dimensions. It provides specific actions (discover, search, bulk import), includes natural trigger terms users would actually say, explicitly states both capabilities and usage scenarios, and carves out a distinct niche within the Terraform ecosystem focused on import workflows.
  Content: 85%
    conciseness: 2/3 - The content is mostly efficient but includes some redundancy - the prerequisites section repeats the discovery script information, and some explanations (like the query output format) could be more compact. The post-generation cleanup section with before/after examples is valuable but slightly verbose.
    actionability: 3/3 - Excellent executable guidance throughout with complete, copy-paste ready HCL configurations and bash commands. The complete example at the end provides a full workflow with real commands. All code blocks are executable, not pseudocode.
    workflow_clarity: 3/3 - Clear decision tree upfront, explicit 5-step workflow, and the complete example shows the exact sequence with validation steps (terraform plan before apply). The 'Check Provider Support First' section with IMPORTANT callout establishes a critical validation checkpoint before proceeding.
    progressive_disclosure: 3/3 - Well-structured with clear sections progressing from prerequisites to basic to advanced usage. References external documentation appropriately (HashiCorp docs, MANUAL-IMPORT.md for unsupported resources). Content is appropriately organized without being monolithic or requiring deep navigation.

    Assessment: This is a strong, well-structured skill that provides actionable guidance for Terraform resource discovery and bulk import. The decision tree and explicit workflow steps make it easy to follow, and the code examples are complete and executable. Minor verbosity in some sections (prerequisites, cleanup examples) prevents a perfect conciseness score, but overall the content earns its place.

Average Score: 93%

✔ Skill evaluation completed successfully!

I left it there without over optimizing it based on some feedback notes I saw. Why do I feel this is important ? Working with an open spec, a tool like this can guide you on how you can make your skills effective. Keep your tests handy and re-run after changes you make. Sometimes it is just a change in order which makes a world of difference.

Learnings

If I have to start on a new agent skill tomorrow ( without some basline ) I would probably one of the below approaches:
- tessl gives you tessl skill new workflow with the npm library to get you started.
- Anthropic gives you a skill creator skill which you can possible use to start.
As with any of these instructions, you have to be clear about the versions your features are available in. Terraform search requires the user to have both terraform versions above 1.14.0 and using a provider version which has list resource support.
- I had to explicitly mention to remove version constraints on the provider block to get the latest version always in the instructions.
Compatibility requirements : I had mixed results with this parameter which I am keeping for now and will revisit later to refine further if needed.

Conclusion

It was a fun experiment to see some of my existing instructions I had in my documents could be used to create a skill to import existing resources under Terraform management. The effort required in this case was minimal considering I had the instructions in various markdowns in my machine. tessl review helps to know what else could be optimized to efficiently manage what the model sees when it is made aware of the available skills. What's next ? I think the ephemerality and actions based approaches could use some nudge among practitioners.

Note : As of today, my changes are on an active PR being reviewed.

References:

Kiro CLI skill resources : https://kiro.dev/docs/cli/custom-agents/configuration-reference/#skill-resources
Context engineering : https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Kiro has Terraform skills

quixoticmonk — Tue, 03 Feb 2026 04:14:53 +0000

Cross posted from https://manuchandrasekhar.com/posts/2026/01-27-kiro-terraform-skills/

Powers and now Skills. Kiro's 1.24.0 version just added support for Skills, the new open spec for giving agents new capabilities and expertise. In a way. Let me explain.

Naturally, I started using the kiro skills when the HashiCorp Sr PM for Agentic Workflows and a dear friend Gautam pinged asking if I tried the HashiCorp agent skills. Here is how I got along with it on kiro-cli which is my daily driver.

HashiCorp's agent-skills repository takes a more targeted approach - providing specialized skills for Terraform development that can be integrated into various AI coding assistants.

What are HashiCorp Agent Skills?

HashiCorp Agent Skills is a collection of specialized knowledge modules designed to enhance AI agents' capabilities with HashiCorp products. Currently focused on Terraform, these skills can be integrated into most AI development tools.

The repository provides three main Terraform-focused plugins:

terraform-code-generation: Core HCL code generation following HashiCorp style conventions and Terraform test
terraform-module-generation: Module refactoring and Terraform Stacks.
terraform-provider-development: If you are a provider developer or contributor, you should be looking at this. If you remember my HashiConf talks on Making AI work for you where we discussed how kiro ( then Q) was assisting provider development teams with Terraform actions which was an unknown construct at that point.

So why should you care ?

Skills, originally introduced by Anthropic is a new open spec for giving agents new capabilities and expertise. We can do with a lot more openness and consistency across these different ways of interacting with Generative AI agents. Sure, it is a markdown and you have the flexibility to add whatever details you need. But how much is always the question. And should all of it get loaded into context when the agent is starting up? If you use Terraform as a daily driver for your infrastructure provisioning, the HashiCorp suite of skills is something you should absolutely be considering with how it makes that context available for your agentic interactions.

How do you use it ?

Most of the skills, rules, instructions, MCP server are supposed to make our questions without a lot of context build that up as you interact with the coding agent of your choice. Much of what I am saying here is available in the public documentation; hence adding only the relevant ones for kiro-cli.

Skills Installation

If you have npx on your machine, it is as simple as:

npx skills add hashicorp/agent-skills

Or you can install a specific skill. Keep in mind that the installation step above does allow you to pick and choose the skills you want to install.

# Install a specific skill
npx skills add hashicorp/agent-skills/terraform/code-generation/skills/terraform-style-guide

The skills terminal interface shows the source of the repository
from which you are installing these skills.

Select the ones you are interested in.

Now this is something I got confused about. I didn't have 28 agents ( or did I ?)

◇  Detected 28 agents
│
◆  Install to
│  ● All agents (Recommended) (Install to all 28 detected agents)
│  ○ Select specific agents
└

These are not the custom kiro-cli agents, but the coding agents you use like Kiro, Kilo Code, Goose, Claude Code and so on.

Note the directory it is referencing here. This is the .kiro directory in your user space on a Mac.

◆  Select agents to install skills to (space to toggle)
│  ◻ Antigravity
│  ◻ Claude Code
│  ◻ Clawdbot
│  ◻ Cline
...
│  ◻ Goose
│  ◻ Kilo Code
│  ◼ Kiro CLI (.kiro/skills)
│  ◻ MCPJam
│  ◻ Mux
...
│  ◻ Zencoder
│  ◻ Neovate

Scope: I would choose Global here rather than having to install it in every project under a .kiro directory. I used to do that for rules before.

Installation method:

◆  Installation method
│  ● Symlink (Recommended) (Single source of truth, easy updates)
│  ○ Copy to all agents
└

So what did we select until now?

◇  Installation Summary ───────────────────╮
│                                          │
│  ~/.agents/skills/terraform-style-guide  │
│    symlink → Kiro CLI                    │
│    overwrites: Kiro CLI                  │
│                                          │
│  ~/.agents/skills/terraform-test         │
│    symlink → Kiro CLI                    │
│    overwrites: Kiro CLI                  │
│                                          │
│  ~/.agents/skills/refactor-module        │
│    symlink → Kiro CLI                    │
│    overwrites: Kiro CLI                  │
│                                          │
│  ~/.agents/skills/terraform-stacks       │
│    symlink → Kiro CLI                    │
│    overwrites: Kiro CLI                  │
│                                          │
├──────────────────────────────────────────╯
│
◆  Proceed with installation?
│  ● Yes / ○ No

Proceed with installation.

│
◇  Installed 4 skills to 1 agent ────────────╮
│                                            │
│  ✓ ~/.agents/skills/terraform-style-guide  │
│    symlink → Kiro CLI                      │
│  ✓ ~/.agents/skills/terraform-test         │
│    symlink → Kiro CLI                      │
│  ✓ ~/.agents/skills/refactor-module        │
│    symlink → Kiro CLI                      │
│  ✓ ~/.agents/skills/terraform-stacks       │
│    symlink → Kiro CLI                      │
│                                            │
├────────────────────────────────────────────╯

│
└  Done!

Are we done? With the skills installation. But not completely.

Kiro skills resource

Reference: https://kiro.dev/docs/cli/custom-agents/configuration-reference/#skill-resources

kiro-cli (as of now) expects the skill to be referenced in a similar way as your rules or other markdowns. With a twist, the skill:// prefix makes kiro understand you are looking to load these dynamically when needed so that all of the text in all of the markdowns in there are not loaded always. If you are installing any skills for the first time, the npx install prompts you to install a find_skills skill too :)

In my Kiro CLI setup, I've configured a custom agent that combines whatever tools I use for Terraform development. kiro-cli lets you generate an agent allowing you to create the json file required for agent config in your .kiro/agents directory.

Here's how it's configured on my end.

{
  "name": "iac",
  "description": "You are a specialist in infrastructure as code, especially with AWS.",
  "prompt": "You are a specialist in infrastructure as code (IaC), with deep expertise in AWS services and best practices. You help users design, implement, and manage cloud infrastructure using code-based approaches like Terraform, CloudFormation, CDK, and other IaC tools. You provide guidance on AWS architecture patterns, security best practices, cost optimization, and automation strategies. You can assist with writing, reviewing, and troubleshooting infrastructure code, as well as helping users understand AWS services and how to effectively use them in their infrastructure deployments.",
  "mcpServers": {
    "awslabs.aws-documentation-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",
        "AWS_DOCUMENTATION_PARTITION": "aws"
      }
    },
    "terraform": {
      "command": "finch",
      "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  },
  "tools": ["*"],
  "toolAliases": {},
  "allowedTools": [],
  "resources": ["skill://~/.kiro/skills/**/SKILL.md"],
  "hooks": {},
  "toolsSettings": {},
  "useLegacyMcpJson": false,
  "model": null
}

Note the ["skill://~/.kiro/skills/**/SKILL.md"], it is installed in my .kiro directory under user. You could modify it based on your installation.

Skills in Action

With the custom agent called iac, I can either invoke the agent directly or switch to that agent.

kiro-cli --agent iac
✓ terraform loaded in 0.54 s
✓ Framelink MCP for Figma loaded in 1.49 s
⚠ 2 of 3 mcp servers initialized. Servers still loading:
- awslabs.aws-documentation-mcp-server
⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀     ⢀⣴⣶⣶⣦⡀⠀⠀⠀⢀⣴⣶⣦⣄⡀⠀⠀⢀⣴⣶⣶⣦⡀⠀⠀⢀⣴⣶⣶⣶⣶⣶⣶⣶⣶⣶⣦⣄⡀⠀⠀⠀⠀⠀⠀⢀⣠⣴⣶⣶⣶⣶⣶⣦⣄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀    ⢰⣿⠋⠁⠈⠙⣿⡆⠀⢀⣾⡿⠁⠀⠈⢻⡆⢰⣿⠋⠁⠈⠙⣿⡆⢰⣿⠋⠁⠀⠀⠀⠀⠀⠀⠀⠀⠈⠙⠻⣦⠀⠀⠀⠀⣴⡿⠟⠋⠁⠀⠀⠀⠈⠙⠻⢿⣦⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⣿⣇⣴⡿⠋⠀⠀⠀⢀⣼⠇⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢠⣤⣤⣤⣤⣄⠀⠀⠀⠀⣿⡆⠀⠀⣼⡟⠀⠀⠀⠀⣀⣀⣀⠀⠀⠀⠀⢻⣧⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⣿⡿⠋⠀⠀⠀⢀⣾⡿⠁⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢸⣿⠉⠉⠉⣿⡇⠀⠀⠀⣿⡇⠀⣼⡟⠀⠀⠀⣰⡿⠟⠛⠻⢿⣆⠀⠀⠀⢻⣧⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⠙⠁⠀⠀⢀⣼⡟⠁⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢸⣿⣶⣶⡶⠋⠀⠀⠀⠀⣿⠇⢰⣿⠀⠀⠀⢰⣿⠀⠀⠀⠀⠀⣿⡆⠀⠀⠀⣿⡆
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⠀⠀⠀⠀⠹⣷⡀⠀⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣼⠟⠀⢸⣿⠀⠀⠀⢸⣿⠀⠀⠀⠀⠀⣿⡇⠀⠀⠀⣿⡇
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⠀⣠⡀⠀⠀⠹⣷⡄⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣤⣄⠀⠀⠀⠀⠹⣿⡅⠀⠀⠸⣿⠀⠀⠀⠸⣿⠀⠀⠀⠀⠀⣿⠇⠀⠀⠀⣿⠇
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⣾⡟⣷⡀⠀⠀⠘⣿⣆⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣿⡟⣷⡀⠀⠀⠀⠘⣿⣆⠀⠀⢻⣧⠀⠀⠀⠹⣷⣦⣤⣤⣾⠏⠀⠀⠀⣼⡟
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⣿⡇⠹⣷⡀⠀⠀⠈⢻⡇⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣿⡇⠹⣷⡀⠀⠀⠀⠈⢻⡇⠀⠀⢻⣧⠀⠀⠀⠀⠉⠉⠉⠀⠀⠀⠀⣼⡟
⠀⠀⠀⠀⠀⠀⠀    ⠸⣿⣄⡀⢀⣠⣿⠇⠀⠙⣷⡀⠀⢀⣼⠇⠀⠸⣿⣄⡀⢀⣠⣿⠇⠸⣿⣄⡀⢀⣠⣿⠇⠀⠙⣷⡀⠀⠀⢀⣼⠇⠀⠀⠀⠻⣷⣦⣄⡀⠀⠀⠀⢀⣠⣴⣾⠟
⠀⠀⠀⠀⠀⠀⠀    ⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠀⠀⠈⠙⠻⠿⠿⠿⠿⠟⠋⠁

╭─────────────────────────────── Did you know? ────────────────────────────────╮
│                                                                              │
│     Enable workspace checkpoints to snapshot & restore changes. Just run     │
│                 kiro-cli settings chat.enableCheckpoint true                 │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

Model: claude-sonnet-4 (/model to change)

I haven't yet found the command which told me what skills are available on load time. But introspect works in those cases.

[iac] > introspect are there any skills available for me to use ?

Introspecting to get you the right information (using tool: introspect) - Completed in 0.1s

> Based on the context entries you provided, yes, you have several skills available:

Available Skills:

1. find-skills - Helps you discover and install additional agent skills when you ask questions like "how do I do X" or "find a skill for X"
2. refactor-module - Transforms monolithic Terraform configurations into reusable, maintainable modules following HashiCorp's best practices
3. terraform-stacks - Comprehensive guide for working with HashiCorp Terraform Stacks, including creating and managing .tfcomponent.hcl and .tfdeploy.hcl files
4. terraform-style-guide - Generates Terraform HCL code following HashiCorp's official style conventions and best practices
5. terraform-test - Comprehensive guide for writing and running Terraform tests, including creating .tftest.hcl files and test scenarios

These skills are stored in your ~/.kiro/skills/ directory and are designed to help with infrastructure as code tasks, particularly around Terraform development and best practices.

If you're looking for additional skills beyond these, you can use the find-skills skill to discover and install more capabilities based on your specific needs.
 ▸ Time: 12s

Usage

What do you do? You ask your question which you know will trigger the skill which can answer this. I haven't figured out how the default kiro_default agent can get these without creating another custom agent. Maybe that is not possible since we need the agent configuration to include skill resources right now.

Let's do this without calling our agent first time. For the eagle eyed and folks familiar with TF stacks, the tfstacks.hcl is being referenced which is still the old norm of creating stacks (Yes, I am on the TF MCP server 0.3.x version now)

How do I create a Terraform stacks config for a VPC config from the private registry manu.example.com ?

> I'll help you create a Terraform stacks configuration for a VPC from your private registry. Let me first get the latest Terraform provider version and then show you the minimal configuration.
Running tool get_latest_provider_version with the param (from mcp server: terraform)
 ⋮  {
 ⋮    "namespace": "hashicorp",
 ⋮    "name": "aws"
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y

 - Completed in 3.778s

> Here's the minimal Terraform stacks configuration for a VPC from your private registry:

deployments.tfdeploy.hcl
hcl
deployment "vpc" {
  inputs = {
    regions = ["us-east-1"]
  }
}

vpc.tfstack.hcl
hcl
required_providers {
  aws = {
    source  = "hashicorp/aws"
    version = "~> 6.28.0"
  }
}

variable "regions" {
  type = set(string)
}

component "vpc" {
  source = "manu.example.com/your-namespace/vpc-module"

  for_each = var.regions

Invoke the agent kiro-cli --agent iac or /agent swap iac from within the CLI.

How do I create a Terraform stacks config for a VPC config from the private registry manu.example.com ?

> I'll help you create a Terraform Stacks configuration for a VPC from your private registry. Let me first check the terraform-stacks skill for the specific syntax.
Reading file: /Users/abc123/.kiro/skills/terraform-stacks/SKILL.md, all lines (using tool: read)
✓ Successfully read 14349 bytes from /Users/abc123/.kiro/skills/terraform-stacks/SKILL.md
- Completed in 0.0s

> Based on the Terraform Stacks documentation, here's how to create a Stack configuration for a VPC from your private registry manu.example.com:

Component Configuration (components.tfcomponent.hcl):

hcl
component "vpc" {
 source  = "manu.example.com/vpc/aws"
 version = "1.0.0"

 inputs = {
   cidr_block = var.vpc_cidr
   region     = var.aws_region
 }

 providers = {
   aws = provider.aws.this
 }
}


Provider Configuration (providers.tfcomponent.hcl):

hcl
required_providers {
 aws = {
   source  = "hashicorp/aws"
   version = "~> 5.7.0"
 }
}

provider "aws" "this" {
 config {
   region = var.aws_region
   assume_role_with_web_identity {
     role_arn           = var.role_arn
     web_identity_token = var.identity_token
   }
 }
}


Variables (variables.tfcomponent.hcl):

hcl
variable "vpc_cidr" {
 type = string
}

...


Deployment (deployments.tfdeploy.hcl):

hcl
identity_token "aws" {
 audience = ["aws.workload.identity"]
}

deployment "production" {
 inputs = {
   vpc_cidr       = "10.0.0.0/16"
   aws_region     = "us-west-1"
   role_arn       = "arn:aws:iam::123456789012:role/hcp-terraform-stacks"
   identity_token = identity_token.aws.jwt
 }
}


Key points for private registry sources:
- Use the full registry hostname in the source: manu.example.com/vpc/aws
- Include a version constraint
- Ensure you're authenticated to the private registry before running terraform stacks providers-lock
▸ Time: 19s

Bloopers

Without the agent invoked.

> Do I have any skills available ?

> Based on my review, you do not have any specific skills in the documents.

Looking Forward

With only Terraform in the current skill list, take a look at the branches and you will see some of the groundwork done before and how it evolved into what is available as version 0.0.1.

I do have an open question to the skills developers or contributors. How do we make sure that the responses we get for a set of questions after making changes to the existing skills are not worsened after those changes ? How can we automatically validate these are goind in the wrong direction

The future of infrastructure development is looking increasingly collaborative - with AI agents that understand not just syntax, but the deeper patterns and practices that make infrastructure reliable, secure, and maintainable. Yes, I had the kiro write the above line ;)

Other notable skills for your Terraform/OpenTofu exploits:

Anton's Terraform skills

Stategraph: Deploy on AWS with Terraform Part 1

quixoticmonk — Tue, 03 Feb 2026 03:41:40 +0000

Crossposted from https://manuchandrasekhar.com/posts/2026/02-01-stategraph-aws-deployment/

If you're following the Infrastructure as Code space, Josh Pollara is a name you've likely encountered. While I haven't personally tried terrateam, I've been following what he and his co-founders have been building. One of the most common questions I get from customers using Terraform is around state management. Most AWS deployments default to S3 as a backend (with DynamoDB for locking in pre-1.10 Terraform versions). The idea of exploring another mechanism in the state management space intrigued me, especially with promises around faster plans through their upcoming Velocity feature. The First Principles page is worth reading, and this stood out:

Infrastructure is a graph. Store it as a graph.

I started with their backend implementation using the Docker Compose quickstart. I'll save the nuances of the transactional nature of state changes and metadata tracking for a future post.

Dev setup with Docker(Finch) compose

The Docker Compose setup was straightforward for local development. Initially, I struggled with configuring this as a Terraform state backend. Stategraph implements the HTTP backend protocol, requiring an endpoint and authentication mechanism. My confusion was primarily because I skipped the Creating an API key section in the quickstart guide.

The documentation could benefit from emphasizing the API key requirement earlier in the flow for users who might skip ahead (like me).

terraform {
  backend "http" {
    address = "http://myrest.api.com/foo"
    username = "session"
    password = "<your-api-key>"
  }
}

Note that the user settings does give you an option to create a service account for CICD pipelines.

For security, avoid hardcoding credentials in your backend configuration. Use environment variables instead. The environment variables TF_HTTP_USERNAME and TF_HTTP_PASSWORD are your best bet here.

terraform {
  backend "http" {
    address = "http://localhost:8080/api/v1/states/backend/<group-id>"
  }
}

Understanding the `group-id`

The group-id is a unique identifier that Stategraph assigns to organize and locate your Terraform state files. Think of it as a folder ID or address where your infrastructure state is stored. In HCP Terraform terms, it's similar to a workspace or project identifier. This is the first time I noticed the stategraph CLI.

For MacOs users, the installation is as simple as:

brew tap stategraph/stategraph
brew install stategraph

Generate the group-id using these commands (detailed in Create a state):

# Get your tenant ID

stategraph user tenants list

# Create a new state (returns group_id)
stategraph states create --tenant <tenant_id> --name "stategraph-demo"

Response example:

{
  "id": "...",
  "name": "stategraph-demo", 
  "group_id": "550e8434-t59b-56d4-a716-329055440073",
  "workspace": "default"
}

Initial Web Interface Impressions

The Stategraph web interface impressed me with its clean design. Even with just two state files in my initial setup, the interface clearly prioritized giving visibility into individual resources within state files and across multiple states. The screenshots below show the different views available:

State Overview:

Control Plan Insights:

State Metadata:

Deployment configuration using Terraform

The local Docker Compose setup was just the beginning. I wanted to deploy Stategraph into a production-ready environment using ECS with an external PostgreSQL database on RDS. After several iterations and troubleshooting various configuration issues, I have a working deployment using Stategraph server version 0.1.16.

The complete Terraform configuration I used is available at: Stategraph ECS Infrastructure

Architecture Overview

The infrastructure configuration creates a Stategraph environment with:

ECS EC2: Runs the Stategraph container (ghcr.io/stategraph/stategraph-server)
CloudFront: CDN for HTTPS termination and global distribution
Application Load Balancer: Routes traffic to ECS tasks
RDS PostgreSQL 17: Database for state storage and transaction history
VPC: Isolated network with public/private subnets
Secrets Manager: Secure storage for database password and OAuth secrets

Prerequisites

Before deploying, you'll need:

AWS credentials configured (via environment variables, IAM roles, or AWS profiles)
Terraform >= 1.0
Google OAuth Application - Set up at Google Cloud Console
- Create OAuth 2.0 Client ID for web application
- Configure authorized redirect URIs

Key Configuration

Required Variables

variable "google_oauth_client_id" {
  description = "Google OAuth Client ID"
  type        = string
}

variable "google_oauth_client_secret" {
  description = "Google OAuth Client Secret"
  type        = string
  sensitive   = true
}

Container Configuration

Stategraph runs on port 8180 internally with nginx as a reverse proxy on port 8080. Key environment variables include:

environment = [
  {
    name  = "STATEGRAPH_UI_BASE"
    value = local.stategraph_url
  },
  {
    name  = "STATEGRAPH_PORT" 
    value = "8180"
  },
  {
    name  = "STATEGRAPH_OAUTH_TYPE"
    value = "oidc"
  },
  {
    name  = "STATEGRAPH_OAUTH_OIDC_ISSUER_URL"
    value = "https://accounts.google.com"
  }
]

secrets = [
  {
    name      = "DB_PASS"
    valueFrom = aws_secretsmanager_secret.db_password.arn
  },
  {
    name      = "STATEGRAPH_OAUTH_CLIENT_SECRET"
    valueFrom = aws_secretsmanager_secret.google_client_secret.arn
  }
]

Note: I used oidc as the OAuth type instead of google due to configuration issues with the latter. I have been lazy here not to go back and check what I missed.

Deployment

Initialize and Deploy:

Follow the standard Terraform workflow:

   terraform init
   terraform plan
   terraform apply

Configure OAuth:

After deployment, configure your Google OAuth application with the redirect URI:

   terraform output google_oauth_redirect_uri

The callback URL will be in the format: https://abc.cloudfront.net/oauth2/oidc/callback

Access Stategraph:

Retrieve the Stategraph URL from Terraform outputs:

   # Get the HTTPS URL (via CloudFront)
   terraform output stategraph_url

Stategraph UI

Once deployed, the initial setup flow includes several steps.

License Prompt
Enter Existing License
User Information

Google Authentication (Note: I misconfigured STATEGRAPH_OAUTH_DISPLAY_NAME - it should be Google rather than the full message shown)

Main Web Interface

State Migration

Obviously the next thing to do was migrate the state to Stategraph itself. For the Docker compose local development setup, I was copying and pasting without reading half of it. Now came the actual setup where I noticed the additional variables I need to keep in mind. You can generate an API KEY from the user settings and set these environment vars as you would need it for stategraph CLI command.

export STATEGRAPH_API_BASE="<stategragh_url>"
export STATEGRAPH_API_KEY="<api_key>"

Once done, retrieve the tenant id

stategraph user tenants list

And create the state container. This is where I think they should have a glossary of terms in reference to stategraph. We as a community have made some words difficult to use in many other contexts.

stategraph states create --tenant <tenant_id> --name "stategraph-ecs"
{
 "created_at": "2026-02-02T05:34:21Z",
 "group_id": "<group_id>",
 "id": "...",
 "name": "stategraph-ecs",
 "workspace": "default"
}

Update the Terraform block to use the same backend. I did backup the state before doing it though the configuration didn't have a lot of components and I could have manually cleaned them up if I messed it up.

Run terraform init

Initializing the backend...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "http" backend. No existing state was found in the newly
  configured "http" backend. Do you want to copy this state to the new "http"
  backend? Enter "yes" to copy and "no" to start with an empty state.

  Enter a value:

Enter yes. Here goes nothing..

Successfully configured the backend "http"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing provider plugins...
- Reusing previous version of hashicorp/random from the dependency lock file
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using previously-installed hashicorp/aws v6.28.0
- Using previously-installed hashicorp/random v3.8.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Run a plan to check everything is ok.

random_password.db_password[0]: Refreshing state... [id=none]
random_id.secret_suffix: Refreshing state... [id=vKBxqA]
data.aws_availability_zones.available: Reading...
aws_secretsmanager_secret.db_password: Refreshing state... [id=arn:aws:secretsmanager:us-east-1:############:secret:stategraph-db-password-bca071a8-MgkbzS]
aws_ecs_cluster.main: Refreshing state... [id=arn:aws:ecs:us-east-1:############:cluster/stategraph]
data.aws_ami.ecs_optimized: Reading...
....
aws_cloudfront_distribution.stategraph: Refreshing state... [id=E2CDRVGI3JY6BT]
aws_db_instance.postgres: Refreshing state... [id=db-QRFNQQCUDBMW4HXCODVUHWKTXE]
aws_ecs_task_definition.stategraph: Refreshing state... [id=stategraph]
aws_ecs_service.stategraph: Refreshing state... [id=arn:aws:ecs:us-east-1:############:service/stategraph/stategraph]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences,
so no changes are needed.

The Resource count on the pane looks off by 2.

If you dig into the inspect state , you have the 48 resources listed.

State Overview

I still need to dive deep into what some of these data points mean, but they are there for you if you want them. The view is scoped to the state you were looking at; in my case the stategraph deployment itself. The page does give you quick jump off points to Search and Inventory.

The dependency blast radius and Top resource types !!

Now what are Orphaned candidates ? :thinkingface:

Inventory

If you select one of the resource types from state overview, it takes you to the inventory of currently managed resources. This is sweet !

Querying Resources

The interface already gives you some sample queries and it worked out well with my stategraph infrastructure here. I am not going to draw parallels just yet, the query interface along with the examples were a nice a touch.

For your recurring queries :

I did feel like a kid during Christmas with a candy box all for himself ;)

Monitoring and Troubleshooting

Monitor your deployment through:

CloudWatch Logs: /ecs/stategraph log group
ECS Service Events: Check for deployment issues
Target Group Health: Monitor ALB target group status

Common issues to watch for:

Database connectivity (security groups, RDS availability)
OAuth configuration (redirect URIs, client secrets)
Load balancer health checks

Deployment Challenges

I encountered couple of challenges during my ECS Terraform route:

Version Compatibility: Stategraph iterates releases frequently (almost daily). I struggled to get ALB health checks passing on versions before 0.1.15 due to ECS task failures during database migration tasks, even though database connectivity was confirmed.
Compute Choice: I initially started with Fargate but switched to EC2 instances for some troubleshooting.

Conclusion

Stategraph brings a fresh perspective to infrastructure state management that complement the existing ecosystem well. The visual interface and query capabilities will offer valuable insights that practitioners will appreciate, especially in organizations with a huge number of workloads targeting multiple platforms.

If you are looking to get started , the Terraform configuration here should give you a fully stable infrastructure once you have a Google OAuth client ID. Or swap out the authentication mechanism based on your preference.

Here are the key resources I referenced during configuration:

Stategraph Documentation
Stategraph OAuth Setup
Stategraph Environment Variables - Comprehensive list of configuration options (I appreciate having all environment variables documented in one place!)
Google Cloud Console - for OAuth setup

There are so many components to this along with the orchestration side using Terrateam which I am excited to try. More of it in the next set of posts.

Terraform Module Guard: Multi-Engine Policy Validation for Module Sources

quixoticmonk — Thu, 13 Nov 2025 04:11:47 +0000

It's November already !!! Are you in the naughty list or nice list ?

One of my wishlist items for HCP Terraform or Terraform enterprise has always been the ability to restrict what modules or providers can be used based on some list. Yes, if you have used GitHub actions the desire to have something similar comes from that interface of allowed actions. While that's a wishlist item, I have had clients who had asked for mechanisms to do this using their existing policy as code frameworks. And when I say Policy as Code frameworks or tools, I mean some of these:

checkov
opa
sentinel
Or a simple bash script

Whether you're using HCP Terraform with its enterprise features or the community edition with open-source tooling, you need consistent ways to validate module origins. This challenge led me to create terraform-module-guard, a collection of policies that validate Terraform module sources across multiple policy engines. The reason it exists is for purely selfish reasons as I often find myself trying to find that last time I used it which is in my filesystem somewhere.

The Problem

Let's dive into the problem statement further.Terraform modules can be sourced from various locations:

Public registries (registry.terraform.io)
Private registries
Git repositories
Local file paths or even HTTP URLs if I am not wrong

Without proper controls, teams might inadvertently use modules from untrusted sources, potentially introducing security vulnerabilities or compliance violations. Different organizations use different policy engines based on their Terraform deployment model:

HCP Terraform users typically leverage Sentinel or OPA for policy enforcement
Community edition users often rely on open-source tools like OPA, Checkov, or pre-commit hooks

My intention

My intention here is purely as a frame of reference of what can be done to solve this problem across some common PaC frameworks.

GitHub repo : terraform-module-guard provides identical policy logic implemented across different engines.

Let's start with the configuration elements. In the repo ,allowed-sources.yaml represents an example of what is allowed when considering the sources of the modules. I am using the inline versions of these for OPA and Sentinel. There might be ways to load the file into the evaluations. I might look into that later.

allowed_sources:
  registry:
    - "cloudposse/*"
    - "terraform-aws-modules/*"
    - "aws-ia/*"
  git:
    - "github.com/cloudposse/*"
    - "github.com/terraform-aws-modules/*"
    - "github.com/aws-ia/*"

This is merely an example of the keys and values I wanted to consider. You may have variations of this which you can absolutely add and update the policies with.

Data Set

The repository includes test files that demonstrate the policy validation across all engines. These examples were tested against:

Checkov: v3.2.458
OPA: v1.9.0

✅ Good Module Sources

Let's define some passing examples. examples/pass/pass.tf:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
}

module "label" {
  source  = "aws-ia/label/aws"
  version = "~> 0.0.5"
}

module "cloudposse_module" {
  source  = "cloudposse/label/null"
  version = "~> 0.25.0"
}

module "git_terraform_aws" {
  source = "git::ssh://git@github.com/terraform-aws-modules/terraform-aws-s3-bucket.git?ref=v4.0.0"
}

module "git_cloudposse" {
  source = "git::ssh://git@github.com/cloudposse/terraform-null-label.git?ref=0.25.0"
}

❌ Bad Module Sources

Similarly some failing examples. Yes, I do have a passing source mixed in to validate that it does get flagged as passed. (Blame the QA in me) These should be present in the repo as examples/fail/fail.tf:

module "quixoticmonk_glue_1" {
  source = "quixoticmonk/glue/aws"
  version = "~> 0.0.3"
}

module "quixoticmonk_glue_2" {
  source = "quixoticmonk/glue/aws"
  version = "~> 0.0.3"
}

module "docker_secret" {
  source  = "bendrucker/docker-secret/kubernetes"
  version = "1.0.0"

  name      = "my-docker-secret"
  namespace = "default"
  registries = {
    "docker.io" = {
      username = "user"
      password = "pass"
      email    = "user@example.com"
    }
  }
}

module "git_quixoticmonk_s3" {
  source = "git::ssh://git@github.com/quixoticmonk/terraform-aws-s3.git?ref=main"
}

# This should PASS - allowed source
module "allowed_module" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
}

1. Sentinel (HCP Terraform)

For teams using HCP Terraform, you can use the Sentinel policy referenced here. Keep in mind that this uses a allowed_$$_sources input inside the policy itself. There may be a better way to define the list of sources and my sentinel kungfu is not that strong , yet. I should probably ask the sentinel team if there is a way to manage the sources.

You can either add this policy as part of a policyset via VCS connection or create a policy inline in the HCP Terraform UI and enforce it on a workspace.

For inline policies:

Workspaces -> Policies -> Create a new policy -> Select Sentinel and add the policy in the policy code (Sentinel) section

Create a Terraform workspace which has some of these modules being called in the configuration. Post plan, you should be able to see the details on Sentinel which should look something like below :

This policy validates module sources during plan and apply operations, blocking runs that use unauthorized modules.

2. Checkov

If you have used Terraform and built a CICD pipeline for provisioning infrastructure using Terraform, you would have heard about Checkov which has become a standard for static analysis of the Terraform configuration. I do think it can get noisy without the severity classification. But I personally love the custom checks option which I keep using across the board for many situations where I need some new policies specific to my customer or something unique for my situation.

# Run specific module source validation
checkov -f main.tf --external-checks-dir checkov/ --check CKV_TF_MODULE_SOURCE

For examples/pass/pass.tf:

Passed checks: 5, Failed checks: 0, Skipped checks: 0

Check: CKV_TF_MODULE_SOURCE: "Ensure module source is from allowed list"
    PASSED for resource: vpc
    PASSED for resource: label
    PASSED for resource: cloudposse_module
    PASSED for resource: git_terraform_aws
    PASSED for resource: git_cloudposse

Running against examples/fail/fail.tf. Yes, I did sneak in a passing source to verify if this actually does what I am expecting it to do.

Passed checks: 1, Failed checks: 4, Skipped checks: 0

Check: CKV_TF_MODULE_SOURCE: "Ensure module source is from allowed list"
    PASSED for resource: allowed_module

    FAILED for resource: quixoticmonk_glue_1
    File: /fail.tf:4-7
        4 | module "quixoticmonk_glue_1" {
        5 |   source = "quixoticmonk/glue/aws"
        6 |   version = "~> 0.0.3"
        7 | }

    FAILED for resource: quixoticmonk_glue_2
    File: /fail.tf:9-12
        9  | module "quixoticmonk_glue_2" {
        10 |   source = "quixoticmonk/glue/aws"
        11 |   version = "~> 0.0.3"
        12 | }

    FAILED for resource: docker_secret
    File: /fail.tf:14-27
        14 | module "docker_secret" {
        15 |   source  = "bendrucker/docker-secret/kubernetes"
        16 |   version = "1.0.0"

    FAILED for resource: git_quixoticmonk_s3
    File: /fail.tf:30-32
        30 | module "git_quixoticmonk_s3" {
        31 |   source = "git::ssh://git@github.com/quixoticmonk/terraform-aws-s3.git?ref=main"
        32 | }

3. Open Policy Agent (OPA)

If you prefer OPA , you could use the example policy from the opa directory against a Terraform plan json. The steps would look like below:

# Generate Terraform plan in JSON format
terraform init
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

# Execute policy against Terraform plan JSON
opa exec --decision terraform/module_sources/deny --bundle opa/ tfplan.json

# Fail on violations (recommended for CI/CD)
opa exec --decision terraform/module_sources/deny --bundle opa/ --fail-non-empty tfplan.json

And what do we see...

For the pass scenarios present in examples/pass/opa/input.json

{
  "result": [
    {
      "path": "examples/pass/opa/input.json",
      "result": [] # No violations.
    }
  ]
}
Exit code: 0

Running against examples/fail/opa/input.json with --fail-non-empty:

{
  "result": [
    {
      "path": "examples/fail/opa/input.json",
      "result": [
        "Module 'docker_secret' uses disallowed source: bendrucker/docker-secret/kubernetes",
        "Module 'git_quixoticmonk_s3' uses disallowed source: git::ssh://git@github.com/quixoticmonk/terraform-aws-s3.git?ref=main",
        "Module 'quixoticmonk_glue_1' uses disallowed source: quixoticmonk/glue/aws",
        "Module 'quixoticmonk_glue_2' uses disallowed source: quixoticmonk/glue/aws"
      ]
    }
  ]
}
Exit code: 1

The exit code on opa exec is really helpful when you are running this in a CICD pipeline if you are writing tests to validate your policies as well.

4. Pre-commit Hooks

You could technically include any of the above in the pre-commit step as a hook. I decided to create a bash script which effectively does some string manipulation to verify if the source is allowed. I had Amazon Q whip up this quick script to verify if the module source is in the allowed list or not.

repos:
  - repo: local
    hooks:
      - id: validate-module-sources
        name: Validate module sources
        entry: ./pre-commit/validate-module-sources.sh
        language: script
        files: \.tf$

Test Results:

Running against examples/pass/pass.tf:

✅ No violations found - all module sources are allowed

Running against examples/fail/fail.tf:

ERROR: Disallowed module source in examples/fail/fail.tf: quixoticmonk/glue/aws
ERROR: Disallowed module source in examples/fail/fail.tf: quixoticmonk/glue/aws
ERROR: Disallowed module source in examples/fail/fail.tf: bendrucker/docker-secret/kubernetes
ERROR: Disallowed module source in examples/fail/fail.tf: git::ssh://git@github.com/quixoticmonk/terraform-aws-s3.git?ref=main

How can you get started ?

The repository includes examples to test and play around with:

examples/pass/ - Valid module sources that should pass validation
examples/fail/ - Invalid sources that should trigger policy violations

Whether you're using HCP Terraform's enterprise features or building with community tools, you should have the ability to implement consistent module source validation across your entire Terraform ecosystem.

Terratags v0.6.0: Remote Configuration and Google Cloud Support

quixoticmonk — Sat, 18 Oct 2025 14:35:09 +0000

Terratags continues to evolve, and v0.6.0 brings two significant features: remote configuration support and Google Cloud Provider support. These additions make Terratags extend its reach beyond AWS and Azure to cover the major cloud providers.

What's New in v0.6.0

Remote Configuration Support

One of the requested features was the ability to centralize configuration management. This allows team to avoid duplicating tag requirements across multiple repositories and maintain consistency across their infrastructure.

v0.6.0 introduces remote configuration support, allowing you to load your Terratags configuration from:

HTTP/HTTPS URLs

terratags -config https://example.com/configs/terratags.yaml -dir ./infra

Git Repositories

# HTTPS with branch/tag specification
terratags -config https://github.com/org/configs.git//terratags.yaml?ref=main -dir ./infra

# SSH support for private repositories
terratags -config git@github.com:org/configs.git//path/to/config.yaml?ref=v1.0.0 -dir ./infra

This is particularly powerful for organizations that want to:

Version their tagging policies alongside their infrastructure code
Use different configurations for different environments (dev, staging, prod)
Maintain audit trails of configuration changes
Leverage Git's branching and tagging for configuration management

Version Pinning and Environment-Specific Configs

The Git integration supports referencing specific branches, tags, or commits:

# Production uses stable tagged version
terratags -config https://github.com/org/configs.git//prod-config.yaml?ref=v2.1.0

# Development uses latest from main branch
terratags -config https://github.com/org/configs.git//dev-config.yaml?ref=main

# Specific commit for reproducible builds
terratags -config https://github.com/org/configs.git//config.yaml?ref=abc123def

Google Cloud Provider Support

The second major addition is full support for Google Cloud Platform. GCP uses 'labels' instead of 'tags' for resource metadata.

Basic GCP Label Validation

resource "google_compute_instance" "web_server" {
  name         = "web-server-01"
  machine_type = "e2-medium"
  zone         = "us-central1-a"

  labels = {
    environment = "production"
    project     = "web-app"
    owner       = "devops@example.com"
    name        = "web-server-01"
  }
}

Google Provider default_labels Support

Just like AWS and Azapi provider's default_tags , Google provider's default_labels are fully supported:

provider "google" {
  project = "my-project-id"
  region  = "us-central1"

  default_labels = {
    environment = "production"
    owner       = "team-platform"
    managed_by  = "terraform"
  }
}

resource "google_storage_bucket" "data_bucket" {
  name     = "company-data-bucket"
  location = "US"

  # Only need to specify labels not covered by default_labels
  labels = {
    name    = "data-bucket"
    project = "analytics"
  }
}

In this example, the bucket will have all required labels: name and project from the resource-level labels, and environment, owner, and managed_by from the provider's default_labels.

Multi-Cloud Tagging Consistency

With v0.6.0, Terratags now supports all three major cloud providers with their respective tagging mechanisms:

AWS: tags with default_tags support
Azure: tags with azapi default_tags support
Google Cloud: labels with default_labels support

This means you can maintain consistent tagging policies across your entire multi-cloud infrastructure using a single tool and configuration format.

Validation in CI/CD

# GitHub Actions example
- name: Validate AWS Resources
  run: terratags -config https://example.com/aws-tags.yaml -dir ./aws-infra

- name: Validate GCP Resources  
  run: terratags -config https://example.com/gcp-labels.yaml -dir ./gcp-infra

- name: Validate Azure Resources
  run: terratags -config https://example.com/azure-tags.yaml -dir ./azure-infra

Pattern Validation

The advanced pattern validation introduced in earlier versions works consistently across all providers:

# Works for AWS tags, Azure tags, and GCP labels
required_tags:
  environment:
    pattern: "^(dev|test|staging|prod)$"

  owner:
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"

  cost_center:
    pattern: "^CC-[0-9]{4}$"

Getting Started with v0.6.0

Installation

# Using Homebrew (recommended)
brew install terratags/tap/terratags

# Or download from GitHub releases
# https://github.com/terratags/terratags/releases/tag/v0.6.0

Quick Start with Remote Config

Set up a remote configuration:

# https://example.com/terratags.yaml
required_tags:
  environment:
    pattern: "^(dev|test|staging|prod)$"
  owner:
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
  project: {}
  name: {}

Run validation:

terratags -config https://example.com/terratags.yaml -dir ./infra -report report.html

Set up pre-commit hooks:

repos:
  - repo: https://github.com/terratags/terratags
    rev: v0.6.0
    hooks:
      - id: terratags
        args: [--config=https://example.com/terratags.yaml]

Looking Ahead

There are a few items in the report generation which I want to look to implement, without breaking existing structure and including all the metadata.

Resources

GitHub Repository: https://github.com/terratags/terratags
Documentation: https://terratags.github.io/terratags/
Remote Config Examples: https://terratags.github.io/terratags/examples/remote_config/
Release Notes: https://github.com/terratags/terratags/releases/tag/v0.6.0

If you're using Terratags and have been waiting for centralized configuration management, v0.6.0 is definitely worth the upgrade. As always, I'd love to hear about your experience and any feedback you have!

Exploring terraform provider capabilities with schema analysis

quixoticmonk — Thu, 09 Oct 2025 17:56:44 +0000

Terraform has become the de facto name when it comes to tools which help you model infrastructure in a declarative language, the idea of which we call as Infrastructure as Code. At a very high level, Terraform is a Go binary which knows how to do some things well. And providers are that much needed context which terraform needs to work with a platform. The platform can be a cloud service provider or an artifactory platform like jFrog and so on. Most developers only scratch the surface of what Terraform providers offer. While everyone knows about basic resources and datasources available within a provider, anything beyond that is still not easily discovered ( unless the documentation surfaces them up well).

You're deploying infrastructure with Terraform and need to invalidate a CloudFront cache after your S3 bucket updates (Like with this blog). You've heard Terraform has a new concept called "actions" for this, but how do you discover what's available? In this post, we'll explore how to use the terraform providers subcommand to identify some of the core capabilities which might exist with the provider you normally interact with.

Note: With the availability of Terraform MCP servers, these might be easier than how it was earlier.

Pre-requisites

The sections below lists commands which can provide you more details around the core capabilities( for lack of better terms) that exist with aws provider. You may use the provider that you use in your daily life.

jq for maneuvering around the json schema file
terraform binary :1.14.0-beta versions to gather some of the attributes
The latest version of your provider.

providers schema command

If you have ever run the terraform providers command, you will see the list of options available; out of which we are going to dive into the schema subcommand. Terraform's providers schema command exposes every capability your provider supports in a structured JSON format.

❯ terraform providers --help

Options:

  -test-directory=path  Set the Terraform test directory, defaults to "tests".

Subcommands:
    lock      Write out dependency locks for the configured providers
    mirror    Save local copies of all required provider plugins
    schema    Show schemas for the providers used in the configuration

Warning: If you run the command terraform provider schema -json on your terminal expect a ball of text to fill your terminal screen.

Quick Setup

Let's start with a minimal Terraform configuration to explore the AWS & AWSCC provider:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
    }
    awscc = {
      source = "hashicorp/awscc"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

provider "awscc" {
  region = "us-west-2"
}

After running terraform init, we can extract the complete provider schema using the below command. I am going to pipe the results out to a json file so that I can perform my analysis on the available file.

terraform init
terraform providers schema -json > aws_schema.json

Provider Capability Categories

First, let's see what capability types are available. Over the course of time, Terraform introduced many schema capabilities/types that providers adopted. To get the list of capabilities, all we need to do is find the keys inside provider_schemas.

At the time of writing this, the AWS provider supports 8 distinct capability types:

❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"] | keys' aws_schema.json

[
  "action_schemas",
  "data_source_schemas",
  "ephemeral_resource_schemas",
  "functions",
  "list_resource_schemas",
  "provider",
  "resource_identity_schemas",
  "resource_schemas"
]

What about the AWSCC provider ? It supports 5 at the moment.

❯ jq '.provider_schemas["registry.terraform.io/hashicorp/awscc"] | keys' aws_schema.json
[
  "data_source_schemas",
  "list_resource_schemas",
  "provider",
  "resource_identity_schemas",
  "resource_schemas"
]

Let's get some numbers

Now let's find how many resources exist in each of the provider.


❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].resource_schemas | keys | length' aws_schema.json
1544


❯ jq '.provider_schemas["registry.terraform.io/hashicorp/awscc"].resource_schemas | keys | length' aws_schema.json
1214

There are 1544 & 1214 resources in the AWS and AWSCC providers respectively at this point. The key thing to note here is that you can replace the capability type you want to review and gather the specific detaills of those types.


# Count data sources  
❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].data_source_schemas | keys | length' aws_schema.json

# Count functions
❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].functions | keys | length' aws_schema.json

# Count action schemas
❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].action_schemas | keys | length' aws_schema.json

# Count ephemeral resources
❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].ephemeral_resource_schemas | keys | length' aws_schema.json

# Count resource identity schemas
❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].resource_identity_schemas | keys | length' aws_schema.json

# Count list resources
❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].list_resource_schemas | keys | length' aws_schema.json

For ease of associating them, I have just mapped them to the capability type. You can probably do this with jq as well.

[
  "action_schemas",           // 8 actions
  "data_source_schemas",      // 622 data sources  
  "ephemeral_resource_schemas", // 7 ephemeral resources
  "functions",                // 3 functions
  "list_resource_schemas",    // 4 list resources
  "provider",                 // Provider configuration
  "resource_identity_schemas", // 212 identity schemas
  "resource_schemas"          // 1,544 resources
]

Dive deep into a type

So all these commands are great at presenting you the details in a provider schema. Why do I need it again ? HashiConf '25 introduced two core capabilities with provider support.

Terraform search : Query a list of resources of certain type(s) and provide a means to import them to your state file , if you so desire.
Terraform actions : A HCL native way of managing pre/post- operations on resources during the lifecycle management of resources. In short, the idea is to give an alternative to some of the bespoke scripts and local-exec provisioners running in the modules you know of. This blog itself uses a cache invalidation step with CloudFront once the deployment is complete.

One of my biggest pain points with the provider documentation currently is with how these types are listed. Or rather not listed. AWS provider groups capability types by the resource types like S3 bucket and so there is no easy way to identify the number of actions or list resources supported across the provider. Once I know that a resource type exists, I can search for that one and identify the attributes to use.

Can we get that information from the providers schema? Yes, you can. Let's start with the action schema.

Question: What action resources are supported in AWS provider ?

❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].action_schemas | keys' aws_schema.json

[
  "aws_cloudfront_create_invalidation",
  "aws_codebuild_start_build", 
  "aws_ec2_stop_instance",
  "aws_events_put_events",
  "aws_lambda_invoke",
  "aws_ses_send_email",
  "aws_sfn_start_execution",
  "aws_sns_publish"
]

Question: What about list resources ?

❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].list_resource_schemas | keys' aws_schema.json
[
  "aws_batch_job_queue",
  "aws_cloudwatch_log_group",
  "aws_iam_role",
  "aws_instance"
]

So what if I want to know the supported actions or list resources across other providers ? You can easily change the provider configuration in the providers.tf file I had above to include your provider details and run the same commands. OR, you can take a look at my GitHub repo here. Yes, it is named provider actions before I realized I could do this for all types ( actions, list, functions, ephemeral and so on)

To drive the point home:

Discover available provider functions:

# List all functions
❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].functions | keys' aws_schema.json

[
  "arn_build",      // Construct ARNs programmatically
  "arn_parse",      // Parse ARN components
  "trim_iam_role_path"  // Clean IAM role paths
]

Ephemeral Resources: Temporary Data

Discover ephemeral resources:

# List all ephemeral resources
❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].ephemeral_resource_schemas | keys' aws_schema.json


[
  "aws_cognito_identity_openid_token_for_developer_identity",
  "aws_eks_cluster_auth",
  "aws_kms_secrets", 
  "aws_lambda_invocation",
  "aws_secretsmanager_random_password",
  "aws_secretsmanager_secret_version",
  "aws_ssm_parameter"
]

Review attributes in a specific resource

It doesn't stop there. You have the ability to dive deeper into a resource in a provider and understand the list of attributes expected and if needed pull the required attributes alone. How will you do it ?

Let's check how many attributes are marked as required on aws_s3_bucket resource.


❯ jq '.provider_schemas["registry.terraform.io/hashicorp/aws"].resource_schemas.aws_s3_bucket.block.attributes | to_entries | map(select(.value.required == true)) | map(.key)' aws_schema.json

[]. # None

Conclusion

The next time you look at a provider and want to identify what it offers, I hope you will give this a try.

Note: The Terraform MCP server is adding the actions and list resources discovery into the latest iteration from the looks of it. Hopefully that makes this simpler if you use a Gen AI agent in your work.

To explore your provider schemas; replace the with yours once the provider block is updated.

# Initialize your Terraform configuration
terraform init

# Extract complete schema
terraform providers schema -json ❯ provider_schema.json

# Explore !!!
jq '.provider_schemas | keys' provider_schema.json
jq '.provider_schemas["registry.terraform.io/hashicorp/<provider_name>"] | keys' provider_schema.json

GitHub repo with List/Actions : Extract actions/list

Mastering Terraform Stacks: Post-GA Command References Part 1

quixoticmonk — Thu, 02 Oct 2025 16:17:44 +0000

This post builds on my previous article Terraform Stacks: A Revisit, where I reviewed what Terraform Stacks had evolved to from an idea or beta. The concept of having that layer of abstraction around deployment was novel and I am still looking forward to some of the improvements we will see in the future. In this post, I am looking to review the terraform stacks subcommand in detail based on the updates from HashiConf. Some of the updates actually broke some live demo plans of some fellow HashiCorp ambassadors on Day 2 of HashiConf :) You know who you are.

Anyone wanting a good reference of the changes from beta to General availability(GA) should read the official documentation here. I do feel there are some elements missing or scattered around the documentation elsewhere which could have been surfaced up better. At a high level, terraform stacks subcommand provides a comprehensive set of options organized into primary operations for configuration, deployment groups, and deployment runs.

Prerequisites and Setup

Before diving into the commands, you'll need an active HCP Terraform setup. This includes setting up an HCP Terraform organization, creating a project ( or use the Default Project ) within that organization, and generating a token with appropriate permissions for stack operations. The CLI relies on specific environment variables including TF_STACKS_ORGANIZATION_NAME,TF_STACKS_PROJECT_NAME ,TF_STACKS_STACK_NAME , and TF_TOKEN_app_terraform_io for authentication and targeting the correct resources if not explicitly provided in the commands as arguments or options.

Building on the examples from my previous post, we'll explore the foundational commands that every Terraform Stacks workflow begins with. The terraform stacks init command prepares your configuration directory, while providers-lock ensures consistent provider versions across environments. The validate command checks your configuration syntax before deployment. These commands form the foundation that enables the more advanced operations covered in the following sections.

Note: I have terraform aliased to tf.

If you run terraform stacks post GA, you would see these additional subcommands for configuration, deployment-group and deployment-run. It would be a miss not to introduce these without which the post will be difficult to comprehend.

tf stacks
Usage: terraform stacks [global options] <command> [args]

The available commands for execution are listed below.

Primary Commands:
  init              Prepare the configuration directory for further commands
  providers-lock    Write out dependency locks for the configured providers
  validate          Check whether the configuration is valid
  create            Create a stack
  list              List stacks for a given organization and/or project.
  version           Show the current Stacks Plugin version
  fmt               Reformat your Terraform Stacks configuration to a canonical format


Sub-commands:
  configuration     Manage stack configuration
  deployment-group  Manage deployment groups
  deployment-run    Manage deployment runs


Global options (use these before the subcommand, if any):
  -chdir=DIR              Switch to a different working directory before executing the
                          given subcommand.
  -plugin-cache-dir=DIR   Override the default directory where the stack plugin binary is cached.
  -stacks-version         An alias for the "version" subcommand.
  -no-color=BOOL          Disable color output. Must be explicitly set to true or false.

Usage help:
  -usage                  Show this usage output or the usage for a specified subcommand.
                          Use after the command: terraform stacks <command> -usage

Components : is a replacement of modules in a way; though it is more than modules.Translates to what infrastructure, or components, should be part of the Stack.
Deployments : Where and how many times to deploy the infrastructure in the Stack.
Deployment Groups : Combine a set of deployment targets into a group. Allows to set some specific approval rules for each deployment groups based on specific contextual conditions.
Configuration : Everything including the above with the terraform version , lock files which make up a Stack

General notes before we dive in

I do like the -json usage across the subcommands. May be we are gearing up to a usage of these commands from an agent :)

Note: Can we get some short form syntaxes for these subcommand options already please ?

Create a Stack from your terminal

I somehow feel this command is a little incomplete as it stands now. I am ignoring the global options as they are the same 4 always across Stacks' subcommands. Lets create a Stack in three different variants and see what it translates to in the HCP Terraform UI.

Option 1

tf stacks  create  -organization-name ne-devops -project-name "Default Project" -stack-name "manu-option1"
Creating stack...
Stack: Created stack 'manu-option1'

The result is ...

Reviewing the settings..

Option 2

tf stacks  create  -organization-name ne-devops -project-name "Default Project" -stack-name "manu-option2" -with-template
Creating stack...
Stack: Created stack 'manu-option2'
Creating example stacks configuration...
Stack: Created example stack configuration for 'manu-option2'

The result is ...

Reviewing the settings...

I do not see a difference in the stack created on the HCP Terraform UI with the -with-template option supplied with the terraform stacks create command. Now the argument reads as below

 -with-template      Generate boilerplate configuration

May be it is a placeholder for more things to come.

Option 3

Though this is more of a variant only in terms of how the data is presented back to the user on the completion of a command, I see the value when it comes to passing these logs to some external systems or even to an operations agent.

tf stacks  create  -organization-name ne-devops -project-name "Default Project" -stack-name "manu-option3" -json
{"@level":"info","@message":"Creating stack","@module":"terraform.stacks.ui","@timestamp":"2025-10-01T21:29:06.137667-04:00","format_version":"1.0","type":"create_in_progress"}
{"@level":"info","@message":"Created stack","@module":"terraform.stacks.ui","@timestamp":"2025-10-01T21:29:06.421967-04:00","format_version":"1.0","type":"create_success"}

What am I missing ?

The stacks which are created are barebones at this point. What would make this command wholesome is the ability to associate the stacks with a VCS connection and to be able to start that first run of the configuration fetch that way.

List the stacks

Lets run the stacks list without any arguments on a new terminal.

tf stacks list
╷
│ Error: Missing required flag `-organization-name`
│
│ Please provide the `-organization-name` flag with the name of the target organization.
│ Alternatively, set the ENV VAR 'TF_STACKS_ORGANIZATION_NAME'.
╵
Failure! Could not list stacks

As expected, we do see the need to specify the Organization name.

tabular format


tf stacks list -organization-name ne-devops
        Stack Name        |         Stack ID         |        Created At        |        Updated At        |
       manu-option2       |   st-Y2J3wa6yKBSP83Hc    |    Oct 02, 2025 13:02    |    Oct 02, 2025 13:02    |
       manu-option1       |   st-31HY1439bDRVawex    |    Oct 02, 2025 13:00    |    Oct 02, 2025 13:00    |
        app-stack         |   st-g7uPLPR4pnWyvT7e    |    Oct 01, 2025 17:44    |    Oct 01, 2025 17:44    |
   manuchn-stacks-2025    |   st-jcgFCdyai89kcn5S    |    Sep 30, 2025 14:08    |    Sep 30, 2025 14:08    |
     pet-nulls-stack      |   st-uyBoA811rPgNzvw3    |    Sep 08, 2024 04:41    |    Sep 08, 2024 04:41    |
  external_module_stack   |   st-wfXoXu2a56n3GC4Y    |    Mar 09, 2024 22:00    |    Mar 09, 2024 23:09    |
     pet-nulls-stack      |   st-M6kzAWsw7e7Ldep8    |    Feb 28, 2024 22:57    |    Feb 28, 2024 22:59    |

json format

I was thinking the stacks list would benefit from a column project till I ran the -json format. The data doesn't seem to be present in the output.

tf stacks list -organization-name ne-devops -json
{"format_version":"1.0","organization_name":"ne-devops","project_id":"","stacks":[{"created_at":"2025-10-02T13:02:49Z","id":"st-Y2J3wa6yKBSP83Hc","name":"manu-option2","updated_at":"2025-10-02T13:02:49Z"},{"created_at":"2025-10-02T13:00:22Z","id":"st-31HY1439bDRVawex","name":"manu-option1","updated_at":"2025-10-02T13:00:22Z"},{"created_at":"2025-10-01T17:44:34Z","id":"st-g7uPLPR4pnWyvT7e","name":"app-stack","updated_at":"2025-10-01T17:44:34Z"},{"created_at":"2025-09-30T14:08:37Z","id":"st-jcgFCdyai89kcn5S","name":"manuchn-stacks-2025","updated_at":"2025-09-30T14:08:37Z"},{"created_at":"2024-09-08T04:41:32Z","id":"st-uyBoA811rPgNzvw3","name":"pet-nulls-stack","updated_at":"2024-09-08T04:41:32Z"},{"created_at":"2024-03-09T22:00:44Z","id":"st-wfXoXu2a56n3GC4Y","name":"external_module_stack","updated_at":"2024-03-09T23:09:22Z"},{"created_at":"2024-02-28T22:57:52Z","id":"st-M6kzAWsw7e7Ldep8","name":"pet-nulls-stack","updated_at":"2024-02-28T22:59:54Z"}]}

Filter by project

All the stacks I had listed were part of the Default Project anyway. So it is not not going to show any difference here.

❯ tf stacks list -organization-name ne-devops -project-name "Default Project"
        Stack Name        |         Stack ID         |        Created At        |        Updated At        |
       manu-option2       |   st-Y2J3wa6yKBSP83Hc    |    Oct 02, 2025 13:02    |    Oct 02, 2025 13:02    |
       manu-option1       |   st-31HY1439bDRVawex    |    Oct 02, 2025 13:00    |    Oct 02, 2025 13:00    |
        app-stack         |   st-g7uPLPR4pnWyvT7e    |    Oct 01, 2025 17:44    |    Oct 01, 2025 17:44    |
   manuchn-stacks-2025    |   st-jcgFCdyai89kcn5S    |    Sep 30, 2025 14:08    |    Sep 30, 2025 14:08    |
  external_module_stack   |   st-wfXoXu2a56n3GC4Y    |    Mar 09, 2024 22:00    |    Mar 09, 2024 23:09    |
     pet-nulls-stack      |   st-M6kzAWsw7e7Ldep8    |    Feb 28, 2024 22:57    |    Feb 28, 2024 22:59    |


❯ tf stacks list -organization-name ne-devops -project-name "experiments"
        Stack Name        |         Stack ID         |        Created At        |        Updated At        |

Tying this back to the HCP Terraform UI; why is Stacks not an entity of its own similar to the workspaces ?

Configuration related

As we are peeling the layers of the Stacks onion, we have till now looked at adding the Stacks frame onto the HCP Terraform organization. But it is missing any sort of configuration items to provision any infrastructure to a target platform.

Note: I have configured a variableset on my HCP Terraform organization with an IAM role which allows any stacks in my org to provision some resources ( S3, VPCs) if they fall under my HCP Terraform organization. I am not going to dive into that as that OIDC based setup hasn't changed from the time of beta.

The commands below are run on a directory which has my HashiConf-Stack repo cloned. So this command is supposed to supplement the stacks create in my mind. For most of the commands below, a stack is the frame of reference. So you need either a combination of organization-name, project-name, stack-name or stack-id. I do wonder why we need the project name since we can list the stacks without a project reference in the stacks list command.

list

I am going to use one of the stack ids from the create operations we did earlier. As expected, there are no configuration items associated with the stack manu-option1 at this point.

> tf stacks configuration list -stack-id st-31HY1439bDRVawex
     Sequence Number      |     Configuration ID     |


> tf stacks configuration list -stack-id st-31HY1439bDRVawex --json
{"configurations":null,"format_version":"1.0","stack_id":"st-31HY1439bDRVawex"}

Upload

Running this from a non-stacks directory.

tf stacks configuration upload -stack-id st-31HY1439bDRVawex
╷
│ Error: Missing .terraform-version file
│
│ Terraform Stacks requires a .terraform-version file alongside the root .tfcomponent.hcl files.
╵
╷
│ Error: Failed to open source bundle
│
│ Failed to open source bundle: cannot read manifest: open /Users/manuchn/Documents/2025/TFC/Hashi/experiments/manuchandrasekhar.com/.terraform/modules/terraform-sources.json: no such file or directory. You may need to run `terraform stacks init`.
╵
failed to upload stack configuration

So , you need to initialize the stack , provide a lock configuration and a terraform version. We didn't specify a terraform version when we created the stack using the cli, which I believe doesn't have a version association till a configuration is uploaded.

tf stacks init
Provider "hashicorp/aws" already locked at "5.100.0".
Provider "hashicorp/random" already locked at "3.7.2".
Downloading "hashicorp/aws"@"5.100.0"....
Downloading "hashicorp/random"@"3.7.2"....
Success! Configuration has been initialized and more commands can now be executed.

❯ tf stacks configuration upload -stack-id st-31HY1439bDRVawex
Uploading stack configuration...

Configuration for Stack (id: 'st-31HY1439bDRVawex') was uploaded
Configuration ID: stc-S5Sr3y57SWDLd5G5
Sequence Number: 1

See run at: https://app.terraform.io/app/ne-devops/projects/prj-qbcM8hb5k4EUCGj4/stacks/st-31HY1439bDRVawex/configurations-ga/stc-S5Sr3y57SWDLd5G5

The url which has the configuration or run leads you to the page below if you open the configuration 1

Note: You do not see an apply creating resources as I had destroy=true set on the deployments for the first time.

Subsequently a configuration list renders the below.

tf stacks configuration list -stack-id st-31HY1439bDRVawex
     Sequence Number      |     Configuration ID     |
            1             |   stc-S5Sr3y57SWDLd5G5   |

Note: I have seen some glitches here where the Configurations remain blank even when there is an active configuration. This could be some caching issues on my browser.

Let's re-run the configuration upload with the destroy=true removed in the tfdeploy.hcl file. I did make a mistake on my configuration and had to run the configuration upload twice. So you will see configuration versions up to 3 in the list when we do those. With the auto-approve on:

Diving into the deployment in HCP Terraform, you can see that the resources have been created in my target AWS account using the configuration upload without a VCS connection.

The state from the Stacks standpoint is slightly different from how you are used to from a workspace or pre-GA.

The command configurations upload has this option speculative which can prevent triggering any deployments via this configuration upload. Lets try this again with the option set to true.

tf stacks configuration upload -stack-id st-31HY1439bDRVawex -speculative
Uploading stack configuration...

Speculative Configuration for Stack (id: 'st-31HY1439bDRVawex') was uploaded
Configuration ID: stc-PbHnPRArTLBABzCC

See run at: https://app.terraform.io/app/ne-devops/projects/prj-qbcM8hb5k4EUCGj4/stacks/st-31HY1439bDRVawex/configurations-ga/stc-PbHnPRArTLBABzCC

My issue here is with the phrasing on the option speculative. You are triggering a deployment run under a configuration null. I believe this maps to a speculative plan run on workspaces. I think this should be updated to state that explicitly than using the word deployment here.

-speculative: Upload will be speculative and will not trigger any deployments.

Note: I hope they have an option to see this as a json with some download options.

Watch

This is your command line equivalent of live loading on the HCP Terraform UI or the kubectl watch command.

 tf stacks configuration upload -stack-id st-31HY1439bDRVawex
Uploading stack configuration...

Configuration for Stack (id: 'st-31HY1439bDRVawex') was uploaded
Configuration ID: stc-e6dfkfXL3HgDq1U2
Sequence Number: 4

See run at: https://app.terraform.io/app/ne-devops/projects/prj-qbcM8hb5k4EUCGj4/stacks/st-31HY1439bDRVawex/configurations-ga/stc-e6dfkfXL3HgDq1U2

❯ tf stacks configuration watch -configuration-id stc-e6dfkfXL3HgDq1U2

Entering the command launches you to a watch interface which looks to provide you with a real time update on what is happening with the configuration or deployment. Keep in mind that I have the auto-approve set on the deployment groups which is making the response below skip a Pending state.


[Configuration Sequence Number: 4]
  ✓ Configuration: 'stc-e6dfkfXL3HgDq1U2'                   [Completed]        [24s]
    - Deployment Group: 'test_stack'                        [Deploying]        [33s]

Press q to quit

....


[Configuration Sequence Number: 4]
  ✓ Configuration: 'stc-e6dfkfXL3HgDq1U2'                   [Completed]        [24s]
    ✓ Deployment Group: 'test_stack'                        [Succeeded]        [37s]

Press q to quit

There are additional commands in the configuration side including fetch which requires a VCS connection. I am going to bundle that along the VCS based setup in a different post.

Environment Setup

I could possibly have set these below environment variables than having to add those options in all my commands. But I preferred to know what I am working with , this time around. Maybe in a CI based environment, the environment variable setup would come in handy.

export TF_STACKS_ORGANIZATION_NAME="ne-devops"
export TF_STACKS_PROJECT_NAME="Default Project"
export TF_STACKS_STACK_NAME="app-stack"

Conclusion

With the recent updates , Terraform Stacks provides a unified CLI experience for managing deployments directly against HCP Terraform organizations, offering an alternative to VCS-based deployment workflows. I hope that current implementation gaps will be addressed as platform teams adopt Stacks for managing baseline infrastructure that development teams build upon. As I have always said, Stacks introduces new approaches for provisioning foundational infrastructure across target platforms. However, documented post-GA limitations currently restrict broader adoption in scenarios like AWS OU-based deployments that would typically use StackSets or something similar.

HCP Terraform supports up to a maximum of 20 deployments for a Stack.
Deployment groups currently support a single deployment for a Stack.

I planned to write about deployment groups and runs. But with the length of the post, I felt it is better to break this into a few different posts.

Terraform stacks: A revisit

quixoticmonk — Mon, 01 Sep 2025 22:14:31 +0000

So it's been almost a year since I published the article on Stacks. I even presented on Stacks on two occassions with HashiCorp engineers. The promise of delivering that multi-region/account/environment experience in a native Terraform language was something exciting. So with HashiConf coming up in 4 weeks, where is it now ? What changes have I seen in the recent days ?

Before we jump into the details, lets pull up the definition of Stacks.

Terraform Stacks lets you group and manage your Terraform configurations as repeatable units of infrastructure. Each stack defines what to deploy, where to deploy it, and how to keep it in sync—making it easier to manage complex environments, reuse modules, and automate deployments.

Spoiler alert ; below seems to be a subtle way to say Stacks is going GA soon around HashiConf. Yaaay !!!

Starting September 25, 2025, Stacks usage will count toward your HCP Terraform resource usage limits

Terraform stacks subcommand

Terraform binary recently released support for stacks which was available via the custom tfstacks cli.

This did give the impression that Stacks is possibly coming to the community edition, but the usage details indicate the opposite.

Unlike other CLI utilities or subcommands, terraform stacks uses a usage option than help. You could very well type terraform stacks whcih will give you the same output in your terminal.

terraform stacks -usage
Usage: terraform stacks [global options] <command> [args]

The available commands for execution are listed below.

Primary Commands:
  init              Prepare the configuration directory for further commands
  providers-lock    Write out dependency locks for the configured providers
  validate          Check whether the configuration is valid
  version           Show the current Stacks Plugin version
  fmt               Reformat your Terraform Stacks configuration to a canonical format


Sub-commands:


Global options (use these before the subcommand, if any):
  -chdir=DIR              Switch to a different working directory before executing the
                          given subcommand.
  -plugin-cache-dir=DIR   Override the default directory where the stack plugin binary is cached.
  -stacks-version         An alias for the "version" subcommand.
  -no-color=BOOL          Disable color output. Must be explicitly set to true or false.

Usage help:
  -usage                  Show this usage output or the usage for a specified subcommand.
                          Use after the command: terraform stacks <command> -usage

Let's see how this translates to the tfstacks-cli options.

tfstacks init -> terraform stacks init
tfstacks validate -> terraform stacks validate
tfstacks providers lock -> terraform stacks providers-lock
tfstacks fmt -> terraform stacks fmt

I am not really sure what the stacks version means per se. I was initially thinking there was a corelation between this and terraform version. But the output makes me think this has to do with the Stacks plugin version.

terraform stacks -stacks-version

Terraform Stacks Plugin version: v1.0.0
on darwin_arm64

The one missing option is in regards to the plan

tfstacks plan -organization=REQUIRED_ORG_NAME -stack=REQUIRED_STACK_ID -deployment=REQUIRED_DEPLOYMENT [-hostname=hostname]

HCP Terraform

Interstingly there seems to be a manual upload option which is coming to HCP Terraform which could be a replacement of the terraform plan workflow we are familiar with. Though , it seems like the user interface is ahead of the command implementation on the stacks API. The linked documentation reverts you back to the same page in the Stacks setup (for now).

HCP Terraform limits the number of deployments up to a maximum of 20 deployments.
* One of the usecases I felt Stacks would be great for was multi account deployments for platform specific infrastructure. So, if a deployment is a map to an account; this limit might be a hurdle in some cases.

Terraform support

I might have overlooked this or never really found a use as I wasn't using Stacks as much as I would have wanted to. tfe_stack seems to support setting up a Stack in HCP Terraform on Stacks enabled projects or organizations using Terraform itself.

Linked stacks

Reference : Pass data between Stacks

The idea is similar to what we had with run trigers on HCP Terraform workspaces. What if you had infrastructure stacks which depended on each other ? Linked stacks give you an option to do exactly that.

Declare an upstream_input block in your Stack’s deployment configuration to read values from another Stack's publish_output block. Adding an upstream_input block creates a dependency on the upstream Stack.

The example they have is around an application stack depending on the networking infrastructure which is provisioned using a different stack. Rather than just being able to use a datasource to reference existing resources, any changes to the networking stack retriggers the downstream stack , in case that update to the networking stack somehow affects the infrastructure in the downstream. This helps with the situation where a redeployment trigger would help get the updated values of networking infra in the application Stack.

Output reference in Stacks UI:

Downstream link:

We will dive into this a little bit more in another post. If you are looking to use the linked stacks in the mean time, keep these in mind:

The output definition in your upstream stacks needs the type defined. The type definition is not something I am used to adding on an output.
An empty value in upstream stack which coincided with a missing definition on my end kept failing on the downstream stack with a missing metadata with no details in the diagnostics. Updating the type input on the outputs fixed the issues, but it didn't retrigger my downstream_stack.

Changes in the file

Though the documentation still references tfstack.hcl extensions for anything outside of the deployment configurations, terraform stacks command says otherwise . I think it is a matter of time before this makes into the documentation. Does it make much difference to the user experience ? Probably not.

When you run terraform stacks validate on a Stacks configuration similar to one below; you get the error which indicates that the file names are not matching what it expects it to be.

 tree .
.
├── components.tfstack.hcl
├── deployments.tfdeploy.hcl
├── infrastructure
│   └── main.tf
├── modules
│   └── random
│       └── main.tf
├── providers.tfstack.hcl
└── variables.tfstack.hcl

Deprecation message:

│ Warning: Deprecated filename usage
│
│ This configuration is using the deprecated .tfstack.hcl or .tfstack.json file extensions. This will not be supported in a future version of Terraform, please update your files to use the latest .tfcomponent.hcl or .tfcomponent.json file extensions.

Considering this is still a beta, I expect we will see more changes on these and the APIs.

Open questions

Will there be a migrate or convert operation from existing workspsace based deployment to Stacks based deployment ?
Will we start getting the same ecosystem built around Stacks like with workspaces?
- Policy As Code : For folks using tools outside of the HCP Terraform, that could continue to work. If an organization is invested in Sentinel, how would that work going forward ?
- Day 2 operations, health checks and notifications on workflow operations.
- Deployments to regulated or private environments using Cloud agents or alike.
Language server support for the Stacks blocks : component, deployment and named provider blocks.

Terratags Update: Advanced Pattern Validation, Multi-Provider Support, and Enhanced Reporting

quixoticmonk — Fri, 25 Jul 2025 02:14:19 +0000

Since my initial post about Terratags in May 2025, the project has evolved significantly. What started as a weekend project to enforce basic tag presence on AWS resources has grown into a tagging validation tool with advanced pattern matching, multi-provider support, and updated reporting capabilities. Some of you reached out and opened issues/enhancement requests around some of the feature set currently available v0.4.0.

What's New: Major Updates Since v0.1.0

The latest version of Terratags (v0.4.0) introduces several features that address some of the enhancement requests that came my way:

1. Advanced Pattern Validation with Regex Support

The most significant addition is pattern validation - the ability to validate not just tag presence, but also tag values using regular expressions. This addresses a gap where teams need to enforce specific naming conventions, email formats, or business rules for tag values. I was talking to a customer who wanted something similar few months back to match up to their CMDB naming standards and so on. It did influence some of the work here.

Before: Simple Presence Validation

required_tags:
  - Name
  - Environment
  - Owner
  - Project

Now: Advanced Pattern Validation

required_tags:
  # Strict environment values
  Environment:
    pattern: "^(dev|test|staging|prod)$"

  # Valid email for ownership
  Owner:
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"

  # Project code format
  Project:
    pattern: "^[A-Z]{2,4}-[0-9]{3,6}$"

  # No whitespace in names
  Name:
    pattern: "^\\S+$"

  # Simple presence validation (no pattern)
  Team: {}

2. Multi-Provider Support: Beyond AWS

Terratags now supports additional providers, significantly expanding its utility:

AWS Cloud Control (AWSCC) Provider Support

The AWSCC provider uses a different tag format than the standard AWS provider:

# Standard AWS Provider
resource "aws_s3_bucket" "example" {
  tags = {
    Environment = "prod"
    Project     = "demo"
  }
}

# AWSCC Provider
resource "awscc_apigateway_rest_api" "example" {
  tags = [{
    key   = "Environment"
    value = "prod"
  }, {
    key   = "Project"
    value = "demo"
  }]
}

Terratags now handles both formats seamlessly, with automatic detection and validation.

Azure Providers Support

Support for both azurerm and azapi providers:

# Azurerm Provider
resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"

  tags = {
    Environment = "Production"
    Project     = "Terratags"
  }
}

# azapi Provider with default_tags support
provider "azapi" {
  default_tags = {
    Environment = "Production"
    Project     = "Terratags"
  }
}

The azapi provider even supports default_tags similar to the AWS provider, making tag management more consistent across cloud providers. The issue related to this is kept open as I learn more about the Azure side of providers in Terraform.

3. Enhanced Reporting and Visualization

The HTML reporting system has been modified with:

Visual indicators for compliant, non-compliant, and exempt resources
Detailed breakdown of tag status for each resource
Tag source tracking (resource-level vs provider default_tags)
Exemption details including reasons for exemptions
Summary statistics including exempt resources
Tag violation counts by tag name

4. Pre-commit Hook Integration

As much as I like to take credit for thinking about adding a pre-commit hook integration, I didn't have it in my list of things to do initially. But making this available across the hooks space makes it a lot more valuable and it was easily justifiable.

repos:
  - repo: https://github.com/terratags/terratags
    rev: v0.4.0
    hooks:
      - id: terratags
        args: [
          --config=terratags.yaml,
          --exemptions=exemptions.yaml,
          --remediate
        ]

This enables automatic tag validation before commits, preventing non-compliant resources from entering your codebase.

Real-World Pattern Examples

Environment Validation

Environment:
  pattern: "^(dev|test|staging|prod)$"

✅ Matches: dev, test, staging, prod
❌ Rejects: development, production, DEV, Test

Cost Center Format

CostCenter:
  pattern: "^CC-[0-9]{4}$"

✅ Matches: CC-1234, CC-5678, CC-9012
❌ Rejects: CC123, CC-12345, cc-1234

Project Code Format

Project:
  pattern: "^[A-Z]{2,4}-[0-9]{3,6}$"

✅ Matches: WEB-123456, DATA-567890, SEC-123456
❌ Rejects: web-123, PROJECT, ABC-12

Email Validation

Owner:
  pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"

✅ Matches: devops@company.com, team.lead@company.com
❌ Rejects: username, user@domain, @company.com

Backward Compatibility and Migration

One of the key design principles for these updates was maintaining backward compatibility. All existing simple configurations continue to work unchanged:

# This continues to work exactly as before
required_tags:
  - Name
  - Environment
  - Owner

You can migrate to advanced features incrementally:

# Mixed format - gradually add patterns
required_tags:
  Name: {}  # Just presence validation
  Environment:
    pattern: "^(dev|test|staging|prod)$"  # Pattern validation
  Owner: {}  # Just presence validation for now

Future Roadmap: What's Next

Add Google provider support.
Review any open issues with module level validation.

If you're new to Terratags or want to upgrade:

Installation

# Using Homebrew (recommended)
brew install terratags/tap/terratags

Basic Usage with Pattern Validation

Create a configuration file with patterns:

required_tags:
  Environment:
    pattern: "^(dev|test|staging|prod)$"
  Owner:
    pattern: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
  Name: {}

Run validation:

terratags -config config.yaml -dir ./infra -report report.html

Set up pre-commit hooks:

repos:
  - repo: https://github.com/terratags/terratags
    rev: v0.4.0
    hooks:
      - id: terratags

Resources

GitHub Repository: https://github.com/terratags/terratags
Documentation: https://terratags.github.io/terratags/
Pattern Matching Guide: https://terratags.github.io/terratags/pattern-matching/
Pre-commit Integration: https://terratags.github.io/terratags/pre-commit/

I'd love to hear about your experience with Terratags, especially how you're using the new pattern validation features. Feel free to reach out with feedback and suggestions !

Building "Python a Snake Game" with Amazon Q Developer CLI: A Journey Back to Gaming Fundamentals

quixoticmonk — Sat, 14 Jun 2025 05:05:22 +0000

Participating in the AWS Build Games Challenge: Build Classics with Amazon Q Developer CLI

Introduction

There's something magical about the simplicity of classic games. While modern gaming pushes the boundaries of graphics, physics, and complexity, sometimes the most engaging experiences come from the fundamentals. That's exactly what I discovered when I decided to recreate the timeless Snake game as "Python a Snake Game" using Python and Pygame, with assistance from Amazon Q Developer CLI.

This project is my entry for the AWS Build Games Challenge, where developers are challenged to build classic games using Amazon Q Developer CLI as their coding companion.

Why Snake? The Perfect Starting Point

Snake isn't just a game—it's a rite of passage in my mind. It made sense to build it with two intentions:

Show whats possible with code to a 10 year old who loves video games.
Relive the button mashing experience I had with those old Nokia phones from my childhood, Nokia 3310 I think,

I never thought about this this way, Snake teaches fundamental game development concepts:

Game loops and state management
Collision detection
Real-time input handling
Dynamic object growth and movement
Score tracking and game over conditions

These core concepts form the foundation of virtually every game, making Snake an ideal project for both learning and showcasing development skills.

Why pygame?

Thats the closest to a gaming library I have ever used and this being the summer vacation time in US; I felt this was the perfect time to introduce programming to my 10 year old. And yes, meeting Al Sweigart in a PyOhio few years back when I was still understanding the language made want to go back to it.

The Power of Prompting

One of the most fascinating aspects of working with Amazon Q Developer CLI was discovering how the quality of the initial prompt directly impacts the final product. Rather than simply asking for "a Snake game," I crafted a structured prompt that became the blueprint for the entire project.

My Initial Vision

My original request was straightforward but comprehensive: I wanted to create "Python a Snake Game"—a classic Snake game implementation using Python and Pygame that would showcase both nostalgic gameplay and modern development practices. The key was being specific about the experience I wanted to create—not just a functional game, but an enjoyable one.

The Comprehensive Structured Prompt: A Development Blueprint

What emerged from this collaboration was a detailed structured prompt that served as both specification and guide. This wasn't just a list of features—it was a comprehensive development framework that addressed every aspect of game creation: Prompt

From Prompt to Working Game: The Development Process

Following the Blueprint

The beauty of having a structured prompt became evident during implementation. Instead of making ad-hoc decisions or getting stuck on design choices, I had a clear roadmap to follow. Every feature request in the prompt translated directly into code structure and functionality.

Success Criteria as Development Milestones:
The detailed structured prompt defined specific success criteria that became my development checklist:

✅ Game runs without errors in 800x600 window
✅ Responsive arrow key controls
✅ Proper collision detection
✅ Score tracking functionality
✅ Clean game over and restart mechanics
✅ Smooth gameplay experience

Technical Implementation Highlights

Following the Blueprint

The structured prompt's emphasis on object-oriented design resulted in clean, maintainable code structure.

The game architecture follows clean object-oriented principles:

class Snake:
    def __init__(self):
        self.reset()

    def reset(self):
        # Initialize snake in center with 3 segments
        start_x = GRID_WIDTH // 2
        start_y = GRID_HEIGHT // 2
        self.body = [(start_x - i, start_y) for i in range(INITIAL_SNAKE_LENGTH)]
        self.direction = Direction.RIGHT

Key Technical Decisions

I ended up with some of the below defaults after a couple of iterations when it looked completely different than I thought.

Window Size: I chose 800x600 pixels—a browser-friendly size that's large enough for comfortable gameplay but small enough to fit on any screen. This decision reflects modern web-first thinking while maintaining the classic feel.

Grid System: The 20x20 pixel cell system provides the perfect balance between smooth movement and the chunky, retro aesthetic that makes Snake instantly recognizable.

Frame Rate: At 10 FPS, the game maintains that classic Snake tempo—fast enough to be engaging, slow enough to be controllable.

Game Features That Matter

User Experience Focus

Pause Functionality: Press 'P' to pause/resume—essential for longer games
Instant Restart: Space or Enter to quickly restart after game over
Visual Clarity: Distinct colors for snake head (bright green), body (darker green), and food (red)
Score Tracking: Real-time score display with 10 points per food item

Controls That Feel Right

Arrow Keys: Snake movement
P: Pause/Resume
ESC: Quit game
SPACE/ENTER: Restart after game over

Technical Highlights

Efficient Collision Detection

The game uses grid-based collision detection, checking if the snake's head position matches food coordinates or intersects with walls/body segments. This approach is both computationally efficient and perfectly suited to the grid-based movement system.

Snake Growth

Rather than constantly resizing arrays, the snake growth system uses a "grow_pending" counter, adding segments only when needed and maintaining optimal performance even with very long snakes.

Lessons Learned: The Art of AI-Assisted Development

The Power of Detailed Prompting

This project taught me that the quality of AI-assisted development is directly proportional to the quality of the initial prompt. The comprehensive structured prompt didn't just describe what I wanted—it provided:

Context and Constraints: Specifying the 800x600 browser-friendly window size and 20x20 pixel grid system gave clear boundaries for design decisions.

Success Metrics: Defining specific criteria like "responsive arrow key controls" and "smooth gameplay experience" provided measurable goals.

Implementation Philosophy: Emphasizing object-oriented design and best practices ensured the code would be maintainable and extensible.

User Experience Focus: Including details about pause functionality, visual feedback, and error handling elevated the project from functional to polished.

The Iterative Refinement Process

Working with Amazon Q Developer CLI revealed the importance of iterative refinement in AI-assisted development:

Initial Prompt → Comprehensive Structured Prompt → Implementation → Refinement

Each stage built upon the previous one, with the comprehensive structured prompt serving as the crucial bridge between high-level vision and detailed implementation. This process ensured that the final product wasn't just functional, but thoughtfully designed and professionally executed.

Simplicity is Sophisticated

Building Snake reinforced that great games don't need complex graphics or mechanics. The challenge lies in perfecting the fundamentals—responsive controls, fair difficulty progression, and satisfying feedback loops.

User Experience in Retro Games

Even classic games benefit from modern UX thinking. Features like pause functionality, clear visual feedback, and intuitive restart mechanisms make the difference between a nostalgic novelty and a genuinely enjoyable experience.

What's Next?

One of the most valuable aspects of the comprehensive structured prompt was its forward-thinking approach. It included optional enhancements that could extend the project:

Sound effects for eating food and game over events
Different difficulty levels with variable speed settings
Power-ups or special food items with unique effects
Snake skin patterns or visual themes
Multiplayer support for competitive play
Mobile-friendly touch controls adaptation

Try It Yourself

"Python a Snake Game" is available with full source code, requirements file, and detailed setup instructions. Whether you're learning game development, exploring Python and Pygame, or just want to enjoy some nostalgic gaming, this Snake implementation offers a polished, accessible experience.

Repository: https://github.com/quixoticmonk/python

# Quick start
git clone https://github.com/quixoticmonk/python.git
cd python/snake_q
pip install -r requirements.txt
python snake_game.py

Conclusion: The Future of AI-Assisted Game Development

Participating in the AWS Build Games Challenge with Amazon Q Developer CLI has been an enlightening experience that goes far beyond building a simple game. It demonstrated that effective AI-assisted development is fundamentally about collaboration—between human creativity and AI capability, between high-level vision and detailed implementation, between classic game design and modern development practices.

The Broader Impact

This project represents more than just a nostalgic coding exercise. It showcases how AI-assisted development can make high-quality software creation more accessible while maintaining professional standards. The detailed structured prompt approach could be applied to any software project, from web applications to mobile apps to enterprise systems.

"Python a Snake Game" may be a simple game, but building it well requires attention to detail. With Amazon Q Developer CLI as a development partner, the journey from concept to polished game becomes not just faster, but more enjoyable and educational.

This project was built as part of the AWS Build Games Challenge. The complete source code, comprehensive structured prompt, documentation, and setup instructions are available in the project repository: https://github.com/quixoticmonk/python

Game Stats:

Language: Python 3.11+
Framework: Pygame 2.0+
Window Size: 800x600 pixels
Grid System: 20x20 pixel cells
Frame Rate: 10 FPS
Features: Pause, restart, score tracking, collision detection

Ready to play? The snake is waiting! 🐍

*Want to see how detailed prompting can transform your development process? Check out the comprehensive structured prompt in the repository: https://github.com/quixoticmonk/python .

Simplifying Policy Management in HCP Terraform with the Policysets Module

quixoticmonk — Sun, 01 Jun 2025 19:35:15 +0000

As organizations scale their infrastructure with Terraform, policy management becomes increasingly important. Whether you're enforcing security standards, compliance requirements, or operational best practices, having a streamlined way to manage and deploy policies is essential.

HashiCorp and AWS have worked on publishing some pre-built sentinel policies for AWS provider which you can find below:

I recently faced a challenge: I needed to import locally available Sentinel and OPA policies to HCP Terraform, as well as policies available in public GitHub repositories. After exploring various approaches, I decided to create a reusable Terraform module to solve this problem once and for all. As with most of these modules or utilities, I start off with something I have come across and post them out as public if I think others might benefit. I understand you can do this via a VCS connection with your repository ( requires a GitHub app connection) or a forked repository of a public policyset. And I do remember some sentinel based ones available across the HashiCorp repositories, but they didn't cover the OPA ones.

Introducing the Policysets Module

The result of this effort is a Terraform module that makes it easy to import and manage policy sets in HCP Terraform. The module is now available in the Terraform Registry at quixoticmonk/policysets.

Key Features

Multiple Policy Sources: Import policies from local directories or public Git repositories
Framework Support: Works with both Sentinel and OPA policy frameworks
Flexible Targeting: Apply policies globally or to specific workspaces
Configurable Settings: Customize policy evaluation settings to match your requirements

How to Use the Module

Let's walk through some common scenarios for using this module.

Scenario 1: Importing Local Sentinel Policies

If you have Sentinel policies in a local directory that you want to apply to all workspaces in your organization:

module "sentinel_policy_set" {
  source  = "quixoticmonk/policysets/tfe"

  name         = "my-sentinel-policies"
  description  = "Sentinel policies for cost control"
  organization = "my-organization"
  policy_kind  = "sentinel"

  policy_source      = "local"
  local_policies_path = "${path.module}/policies"

  # Apply globally to all workspaces
  global = true
}

Make sure your local policies directory has the proper structure, including a sentinel.hcl file that defines the policy sets.

Scenario 2: Importing Local OPA Policies

For OPA policies stored locally that you want to apply to specific workspaces:

module "opa_policy_set" {
  source  = "quixoticmonk/policysets/tfe"

  name         = "my-opa-policies"
  description  = "OPA policies for compliance"
  organization = "my-organization"
  policy_kind  = "opa"

  policy_source       = "local"
  local_policies_path = "${path.module}/policies"

  workspace_ids = ["ws-v93RUQTMfJxoX18s"]
}

Your OPA policies directory should include a policies.hcl file that defines the policy configuration.

Scenario 3: Importing Policies from a Public GitHub Repository

If you want to use policies from a public GitHub repository:

module "policy_set" {
  source  = "quixoticmonk/policysets/tfe"
  version = "latest"

  name              = "cis-policies"
  description       = "Sentinel policies supporting CIS framework"
  organization      = "my-organization"
  policy_kind       = "sentinel"
  policy_source     = "git"
  git_url           = "https://github.com/quixoticmonk/policy-library-CIS-Policy-Set-for-AWS-Terraform.git"
  git_branch        = "main"
  git_policies_path = "./"

  # Apply globally to all workspaces
  global = true
}

Notes

When using the git source option, the module will clone the repository to a temporary directory within the module. Make sure the Git command-line tool is available in your environment.
For the local source option, the specified directory must exist and contain valid policy files.
The global and workspace_ids options are mutually exclusive - you can either apply policies globally or to specific workspaces. This forced me to have two different policysets based on the scope of the policies.
When using policy_kind = "opa":
- The agent_enabled parameter is always set to true, regardless of the input value
- The overridable parameter is only valid for OPA policies and ignored for Sentinel policies
policy_tool_version was another input which had to be reviewed since the only common default which could be used was latest. I preferred a single input than two different inputs for opa or sentinel and then enforcing rules on top of it.

Module Requirements

Terraform >= 1.0.0
TFE Provider >= 0.40.0

Getting Started

To get started with this module:

Add the module to your Terraform configuration as shown in the examples above
Configure your HCP Terraform provider with appropriate credentials
- TFE_TOKEN as an environment variable with permissions to create policysets
Run terraform init to download the module
Run terraform plan to see what changes will be made
Run terraform apply to create the policy set in your HCP Terraform organization

What's Next

For the git based path, I want to consider if a curl or wget equivalent is better than expecting git being available in every machine this module is run on.

Conclusion

Managing policies at scale doesn't have to be complicated. With this module, you can easily import and manage policies from various sources, ensuring consistent governance across your Terraform deployments.

The module is open source and available on the Terraform Registry. I welcome feedback, issues, and contributions to make it even better!

Check out the full documentation and source code at quixoticmonk/policysets/tfe to get started.

Forem: quixoticmonk

Terraform 1.15 Alpha: Variable and Output Deprecation

Why is this important ?

Module authors:

Module users:

Deprecation-Guided Migration

Variable Deprecation

Simple message

Structured message

Function support ?

Module example

Outputs

Module outputs

What about root module outputs ?

Deprecation Suppression flag

Understanding Internal vs Your Warnings

Conclusion

Adding agent skills for Terraform

So what's the problem statement?

How does it work ?

Adding the Skill

What list resources are supported ?

/scripts

Testing the Skill in Practice

Actual tests

Test 1 : Supported resources and TF version above 1.14.0

Test 2 : TF version below 1.14.0

Effectiveness of what you wrote

Installation

Review

Learnings

Conclusion

Kiro has Terraform skills

What are HashiCorp Agent Skills?

So why should you care ?

How do you use it ?

Skills Installation

Kiro skills resource

Skills in Action

Usage

Bloopers

Without the agent invoked.

Looking Forward

Stategraph: Deploy on AWS with Terraform Part 1

Dev setup with Docker(Finch) compose

Understanding the group-id

Initial Web Interface Impressions

Deployment configuration using Terraform

Architecture Overview

Prerequisites

Key Configuration

Required Variables

Container Configuration

Deployment

Stategraph UI

State Migration

State Overview

Inventory

Querying Resources

Monitoring and Troubleshooting

Deployment Challenges

Conclusion

Terraform Module Guard: Multi-Engine Policy Validation for Module Sources

The Problem

My intention

Data Set

✅ Good Module Sources

❌ Bad Module Sources

1. Sentinel (HCP Terraform)

2. Checkov

3. Open Policy Agent (OPA)

4. Pre-commit Hooks

How can you get started ?

Terratags v0.6.0: Remote Configuration and Google Cloud Support

What's New in v0.6.0

Remote Configuration Support

HTTP/HTTPS URLs

Git Repositories

Version Pinning and Environment-Specific Configs

Google Cloud Provider Support

Understanding `Internal` vs `Your` Warnings

`/scripts`

Understanding the `group-id`