DEV Community: Kuljot Biring

Tines - SOAR Tool

Kuljot Biring — Wed, 12 Nov 2025 21:31:51 +0000

In recent times, I have been working in Tines as we have shifted to this platform for our SOAR needs.

Tines SOAR is a Security Orchestration, Automation, and Response platform that uses a no-code/low-code interface to help security teams automate and manage security workflows, making them faster and more efficient. It integrates with various security tools through an API-centric approach, allowing it to automate tasks like responding to alerts, triaging incidents, and enriching threat intelligence data

I have been enjoying using this tool a great deal as it allows a lot of flexibility and comes with a large number of built-in integrations.

Tines also has great performance as I have noted that the platform can run actions in parallel which reduces run time as compared to some other SOAR products.

Using Tines, I have been able to automate 50 hours (and counting) of security work so that security engineers can spend time on more value added projects.

As part of my learning on this platform I have completed both the Tines Core Certification as well as the Tines Advanced Certification.

These certifications contain a number of pre-labs which contain a lot of good hands-on material and tips and creates to create robust/efficient stories.

I am looking forward to further my knowledge/skills on the platform in order to increase efficiencies via automation!

Cybr - [LAB] Importing AWS resources into Terraform

Kuljot Biring — Wed, 16 Jul 2025 21:24:05 +0000

Today we are going to solve the challenge lab Import an AWS resource created by Cybr.

This lab will test our skills to see if we can successfully import an S3 bucket which has already been created into our terraform state and configuration.

So let's take a look at the scenario presented:

Scenario 👨‍🔬

For our scenario, let’s pretend that you’ve already completed this course, and you go to your team to tell them you need to start using Terraform and IaC to manage all of your infrastructure in AWS accounts. You decide to start with one of the easiest accounts that has the fewest resources. That account has an Amazon S3 bucket that was manually created. You’d like to start by importing that resource.

It’s imperative that you not change any of the bucket’s existing settings/configurations! You are only importing the existing resource, not applying any changes to that bucket.

You’ve completed this step when you get the following message:

❯ 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.

Once you’ve important the bucket successfully, go ahead and delete it with terraform destroy!

You’ve completed this step when you get the following message:

❯ terraform destroy
aws_s3_bucket.bucket: Refreshing state...
...

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.

Enter a value: yes

aws_s3_bucket.bucket: Destroying... [id=cybrlab-import-bucket-272281913033]
aws_s3_bucket.bucket: Destruction complete after 0s

Destroy complete! Resources: 1 destroyed.

And when running this command returns zero buckets:

❯ aws s3api list-buckets

Good luck and have fun!

We are also given the following hints:

Tip #1

Here’s the Amazon S3 CLI documentation and list-buckets will probably be helpful.

Tip #2

Here’s a link to the AWS provider documentation for convenience.

Tip #3

A good starting point is to create three files: main.tf, provider.tf, variables.tf. Start by configuring those.

Tip #4

You are very likely to encounter errors when importing resources with Terraform, especially when running terraform plan after importing. This is normal and part of the troubleshooting process! Read the error codes — they are usually very helpful.

Bonus Points

For bonus points, if you get this warning, find a way to get rid of it!

Warning: Argument is deprecated

Note: There are several valid methods of completing this lab. I am just choosing the one of them. Also note that the resource blocks and outputs have been sanitized - you will need to fill these in with the values you get back

We are first going to set up our profile with provided credentials. Press Start Lab on the lab webpage to reveal our Access Key ID and Secret Access Key. In our terminal we enter: aws configure --profile cybr. We enter the generated values as follows:

We are good to go. Let's start creating our required files.

We begin with our provider.tf file. To get the latest provider version we head over to the Terraform AWS Registry and in the top right of the page select USE PROVIDER which will drop down the code blocks we need.

We are going to add some configuration to our AWS provider block to use a variable for the region (which we will set soon) and the profile we want to use (which we set up earlier).

Our provider.tf will look like this:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "6.3.0"
    }
  }
}

provider "aws" {
  # Configuration options
  region = var.aws_region
  profile = "cybr"
}

Now, we write our variables.tf file like so:

variable "aws_region" {
description = "The AWS region to deploy in"
type = string
default = "us-east-1"
}

Here we are setting our region to us-east-1.

It's time to implement out main.tf file. Before we attempt to create any resource blocks, we are going to need to find the existing S3 bucket. In our terminal we run the command aws s3api list-buckets --profile cybr.

Nowe we get back a JSON object that shows the details of the existing bucket that will look similar to this (sanitized and anonymized):


{
  "Buckets": [
    {
      "Name": "demo-import-bucket",
      "CreationDate": "2025-07-16T20:26:20+00:00"
    }
  ],
  "Owner": {
    "DisplayName": "example-user",
    "ID":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  }
  "Prefix": null
}

Once we grab the name we can write our code using a minimal resource block as follows:

import {
  to = aws_s3_bucket.bucket_to_import
  id = "demo-import-bucket"
}

resource "aws_s3_bucket" "bucket_to_import" {}

In the resource block replace id with the actual name of the bucket you got back from the terminal command above.

Now, in the terminal run a terraform init.

It would be a good idea to also run a terraform validate to ensure our code doesn't have any glaring issues.

Now we run a terraform plan followed by a terraform apply. We will see our resource being imported and the state file being created.

Follow that up with a terraform state list. We should see aws_s3_bucket.bucket_to_import.

Let's see the details so we can grab them and drop them into our resource block. We run a terraform state show aws_s3_bucket.bucket_to_import

Copy the following corresponding values from the output; bucket and force_destroy and update the resource block. Additionally, we are going to set force_destory = true.

Our main.tf will look like this:

import {
  to = aws_s3_bucket.bucket_to_import
  id = "demo-import-bucket"
}

resource "aws_s3_bucket" "bucket_to_import" {
    bucket = "demo-import-bucket"
    force_destroy = true
}

Now run a terraform plan again to confirm what changes we are going to make.

If satisfied, run a terraform apply -auto-approve which will confirm and apply the changes.

Great! Now our rogue resource is being managed by terraform.

It's time to clean up our resources. We can (optionally) remove the import block in our main.tf file as we no longer need it. Subsequently, we can run a terraform destroy and confirm our choice.

This will destroy our S3 bucket. We can confirm this with an aws s3api list-buckets --profile cybr command run in the terminal. We should see no buckets listed.

If everything has worked as expected, press the terminate lab button and you have successfully completed the challenge lab.

To view the files we created in their final form, see the below:

Cybr - Beginner's Guide to AWS CloudTrail for Security

Kuljot Biring — Tue, 15 Jul 2025 16:24:40 +0000

A few days ago I completed the course Beginner's Guide to AWS CloudTrail for Security by Cybr.

This course succinctly covers the most important aspects of CloudTrail and it's integration with other services. There are several demo lessons which give a details walk-through of setting up CloudTrail and the various considerations that need to be taken into account with its different settings.

Some of the things you will learn are:

CloudTrail Essentials
CloudWatch Logs & SNS notifications
CloudTrail Insights
CloudTrail Lake
Monitoring CloudTrail itself
IAM
Log file integrity
Encryption
Useful CloudTrail CLI commands
AWS Security Monitoring Best Practices

Overall this a great course that gives you great insight on how to use CloudTrail and the various nuances that you must consider when enabling the service and using it in combination with other AWS services.

Cybr - [LAB] [Challenge] Configure security groups and NACLs to specific requirements

Kuljot Biring — Thu, 10 Jul 2025 23:36:02 +0000

In this walk-through we are going to solve the lab Configure security groups and NACLs to specific requirements created by Cybr.

However, the twist is we are going to solve this using Terraform!

Let's have a look at the requirements:

Lab Details 👨‍🔬
Length of time: ~30 minutes
Cost: $0
Difficulty: Moderate

Scenario 🧪

Create four separate security groups:

Security Group #1
Name it Web Servers
Provide open access to two commonly used ports for application servers: 80 and 443
This open access should work for both IPv4 and IPv6

Security Group #2
Name it App Servers
Provide open access for instances in the Web Servers SG to be able to communicate with your app servers

Security Group #3
Name it IT Administration
Provide open access for your organization’s IT admins to be able to SSH and/or RDP into the cloud instances

Your IT admins should only ever have access those instances from the following two IP addresses:
172.16.0.0
192.168.0.0

Security Group #4
Name it Database
Provide open access for application servers to be able to communicate with your MySQL database

Create two separate NACLs:

NACL #1
Name it Public Subnets
Provide open access to allow all traffic that would be allowed by the security groups for resources that would be launched in the public subnets

NACL #2
Name it Private Subnets
Provide open access to allow all traffic that would be allowed by the security groups for resources that would be launched in the private subnets

Let's get started. We are going to create four files:

terraform.tf
variables.tf
main.tf
outputs.tf

We start off with out terraform.tf file.

First, we are going to add out Terraform block like so:

terraform {
  required_version = ">= 1.3.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

This block performs two functions:

requires that the Terraform version must be 1.3.0 or higher.
Declares the AWS provider by specifying its source (from HashiCorp) and requires that its version be 5.0 or higher.

By specifying versions, we also ensure compatibility with specific Terraform and provider versions.

Next, in this same file we add the provider block:

provider "aws" {
  region = var.aws_region
}

This block configures the AWS provider. It sets the region to use via a variable which we will set soon in a variables.tf file. By using a variable, we can re-configure our region without hardcoding it, allowing for easy updates.

Let's now create out variables.tf file. Our purpose of creating this file is to; define input variables in one place, allow easy modification of infrastructure settings, allow our code to be flexible and reusable, supports dynamic configuration.

variable "aws_region" {
  description = "The AWS region to deploy resources into"
  type        = string
  default     = "us-east-1"
}

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "it_admin_ips" {
  description = "List of IPs for IT admin access"
  type        = list(string)
  default     = ["172.16.0.0/16", "192.168.0.0/16"]
}

variable "web_sg_name" {
  type    = string
  default = "web-server"
}

variable "app_sg_name" {
  type    = string
  default = "app-servers"
}

variable "it_sg_name" {
  type    = string
  default = "it-administrator"
}

variable "db_sg_name" {
  type    = string
  default = "database"
}

variable "public_nacl_name" {
  type    = string
  default = "public-subnets"
}

variable "private_nacl_name" {
  type    = string
  default = "private-subnets"
}

In our code we are primarily setting the name of the various resources as variables per the lab instructions.

For aws_region, we are setting the region to us-east-1. For vpc_cidr, we set the VPC CIDR block. We also set the list of IP for the it_admin_ips security group as mentioned by the lab specifications. Lastly, the rest of the variable names correspond to the names that the lab requires us to have for our resources.

Now, we will being writing our main.tf file and creating the resource blocks.

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "cybr-lab"
  }
}

We begin with creating our VPC resource block giving it the name 'main'. We set the CIDR block configuration to utilize the variable we set in variables.tf to define the CIDR range of the VPC for our lab. The DNS settings are to enable DNS resolution as well as allowing public DNS hostnames. Lastly, we tag the resource to allow for tracking and identifying the resource.

Our next resource we will build is the Webserver Security Group. Let's have a look at what this resource block will look like.

resource "aws_security_group" "web_servers" {
  name        = var.web_sg_name
  description = "Allow HTTP and HTTPs from anywhere (IPv4 and IPv6)"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port         = 80
    to_port           = 80
    protocol          = "tcp"
    ipv6_cidr_blocks  = ["::/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port         = 443
    to_port           = 443
    protocol          = "tcp"
    ipv6_cidr_blocks  = ["::/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Name = var.web_sg_name
  }
}

Looking at our resource, we'll start from the top. In the first part, we are assigning the name of the Web Server security group from our variables file which we created earlier. We add a helpful description and associate the security group with the previously created VPC.

The next two blocks we add ingress on port 80 (HTTP) for IPv4 and IPv6 from any address. We do the same for port 443 (HTTPS) in the next two blocks.

Now we have 2 egress blocks which technically are not required as security groups are stateful. So why would we add these blocks? We are adding them for two reasons:

We need to allow IPv6 egress (::/0), which the default rule does not include.
We want to document explicitly for clarity or to prepare for future restrictions.

Note: the -1 for protocol refers to all protocols/network traffic.

Lastly, we tag our resource for identification and tracking purposes.

Let's now build the web app security group.

resource "aws_security_group" "app_servers" {
  name        = var.app_sg_name
  description = "Allow traffic from web servers"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 0
    to_port         = 65535
    protocol        = "tcp"
    security_groups = [aws_security_group.web_servers.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = var.app_sg_name
  }
}

We start by assigning the name for the resource from our variables file. We also associate the resource with our VPC.

In the ingress block we allow the TCP protocol and the associated ports [0 - 65535]. We also reference the web server security group as we want to allow access from the web servers per the lab requirements. For the egress block we allow all outbound access.

Finally we tag the resource for tracking and identification.

Moving on to the next resource, we build our IT administration security group.

resource "aws_security_group" "it_admin" {
  name        = var.it_sg_name
  description = "Allow SSH and RDP from IT admin IPs"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = var.it_admin_ips
  }

  ingress {
    from_port   = 3389
    to_port     = 3389
    protocol    = "tcp"
    cidr_blocks = var.it_admin_ips
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = var.it_sg_name
  }
}

Similar to out other resources we have created thus far, we assign the name from the relevant variable block in our variables.tf file and associate it with our VPC.

We create the ingress blocks for both port 22 (SSH) and port 33389 (RDP). For the CIDR blocks we reference the allowable IPs [172.16.0.0, 192.168.0.0] from the lab specs using variables we have set in variables.tf.

Again, we add an egress block for this resource as explained earlier.

As usual we tag our resource at the end.

Now, we create the Database security group.

resource "aws_security_group" "database" {
  name        = var.db_sg_name
  description = "Allow MySQL access from app servers"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.app_servers.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = var.db_sg_name
  }
}

We set the name as usual and associate it with our VPC. Our ingress limits access to the resources having the app servers security group via port 3306 (MySQL).

Similar to our other resources, we have our egress and tags blocks.

Next we are going to create our public NACL and the associated rules. Keep in mind since NACL are stateless, we need matching rules for inbound and outbound traffic. We also space the rule numbers 10 apart as to allow room to add further rules in the future if needed.

resource "aws_network_acl" "public" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = var.public_nacl_name
  }
}

In this block, we create the NACL, associate it with out VPC, and tag it with the relevant variable name.

Now we set up the public ingress rules.

resource "aws_network_acl_rule" "public_ingress" {
  network_acl_id = aws_network_acl.public.id
  rule_number    = 100
  egress         = false
  protocol       = "-1"
  rule_action    = "allow"
  cidr_block     = "0.0.0.0/0"
  from_port      = 0
  to_port        = 0
}

We set up our IPv4 ingress by associating it with our public NACL and allowing all inbound traffic and assign it a rule number.

resource "aws_network_acl_rule" "public_ingress_ipv6" {
  network_acl_id = aws_network_acl.public.id
  rule_number    = 110
  egress         = false
  protocol       = "-1"
  rule_action    = "allow"
  cidr_block     = "::/0"
  from_port      = 0
  to_port        = 0
}

We do the same for IPv6. Note the the egress = false means that these are for ingress rules.

Since NACLs are stateless we have to have matching egress rules. Similar to how we set up the ingress rules we do the following.

resource "aws_network_acl_rule" "public_egress" {
  network_acl_id = aws_network_acl.public.id
  rule_number    = 120
  egress         = true
  protocol       = "-1"
  rule_action    = "allow"
  cidr_block     = "0.0.0.0/0"
  from_port      = 0
  to_port        = 0
}

For IPv4 egress.

resource "aws_network_acl_rule" "public_egress_ipv6" {
  network_acl_id = aws_network_acl.public.id
  rule_number    = 130
  egress         = true
  protocol       = "-1"
  rule_action    = "allow"
  ipv6_cidr_block = "::/0"
  from_port      = 0
  to_port        = 0
}

For IPv6 egress.

If you're following along, you note that the lab requires a private NACL as well. We are doing to do this very similar to what we did for the public NACL with the obvious exceptions for creating a private NACL and having the rules we create associated with that.

resource "aws_network_acl" "private" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = var.private_nacl_name
  }
}

resource "aws_network_acl_rule" "private_ingress" {
  network_acl_id = aws_network_acl.private.id
  rule_number    = 100
  egress         = false
  protocol       = "-1"
  rule_action    = "allow"
  cidr_block     = "0.0.0.0/0"
  from_port      = 0
  to_port        = 0
}

resource "aws_network_acl_rule" "private_egress_ipv6" {
  network_acl_id = aws_network_acl.private.id
  rule_number    = 100
  egress         = false
  protocol       = "-1"
  rule_action    = "allow"
  cidr_block     = "0.0.0.0/0"
  from_port      = 0
  to_port        = 0
}

That's it. That is our main.tf file. We are now ready to create our outputs.tf file. For this file are are simply outputting the ID of each resource for our reference.

The file will be set up like this.

output "vpc_id" {
  value = aws_vpc.main.id
}

output "web_sg_id" {
  value = aws_security_group.web_servers.id
}

output "app_sg_id" {
  value = aws_security_group.app_servers.id
}

output "it_admin_sg_id" {
  value = aws_security_group.it_admin.id
}

output "database_sg_id" {
  value = aws_security_group.database.id
}

output "public_nacl_id" {
  value = aws_network_acl.public.id
}

output "private_nacl_id" {
  value = aws_network_acl.private.id
}

We have all the files we need. We run a terraform fmt -recursive to format our code properly. Next we run a terraform init to initialize our providers, followed by a terraform validate to ensure there are no errors.

Let's run a terraform plan. Review the resources that will be created. If you are satisfied feel free to run terraform apply -auto-approve to build our resources.

Congratulations, we have successfully completed the lab. Although these resources will cost us no money (at least at the time of this write-up), you may want to run a terraform destroy to remove them at some point to clean up the resources.

You can find the complete files here:

Cybr - Introduction to AWS Security

Kuljot Biring — Mon, 07 Jul 2025 03:00:48 +0000

I recently finished the Introduction to AWS Security course by Cybr. The course is part of the platform's Blue Team Learning Path

This was a great course that offers great content highlighting the key features of security in AWS.

The course has over 100 lessons covering the following topics:

🚧 Infrastructure Security
👤 Identity and Access Management (IAM)
⛁ Data Protection
🪣 Amazon S3 Bucket Protection
🕵🏼‍♂️ Logging, Monitoring, and Incident Response
👥 Multi-Account Security
</> Infrastructure as Code (IaC)

The course contains several labs, graphical cheat sheets with detail explanations, sandbox author-hosted labs and demo videos giving details walk-throughs of services and implementations. There is a good blend of theory and practical/hands on material. If that's not all, you get nearly six credit hours for completing the course!

Since this is introduction course, the author is careful to give sufficient but not overly detailed information via concise digestible videos covering the important aspects.

Overall, this is course packs in some great information and the author's teaching style is solid. As a security engineer holding several AWS certifications, this course is a great buy. I would highly recommend you to give it a go.

Cybr - [LAB] [Challenge] Create a VPC with public and private subnets

Kuljot Biring — Thu, 19 Jun 2025 21:02:21 +0000

Today, we are going to tackle the lab Cybr - [LAB] [Challenge] Create a VPC with public and private subnets

However, there's a slight twist! We are going to do the lab using Terraform. Why? Because clicking around in a console is great when you initially learning, but not realistic when you are working in more professional environment. Therefore, we are going to use IAC via Terraform in order to complete the lab.

Before we get started, this walk-through assumes you know how to set up Terraform and have a very basic understanding of it.

Let's get started.

The lab gives the following prompt:

Lab Details 👨‍🔬
Length of time: 20 minutes

Difficulty: Easy

We did something very similar in the demo lesson titled “Creating VPCs and Subnets” but I want you to try and complete this scenario as much as possible without looking back at that lesson. Of course, if you’re stuck and you can’t find answers by searching online, I do recommend using the course lesson material to break through. Pretend like you’ve been asked to do this on the job and troubleshoot to the best of your ability. That will help you build practical skills.

Scenario 🧪
Create a VPC named cybr-vpc-lab that contains 2 public subnets and 2 private subnets. Each of the public subnets should reside in different availability zones, with a private subnet in each of those zones as well.
Use a CIDR block of /16 for the VPC and CIDRs of /24 for the subnets.
Create an S3 Gateway VPC Endpoint that is connected to both of the private subnets.
While you can use the “VPC and more” option to automate a lot of this, I challenge you to manually create these resources instead to really apply what you’ve learned so far.

Tips:

Remember what makes a public subnet versus a private one
Before you launch a resource, it’s a great idea to verify its pricing first. For example, you should not be launching a NAT Gateway if you want to keep the cost at $0.00 since NAT Gateways cost money — all resources needed for this lab don’t cost anything so that’s a hint you don’t need a NAT Gateway

Before we start coding, keep in mind we want our code to be modularized and follow DRY principles. We are going to create a few files which will look like the directory structure below:

cybr-vpc-lab/
├── main.tf             
├── variables.tf       
├── outputs.tf         
└── terraform.tf

Let' start by creating a terraform.tf file. This file is going to contain our Terraform provider and version restrictions.

Providing versions is a good practice when writing Terraform as it prevents breaking changes from occurring due to compatibility and stability when using different features and versions.

terraform {
  required_version = ">= 1.3.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

In this file we are ensuring that the Terraform version is at least 1.3.0 or greater.

We are also sourcing the AWS provider from HashiCorp and requiring it to be version 5.0 or greater.

Lastly, we are configuring the provider to use the AWS Region specified in the variables file (which we will create next).

Now that we have our providers taken care of, we are going to create variables.tf. This file will house all of our input variables we will use throughout our code.

Our first variable block will be for the AWS Region we are going to deploy our infrastructure into. Typically, we like to use us-east-1 for this.

variable "aws_region" {
  description = "The AWS region to deploy resources"
  type        = string
  default     = "us-east-1"
}

Next, we were told that our VPC should be created with a CIDR block of /16. So let's create a variable for that VPC accordingly:

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  type        = string
  default     = "10.0.0.0/16"
}

We are also to create 2 public subnets in different Availability Zones as well as 2 private subnets in two different availability zones. Both are expected to have /24 CIDRS. We create variables for these as follows:

variable "public_subnet_cidrs" {
  description = "CIDR blocks for public subnets"
  type        = list(string)
  default     = ["10.0.1.0/24", "10.0.2.0/24"]
}

variable "private_subnet_cidrs" {
  description = "CIDR blocks for private subnets"
  type        = list(string)
  default     = ["10.0.101.0/24", "10.0.102.0/24"]
}

Note that the default value for both public and private subnet are created using a list of strings.

At this point we are ready to start creating the resource blocks to build the infrastructure required.

Let's write out main.tf file.

As a quick background, resource blocks in Terraform are generally configured as follows:

resource "<PROVIDER>_<RESOURCE_TYPE>" "<RESOURCE_NAME>" {
  argument = some_value

  tags = {
    Name = "some_name"
    Environment = "some_environment"
  }
}

We have the block labelled as a resource type letting Terraform know we are creating a resource.

Next, the provider and resource type signify which provider we are using and what type of resource to create.

This is followed by the managed resource name which is how we can refer to the resource with our configuration.

Within the body of the block we have required arguments, as well as optional tags which help us identify and manage resources.

We begin by first creating the resource block for our VPC.

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "cybr-vpc-labs"
  }
}

Notice that our resource type is aws_vpc indicating to Terraform what type of resource we want to build.

We have the managed resource name of main.

We also have the cidr_block value set to the value of the variable var.vpc_cidr which is being referenced from our variable named vpc_cidr in the variables.tf file.

Both enable_dns_support and enable_dns_hostnames are set to true.

Lastly, we tag our resource with the value cybr-vpc-labs.

Next, we want to ensure that our subnets are spread across multiple Availability Zones (AZs) in the selected region, we use a data source to dynamically fetch the available zones.

data "aws_availability_zones" "available" {}

Now, we create the Internet Gateway which would let resources in our VPC reach the public internet.

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "cybr-igw"
  }
}

Now we will create the public subnets like so:

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "cybr-public-subnet-${count.index + 1}"
  }
}

Looking at our code, we can see we set count to 2 - meaning that two subnets will be created. the vpc_id is set to the ID of our main VPC.

You can also note that the cidr_block variable is assigned from the public_subnet_cidrs variable using the current index from count to select the appropriate CIDR block for each subnet.

The availability_zone is determined from the available zones in the region (us-east-1) that we selected, using the current index to assign each subnet to a different zone.

Furthermore, we can see that map_public_ip_on_launch is set to true which would allow any instances that are launched in this subnet to receive public IP addresses.

We use the aws_availability_zones data source to dynamically fetch available AZs in our selected region.

Lastly, each subnet is tagged with a name utilizing its index: cybr-public-subnet-1 and cybr-public-subnet-2

Now that we have code for our public subnets we need to create public route tables for these subnets. We want to associate the route table to our VPC using vpc_id = aws_vpc.main.id. Next, we create the route definition that directs all output traffic to our internet gateway that we specified earlier using aws_internet_gateway.gw.id. This will enable internet access for resources using this route table. Lastly, we add a tag to more easily track and manage the resource. Here is what our resource block would look like:

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.gw.id
  }

  tags = {
    Name = "cybr-public-rt"
  }
}

Great, we have created our route tables and now we just need to associate our public subnets with our public route table. We do this by using aws_route_table_association as the resource type. We also set the count parameter to 2 so that two associations are created. The subnet_id is set to the ID of the public subnets defined earlier using aws_subnet.public[count.index].id which allows us to reference each subnet based on the current index. Finally, we link to the public route table. Our resource block will be as follows:

resource "aws_route_table_association" "public" {
  count          = 2
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

Now that we have coded our public subnets, public route table, and associated them, we need to do the same for the private subnets.

Let's begin by first creating the private subnets which is going to be very similar to how we created the public subnets except we will not have a public IP that can be associated with resources in the private subnets:

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "cybr-private-subnet-${count.index + 1}"
  }
}

Similar to before, we will now create the route table for our private subnets. The key difference here will be that the route table will be used to direct traffic to the S3 endpoint:

resource "aws_route_table" "private" {
  count  = 2
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "cybr-private-rt-${count.index + 1}"
  }
}

The next step is to now associate these private subnets with the private route table we just created:

resource "aws_route_table_association" "private" {
  count          = 2
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private[count.index].id
}

Our last resource block will be creating the S3 Gateway Endpoint which will allow resources in our private subnets to connect to resources in S3 without traversing the internet. We will need to do the following; indicate the appropriate resource type, set the VPC id to that of the main VPC, dynamically construct the service name to reference the S3 service in the region we have chosen, specify the endpoint type, associate the resource with the correct route table, and finally, tag our resource for identification. The configuration will look something like this:

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.aws_region}.s3"
  vpc_endpoint_type = "Gateway"

  route_table_ids = [for rt in aws_route_table.private : rt.id]

  tags = {
    Name = "cybr-s3-endpoint"
  }
}

Note that for our route table association, we are using list comprehension to gather the private route tables via their IDs from aws_route_table_private.

For the final stretch of this lab we are going to create an outputs.tf file. The purpose of this file is to define several output values for our Terraform configuration which can be useful for retrieving information about the resources that were created.

We are going to create outputs for; the VPC ID, public subnet IDs, private subnet IDs, and the S3 VPC Endpoint ID. The code will look like this:

output "vpc_id" {
  description = "The ID of the VPC"
  value       = aws_vpc.main.id
}

output "public_subnet_ids" {
  description = "IDs of the public subnets"
  value       = [for subnet in aws_subnet.public : subnet.id]
}

output "private_subnet_ids" {
  description = "IDs of the private subnets"
  value       = [for subnet in aws_subnet.private : subnet.id]
}

output "s3_vpc_endpoint_id" {
  description = "ID of the S3 Gateway VPC Endpoint"
  value       = aws_vpc_endpoint.s3.id
}

Now that we have written all our code we should format out code properly. Let's use a terraform fmt -recursive to make our code more readable.

We also need to initialize our modules with the command: terraform init.

Next, validate the syntax using terraform validate.

We can do a dry run of our code and infrastructure changes using terraform plan.

If we are satisfied with the resources that will be created and how everything looks, we can deploy the resources using terraform apply -auto-approve.

Although the resources we have created should not incur any charges, we are going to remove them using the command terraform destroy and confirm our choice once we ascertain that we are destroying all the resources we have created.

Recap:

We have created the following resources:

Resource Type	Count	Description
VPC	1	Main container for networking
Public Subnets	2	Spread across AZs
Private Subnets	2	Spread across AZs
Route Tables	3	1 public, 2 private
Subnet Associations	4	2 public, 2 private
S3 VPC Endpoint	1	Connects private subnets to S3
Outputs	4	VPC ID, subnet IDs, endpoint ID

We are using Terraform vs clicking around in the console to create these resources since using Terraform to manage infrastructure allows for repeatability and automation. With Terraform, we can define our infrastructure as code, making it easy to version, share, and reproduce environments consistently, while manual configurations can lead to errors and inconsistencies.

For the complete version of all the files, see the links list below:

Hashicorp: Terraform Associate

Kuljot Biring — Wed, 18 Jun 2025 00:17:51 +0000

I have recently passed the Hashicorp Terraform Associate Exam. To help prepare for this exam, I supplemented my existing knowledge base with fantastic course from HashiCorp Certified: Terraform Associate - Hands-On Labs by: Bryan Krausen.

The course has dozens of labs that help re-enforce the concepts and are a practical way to get experience and knowledge with Terraform.

As for the exam itself, I was able to breeze through it with plenty of time to spare.

The exam tests for:

Infrastructure as code core concepts
Terraform workflow (Write, Plan, Apply)
State management techniques
Module usage and development
Terraform Cloud and Enterprise features

At the end of the exam, I received the passing screen. Two days later I received my Credly badge and certification.

I am continuing to use Terraform on all my AWS projects to further sharpen my skills.

AWS Solutions Architect Associate

Kuljot Biring — Mon, 26 May 2025 17:52:19 +0000

Last April (2024), I passed the AWS Solutions Architect Associate Exam. I took this exam to validate my AWS knowledge as I dive deeper into the cloud focusing on building and designing:

🔒 Secure Architectures
💪 Resilient Architectures
🚀 High-Performing Architectures
💰 Cost-Optimized Architectures

How to Pass AWS Certifications

Kuljot Biring — Tue, 13 May 2025 05:57:01 +0000

I want to talk about the strategy I used to pass four AWS certifications on the first attempt and what I would recommend as a good path to do it.

Firstly, this write-up assumes you have basic computer literacy and know the basics of computing.

Course Recommendation

For using a course to learn the topics and materials, I strongly recommend Adrian Cantrill. Adrian’s courses are very detailed. He goes over the actual services and how they work, their limitations, use cases, and how they interact with other services to architect business needs.

Furthermore, the courses offered by Adrian contain ample hands-on labs that help solidify the topics you have just learned. Additionally, there is often “exam power-ups” mentioned in the course which are key items to pay attention to when giving consideration to how to answer exam questions.

Lastly, almost every section contains short quizzes to re-enforce learning. There is also a section at the end of each course which goes over exam strategy, how to approach exams questions, as well as some practice exams.

The courses are very thorough! I would strong advise taking notes as it is a lot of material and writing notes will help you recall a good portion of the content.

There are are other courses which may be shorter and more exam only focused, however if you goal is to not only pass the exam but understand AWS, then Adrian’s courses will give you both.

Practical/Hands on Labs
Some of the best preparation you can do for getting ready to take the exams are hands on labs. There are many platforms offering author hosted or self-hosted lab. Additionally, there are several resources available from AWS themselves including the Well-Architected Labs and more recently the AWS Security Champion - Knowledge Badge Readiness Path

Practice Exam Recommendation
Studying for the AWS certifications is not complete with a study course alone. You need to find some good practice exams. Enter Tutorials Dojo. Aside from the AWS Official Practice Exams, Tutorials Dojo gives the best simulation to what exams might be like.

Tutorials Dojo contains several sets of practice exams usually broken up as follows:

Section based exams (x4)
Review Mode exams (x4)
Timed Exams (x4)
Final Exam (x1)

I recommend doing two iterations of the exams in the order listed above. After you take an exam, you are given a chance to review the results. Use this opportunity to re-read the questions along with the right and wrong answers. Tutorials Dojo does an excellent job of explaining why the right answer is correct and why the wrong answers are wrong. Really try to understand the reasons behind these and don’t rely on memorization.

White Papers

AWS White Papers contain a lot of good knowledge and should not be ignored.

AWS FAQs

AWS FAQS are a really great resource for getting quick officials answers that you may have regarding AWS services.

Taking the exam
AWS exams can be challenging due to their lenght and complexity. I’ve always chosen to take them in person so I would not run into technical issues. If you’ve gone through the above preparation, you should confidently pass the exams. Good luck!

AWS Security Specialty

Kuljot Biring — Sat, 19 Apr 2025 20:10:41 +0000

I have recently passed the Amazon Web Services (AWS) Security Specialty Exam. I took this exam to show mastery of AWS in the following competencies:

👮‍♂️ Threat Detection and Incident Response.
📝 Security Logging and Monitoring.
🚧 Infrastructure Security.
🪪 Identity and Access Management.
🗄️ Data Protection.
🚦 Management and Security Governance.

I'm looking to continue to grow my knowledge and expertise in the cloud and security space.

AWS Solutions Architect Professional

Kuljot Biring — Sun, 14 Jul 2024 21:52:06 +0000

I have recently passed the Amazon Web Services (AWS) Solution Architect Professional Exam. I took this exam to show mastery of AWS in the following competencies:

🏢 Design for organizational complexity.
💡 Design for new solutions.
🛠️ Continuously improve existing solutions.
🚀 Accelerate workload migration and modernization.

I'm looking to continue to grow my knowledge and expertise in the cloud and security space.

AWS Solutions Architect Associate

Kuljot Biring — Mon, 01 Apr 2024 19:52:16 +0000

I've passed the Amazon Web Services (AWS) Solution Architect Associate Exam. I took this exam to validate my AWS knowledge as I dive deeper into the cloud and building/designing:

🔒 Secure Architectures
💪 Resilient Architectures
🚀 High-Performing Architectures
💰 Cost-Optimized Architectures

I am planning to do a lot of awesome things within the cloud security space!