👋 Hi! I’m Bibin Wilson. In each edition, I share practical tips, guides, and the latest trends in DevOps and MLOps to make your day-to-day DevOps tasks more efficient. If someone forwarded this email to you, you can subscribe here to never miss out!
✉️ In Today’s Newsletter
What Terraform Actions are and why they were introduced
Common use cases and a typical workflow
A hands-on example to see how they work in practice
A quick look at some of the latest Terraform features
Remote job opportunities related to Terraform and Cloud roles
🎁 For k8s Certification Aspirants
The Linux Foundation is running a limited-time Lunar New Year Sale. If you are preparing for Kubernetes certifications, this is a good chance to save money. Use code LUNAR26CT at kube.promo/devops to get a flat 35% discount on individual certifications.
For 50% bundle discounts, extra coupons, and other offers, check this GitHub repository for the full list.
Terraform Actions
Terraform has always excelled at CRUD operations. Meaning creating, reading, updating, and deleting infrastructure. But what about everything that happens after the infrastructure is up?
For example,
Invoking a lambda function when needed.
Running an Ansible playbook to configure software.
Invalidating a CDN cache after deploying new assets.
Rebooting a server after a config change.
These are day-2 operations, and until now, Terraform had no clean option for them.
Before v1.14, you had to go with workarounds like provisioners ((local-exec or remote-exec) or external scripts using CI/CD pipelines.
With the introduction of Actions after v1.14, you can perform these operations using the terraform native action blocks built directly into providers (e.g., AWS Provider or Azure Provider).
It is clean, declarative, and state-file friendly.
Example Use Case
Let’s look at a very common and practical scenario.
Lets say you want to invalidate CloudFront distribution cache when there is a update in static files deployed through terraform.
In this case, you can invoke the aws_cloudfront_create_invalidation action to invalidates CloudFront distribution cache for specified paths.
Here is a terraform code example.
action "aws_cloudfront_create_invalidation" "assets" {
config {
distribution_id = aws_cloudfront_distribution.example.id
paths = [
"/images/*",
"/css/*",
"/js/app.js",
"/index.html"
]
timeout = 1200 # 20 minutes
}
}Once this action is triggered, it will wait for the operation to complete.
Action Execution Flow
When you run terraform apply, infrastructure provisioning happens first. Once resources are created and stable, any defined actions execute as a separate phase without modifying Terraform configuration or state.
The following diagram illustrates how the operations are sequentially done when we apply.
Action Block Structure
Actions are defined as separate blocks in your Terraform configuration. The syntax is clean and familiar.
action "<PROVIDER_ACTION_TYPE>" "<NAME_OF_ACTION>" {
config {
// action-specific configuration
}
}The following is an example of an action block to stop an instance.
💡 Key Insight
Actions are not stored in state. They execute after the state has been committed. This means if an action fails, your infrastructure state remains consistent and accurate since the failure is operational, not structural.
Standalone vs. Lifecycle-Bound
Terraform Actions come in two implementation types, each suited to different operational workflows.
1. Manual Trigger
You define the action alongside your resource, but trigger it only when you need it. It is perfect for on-demand operations like stopping a test instance after work is done.
For example,
terraform apply -invoke action.<PROVIDER_ACTION_TYPE>.<NAME_OF_ACTION>2. Automatic Trigger
In this mode, you attach a lifecycle condition like after_create to trigger the action automatically. For example, it is ideal for running Ansible playbooks or invoking a lambda function right after provisioning.
For example,
lifecycle {
action_trigger {
events = [after_create]
actions = [action.aws_lambda_invoke.test_invoke]
}Try It: Invoke a Lambda with Actions
Enough theory. Let’s test this with real code.
We tested the Terraform Actions using a simple Python-based Lambda function that lists S3 buckets. Clone the repository and follow along.
git clone https://github.com/techiescamp/terraform-aws.git
cd terraform-aws/terraform-actionsThe following shows the directory structure used in the Terraform code.
.
├── lambda.tf
├── lambda_src
│ └── list_s3.py
├── list_s3.zip
├── provider.tfThe script list_s3.py inside the lambda_src directory is the lambda function that list the bucket names.
The lambda.tf will create a Lambda function. It also includes an action block aws_lambda_invoke) to invoke the function as given below.
...
action "aws_lambda_invoke" "test_invoke" {
config {
function_name = aws_lambda_function.list_s3_buckets.function_name
payload = jsonencode({
})
}
}
...Deploy the Lambda Function
First, let’s deploy the Lambda function using Terraform and run the normal init, plan, and apply commands.
terraform init
terraform plan
terraform applyThe Lambda function will be created, but it will not be triggered. We need to trigger it using the Terraform action defined in the code.
Preview the Action
Before running the invoke action, let’s use the plan command to see which action will be invoked.
terraform plan -invoke action.aws_lambda_invoke.test_invokeYou will get the following output, which shows the aws_lambda_invoke action that will be invoked.
Terraform will invoke the following action(s):
# action.aws_lambda_invoke.test_invoke will be invoked
action "aws_lambda_invoke" "test_invoke" {
config {
function_name = "list_s3"
payload = jsonencode(
{
key1 = "value1"
key2 = "value2"
}
)
}
}Invoke the Action
You can now use the following command to manually invoke the action.
terraform apply -invoke action.aws_lambda_invoke.test_invokeThis will prompt you to type yes to continue the execution. Once the invocation is completed, you will get the following output.
Action action.aws_lambda_invoke.test_invoke (triggered by CLI): Invoking Lambda function list_s3...
.
.
Apply complete! Resources: 0 added, 0 changed, 0 destroyed. Actions: 1 invokedVerify in AWS Console
To check this in the AWS console, open the Lambda service and go to Functions.
Select the Lambda function and open the Monitor tab.
Scroll down to the CloudWatch Logs section and open the latest log stream.
Expand the log to see the output of the script executed by the Lambda function.
Try Automatic Trigger
If you want to trigger the action automatically after provisioning, you only need to add a lifecycle block, as shown below. This will trigger the Lambda invoke action.
...
lifecycle {
action_trigger {
events = [after_create]
actions = [action.aws_lambda_invoke.test_invoke]
}
Now every terraform apply that creates the resource will also invoke the Lambda
Teardown Resources
After testing, remember to clean up the resource. Use the following command to destroy the Lambda function.
terraform destroyThat’s a Wrap!
Terraform Actions is just getting started.
It is is a new feature and provider support is still rolling out. For example, for AWS you have only the following actions now.
aws_lambda_invoke: Invokes a Lambda function with a custom payload
aws_ec2_stop_instance: Stop a running EC2 instance
aws_cloudfront_create_invalidation: Invalidate CloudFront distribution cache paths
The most important thing? The pattern is established.
Providers now have a standardized way to expose operational capabilities. As the AWS, Azure, and GCP providers ship updates, the list of available actions will grow.
For example, RDS snapshots, ECS deployments, instance reboots, and more.
🧱 Latest Terraform Features
The following are some of the features Terraform recently released.
Terraform Search and Import: This search-and-import feature automatically imports resources that drift and maps them to the existing infrastructure.
Terraform Write Only Arguments: This write-only argument feature is useful when you pass sensitive information but do not want it stored in the state file. For example, updating the rotated master password from Secret Manager to the RDS instance.
Terraform Ephemeral Resources: Ephemeral resources are dedicated Terraform resource blocks that handle temporary data during apply only, but do not store it in the state file. For example, passing the ECR login token for a Helm chart over a CI/CD pipeline to pull images.
📦 Keep Yourself Updated
Kubernetes Drives AI Expansion: Kubernetes adoption for AI workloads has hit 82% and is now the core engine for scaling AI, but organisational culture and cross-team collaboration are now the biggest barriers to moving AI from experiments into reliable production.
No More LocalStack Community Edition: LocalStack is changing how it delivers its AWS cloud emulator. Rather than separate Community and Pro editions, LocalStack for AWS will become a single, unified distribution starting in March 2026
Architecting Agentic MLOps: The article explains that the world of AI is shifting from simple models and retrieval systems to true autonomous AI agents that can reason, plan, and act across complex problems.
🧰 Remote Job Opportunities
Enfec - Sr DevOps Engineer (3-5 yrs)
Rackspace Technology - AWS DevOps Engineer III (5-10 yrs)
GoTo - Sr DevOps Engineer (5+ yrs)
VDart Digital - DevOps Engineer
Cision - Senior DevOps Engineer/SRE (5+ yrs)
Cuculus - Senior DevOps Engineer (5+ yrs)
Winzons - Cloud Engineer – AWS (0-4 yrs)
Protera - Cloud Engineer (5 yrs)
Awign - Cloud Engineer (3-5 yrs)
Radiant Systems Inc - DevOps Engineer (6+ yrs)
