Forem: Ijay

You passed AWS... But Companies Still Won't Hire You

Ijay — Fri, 01 May 2026 09:00:00 +0000

Upon passing certification, no job. That's why I created this video, "The Pain Behind the Smile," and besides, this question is getting much attention.
I kept seeing the same thing everywhere. People
passing their AWS exam and still not getting a
single interview. So I looked into it properly.
Here is what I found.
If this video helped you, feel free to leave a comment here and engage on my channel. I read and learn from your feedback.

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you. ❤️

You Don’t Need Kubernetes to Get an AWS Job (My Real Experience)

Ijay — Tue, 28 Apr 2026 09:00:00 +0000

Many people believe you need Kubernetes to get an AWS job, but that isn’t true for most beginners.

In this video, I share my real experience learning AWS and explain why Kubernetes is often pushed too early. I break down what AWS roles actually expect at the beginner and junior level, what skills matter more than buzzwords, and when Kubernetes really becomes useful.

If you are learning AWS and feel overwhelmed by advice telling you to learn everything at once, this video will help you focus on the fundamentals that actually move you forward.

This is for AWS beginners, cloud learners, and anyone trying to understand what really matters when preparing for an AWS job.

If this video helped you, feel free to leave a comment here and engage on my channel. I read and learn from your feedback.

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you. ❤️

What is an Availability Zone?

Ijay — Fri, 24 Apr 2026 09:00:00 +0000

Availability Zones are one of the most important concepts in AWS, but they are often confusing for beginners. In this video, I explain what an Availability Zone is using simple language and real-life examples, so you can understand how AWS designs reliable and highly available systems.

This video is for anyone learning AWS, cloud computing, or DevOps who wants clarity without heavy technical jargon.

In this video, you will learn:

What an Availability Zone really is
How Availability Zones are different from Regions
Why AWS uses multiple Availability Zones
How Availability Zones improve reliability and uptime
Common beginner misunderstandings about Availability Zones

Once this concept clicks, many other AWS topics start making sense.

If this video helped you, feel free to leave a comment here and engage on my channel. I read and learn from your feedback.

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you. ❤️

Will AI Replace Cloud Engineers in 2026?

Ijay — Tue, 21 Apr 2026 09:00:00 +0000

We are in the AI era. I made this video just to voice my opinion and take points on AI. I use AI , but it can't replace me. So what's your take on AI?

If this video helped you, feel free to leave a comment here and engage on my channel. I read and learn from your feedback.

Thank you. ❤️

3 Ways to Configure Resources in Terraform

Ijay — Fri, 17 Apr 2026 09:00:00 +0000

Infrastructure as Code has changed how engineers manage cloud infrastructure. Instead of manually creating resources in the cloud console, we can define everything in code and let tools handle the provisioning.

Terraform is one of the most popular tools for this purpose.

When working with Terraform, you often need to define values for your resources. For example, you may want to specify the following:

The instance type of a server
The region where resources will be deployed
The name of a resource
Tags used for identification

Terraform allows you to configure these values in different ways. Choosing the right approach helps make your infrastructure easier to manage, reuse, and maintain.

In this article, you will learn three common ways to configure resource values in Terraform:

Using variables
Using locals
Using auto.tfvars files

By the end of this guide, you will understand when to use each method and how they help improve your Terraform configuration.

Prerequisites

Before reading along, make sure you have the following:

Basic understanding of any cloud provider infrastructure.
Terraform is installed on your machine.

You can verify that Terraform is installed by running the following command in your terminal:

terraform version

If Terraform is installed correctly, you should see the version number above displayed.

Understanding Resource Configuration in Terraform

In Terraform, infrastructure is defined using resources.

A resource represents a cloud component such as a virtual machine, storage bucket, database, or load balancer.

Here is a simple example of a Terraform resource that creates an AWS EC2 instance:

resource "aws_instance" "example" {
  ami           = "ami-0xxxxxxxxxxxxxxx0"
  instance_type = "t2.micro"
}

In this configuration, the values for ami and instance_type are written directly inside the resource block.

This works for simple cases, but it can become difficult to manage when your infrastructure grows. Hardcoding values makes configurations less flexible and harder to reuse.

Terraform provides several ways to make these values more dynamic and easier to manage.

How Do We Add Dynamic Values in Terraform?

When writing Terraform configurations, you may sometimes need values that can change. For example, the instance type of a server may be different in development and production environments.

If you write these values directly inside your resource blocks, your configuration becomes harder to reuse and maintain. Instead, Terraform allows you to define values outside the resource and reference them when needed.

Method 1: Using Variables

Variables allow you to define values outside of your resource blocks. This makes your Terraform configuration more flexible and easier to reuse.

Instead of hardcoding values inside a resource, you define the value once and reference it wherever it is needed.

Step 1: Define the variable.

First, define a variable. This is usually done in a file called variables.tf

variable "instance_type" {
  description = "The EC2 instance type"
  type        = string
  default     = "t2.micro"
}

Above, we created a variable called instance_type.

This variable stores the value Terraform uses when creating the EC2 instance.

The default value is set to t2.micro, but this value can be changed later if needed.

Step 2: Next is to use the variable to create a resource.

After defining the variable, you can reference it inside your resource configuration.

resource "aws_instance" "example" {
  ami           = "ami-0xxxxxxxxxxxxxxx0"
  instance_type = var.instance_type
}

So with this declaration Terraform does not use a hardcoded value for the instance type. Instead, it reads the value from the variable we defined earlier.

The prefix var. tells Terraform that the value is coming from a variable.

When Terraform runs, it will use the value stored in instance_type to configure the resource.

Why do you think variables are useful?

As mentioned earlier, hardcoding values can make your infrastructure difficult to manage, especially as your system grows or needs to scale.

Terraform variables help solve this problem by separating configuration values from the resource definitions.

Variables are useful in several situations.

When you want to reuse the same configuration in different environments

For example, you might use a small instance type in a development environment and a larger one in production. With variables, you can keep the same configuration and only change the value.

When you want to change values without modifying the resource block

Instead of editing the resource every time a value changes, you simply update the variable. This keeps your configuration cleaner and easier to maintain.

When you want to make your Terraform configuration easier for other engineers to use

Variables make it clear which values can be adjusted. This allows other engineers to work with the configuration without needing to modify the core infrastructure code.

Method 2: Using Locals

Terraform locals allow you to store values or expressions that are used multiple times in your configuration.

Locals are helpful when you want to simplify repeated values or calculations.

How do I use Local?

Step 1: Define the Local Values

Create a locals block in your Terraform configuration.

locals {
  instance_name = "example-server"
  instance_type = "t2.micro"
}

The code block defines local values called instance_name and instance_type of the configuration.

Next, you define the local values inside the resource configuration

Step 2: Using Locals in a Resource

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = local.instance_type

  tags = {
    Name = local.instance_name
  }
}

The resource configuration uses the value stored in instance_name and in instance_type above to create a resource

Why are Locals Useful in Terraform Declarations?

Locals are useful when you want to avoid repeating the same values in multiple places.
Locals can be used to simplify complex expressions.
The keyword "local" can be used to organize your configuration more clearly.

Method 3: Using auto.tfvars Files

A tfvars file is used to store values for Terraform variables. Instead of typing values in the command line or writing them directly in your configuration, you can place them inside a separate file.

Terraform has a special type of file called ".auto.tfvars."

When Terraform sees a file with this name, it automatically loads the values inside it. This means you do not need to manually pass the file when running Terraform commands.

How is it declared?

Step 1: Define the variable

First, define the variable in your Terraform configuration.

For example, in variable. tffile:

variable "instance_ec2" {
  description = "EC2 instance type"
  type        = string

 tags = {
    Create_By = var.created_by
  }
}

Here, we created a variable called instance_ec2

Step 2: Create the auto.tfvars File

Next, create another file called, let's say, ec2.auto.tfvars

Inside this file, assign a value to the variable.

instance_type = "t3.micro"
created_by    = "dev"

Why Should You Create a auto.tfvars File?

The file helps keep your Terraform configuration clean by separating variable values from the main infrastructure code.

Instead of placing all values directly inside your Terraform files, you can store them in an auto.tfvars file and let Terraform load them automatically.

auto.tfvars Files are useful when:

To keep configuration values separate from your Terraform code
i.e., your resource definitions stay focused on infrastructure, while the variable values are stored in a separate file.
To manage different environment settings
For example, a development environment might use smaller resources, while production may require larger ones.
To allow Terraform to automatically load variable values
Terraform reads .auto.tfvars files automatically when you run commands like terraform plan or terraform apply, so you do not need to pass the file manually.

Because of the benefit of an auto.tfvars file, many teams use tfvars files to manage values for different environments, such as

development
staging
production

When Should You Use Each Method in Resource Configuration?

Variables are best when you want flexibility and reusable configurations.
Locals are useful for simplifying repeated values inside your Terraform code.
auto.tfvars files help supply variable values automatically without modifying the configuration.

In practice, most Terraform projects use a combination of these approaches.

Conclusion

Terraform provides several ways to configure values for your resources. Choosing the right approach can make your infrastructure easier to manage and maintain.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

Some cloud concepts like regions and availability zones can be explained simply. Do you think someone without a technical background can get AWS fundamentals? Watch and share your thoughts: https://www.youtube.com/watch?v=UaNqs93P38Q&t=8s #aws #cloud

Ijay — Wed, 15 Apr 2026 13:25:21 +0000

youtube.com

How I Escaped Tutorial Hell

Ijay — Wed, 15 Apr 2026 09:00:00 +0000

What watching tutorials taught me and why building changed everything.

Almost everyone who is learning something new experiences tutorial hell at some point.

You watch videos, read guides, and follow along step by step. Everything seems clear while you are watching.

But when it is time to try things on your own, you suddenly feel stuck.

In this edition, I want to share my experience and how I eventually broke out of that cycle.

Time flies.

I still remember when I first started learning to code.

I spent hours watching tutorials. React tutorials. JavaScript tutorials. Anything I could find on YouTube.

If you asked me what I was doing, I would confidently say I was learning.

I was always busy.

Busy watching another tutorial.

Busy taking notes.

Busy trying to become a good software engineer.

But there was one problem.

I was watching a lot.

I was not building much.

But whenever I tried to build something on my own, I froze.

Following along in a tutorial felt easy. I could understand what the instructor was doing, and everything looked clear.

But when the tutorial ended, and I was left with a blank editor, I did not know where to start.

That was when I realized something.

I was not actually building.

I was stuck in what many developers call tutorial hell.

Everything makes sense while the instructor is explaining it.

But the moment the tutorial ends and you try to build something on your own, the confidence disappears.

That was exactly what happened to me when I was learning React.

I had watched many tutorials, but I still did not know how to start a simple application from scratch.

That was when I realised something needed to change.

It took time, but eventually I broke out of that cycle.

The thing that helped me was simple.

I stopped focusing on watching and started focusing on building.

Now, when I want to learn something new, I approach it differently.

Instead of opening YouTube first, I start with a small idea.

It could be a simple tool. It could be a small project.

Then I try to build it.

Most of the time, I get stuck. That is normal.

When that happens, I search for solutions, read documentation, debug with AI, or even just take a rest.

But the important thing is this.

I am still the one building it.

And that changes everything.

When you build something yourself, you begin to understand the real challenges developers face. You start seeing how different parts connect. Your confidence grows because you solved the problem yourself.

Tutorials are useful. They introduce you to new tools and concepts.

But tutorials alone cannot make you better.

Building can

Try this this week

Pick one small idea and build it without following a tutorial step by step.

It does not need to be perfect. It just needs to be something you built yourself.

Examples

• A simple to-do list app

• A small API

• A static website

• A small cloud project, like hosting a website on Amazon S3

If you are interested in cloud projects and you are struggling to think of ideas, that is completely normal. Some days your mind just goes blank.

When that happens, do not worry.

You can explore AWS Skill Builder. They have many hands-on projects and learning paths you can follow.

You can also check out my previous post, where I shared an AWS learning path for beginners.

You will learn more than you expect.

Build more.

Watch less.

Your confidence will grow faster than you think.

Before you go, I am curious.

Right now, which one are you doing more?

Watching tutorials or building projects?

Reply and tell me. I would love to hear your experience.

Every month, I share simple lessons from my journey learning cloud and DevOps.

If you enjoy practical stories like this, follow the newsletter for more.

You can follow my work and projects on Twitter, LinkedIn, and GitHub to stay updated on what I’m building and learning.

Thank you.

Can a Non-Technical Person Understand AWS

Ijay — Mon, 13 Apr 2026 09:00:00 +0000

This video explains Amazon Web Services in simple, everyday language, without technical pressure.

If you are not from a tech background but keep hearing about cloud computing, AWS jobs, or cloud skills, this video is for you.

In this video, I broke down what AWS actually is, why companies use it, and what you truly need to understand without becoming an engineer.

I made this video for beginners, career switchers like me, students, business owners, and anyone curious about cloud computing but overwhelmed by technical explanations.

You do not need programming experience to follow along. This is a clear explanation of AWS from a non-technical point of view.

If this video helped you, feel free to leave a comment here and engage on my channel. I read and learn from your feedback.

Thank you. ❤️

Deploying with Terraform

Ijay — Wed, 18 Mar 2026 19:27:00 +0000

The workflow design

In my previous posts, I focused on understanding Infrastructure as Code and setting up my environment. Now it is time to actually build something.

In today's challenge, we are to build our website using Terraform.

What I Built

I used Terraform to create a simple EC2 instance on AWS and made it accessible from the browser.

The setup included:

A provider block to connect to AWS
A resource block to create the EC2 instance
A security group to allow HTTP traffic on port 80
A user data script to serve a simple HTML page.

To deploy the server, I ran:

terraform init
terraform plan
terraform apply -auto-approve

Confirming the Server

After running terraform apply, Terraform returned a public IP in the AWS Console.

I copied the public IP generated and pasted it into the browser:

That confirmed that the server was running and accessible.

The challenges I faced

One issue I encountered was using an invalid AMI. At first, my instance failed to launch because the AMI was not valid for my region.

I fixed this by using a data block to dynamically fetch the correct Amazon Linux AMI.

I also had an issue where my server was not loading in the browser. This was because the web server was not properly set up. I fixed it by installing and starting Apache using the user data.

What I Learned

Doing this challenge helped me understand how Terraform actually works in practice.

Conclusion

Instead of clicking around the AWS console, I was able to define everything in code and create infrastructure in a repeatable way.

This is just the beginning, and I’m looking forward to building more as I continue this challenge.

If this resonates with you, feel free to share it with others on a similar journey.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

IAM Permissions Are Confusing

Ijay — Wed, 18 Mar 2026 09:00:00 +0000

If you’ve ever worked with AWS IAM, you've probably felt this way.

You create a policy. Attach it to a user or role. And still get an "Access Denied" error.

That happened to me more than once.

While learning AWS, I even locked myself out of my account after giving the wrong permissions to a service. Not on purpose, I simply didn’t fully understand what the policy was actually allowing.

That’s when I realised guessing my way through IAM wasn’t helping.

While trying to make sense of it, I came across the IAM Policy Simulator, and it changed how I approach permissions.

What I like about the simulator is how simple the idea is.

It lets you test what a user or role can actually do before you change anything.

Instead of wondering, you can ask one clear question:

Can this user or role perform this action on this resource? (For example: Can this EC2 role read from this S3 bucket?)

The simulator checks all attached policies and shows you the final decision. Seeing it laid out like that helped me understand exactly where things were going wrong.

How I usually access it

When I need it, I:

Sign in to AWS.
Open the IAM service.
On the right-hand side, under Tools, click Policy Simulator.
It redirects to the Policy Simulator page.

Or open the IAM Policy Simulator directly here: IAM policy simulator

From there, I test the actions I’m unsure about and see what’s allowed or denied.

Why this matters (at least for me)

Most of the permission issues I’ve run into weren’t due to anything being missing.

They were small details:

A wrong resource ARN
A condition I didn’t think about
Or an explicit deny I forgot existed

The simulator doesn’t fix things for you or replace reading policies carefully, but it clearly shows which policies are affecting or attached to the user or role, and that makes IAM much less frustrating.

What I’m taking away from this

The IAM Policy Simulator has been a safer way for me to learn permissions. It lets me experiment, understand mistakes, and avoid granting extra permissions just to “make it work.”

I’m curious: When IAM permissions don’t work as expected, how do you usually debug them? Trial and error or stopping to inspect the policy closely?

If IAM or any AWS service has ever confused you, follow the
newsletter or the YouTube channel. I share what I learn as I continue making sense of AWS.

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading!

Step-by-Step Guide to Setting Up Terraform, AWS CLI, and Your AWS Environment

Ijay — Tue, 17 Mar 2026 23:20:50 +0000

In my previous post, I talked about what Infrastructure as Code is, why it matters, and why I decided to start learning Terraform.

Now it is time to move from understanding to actually setting things up.

Before building anything, having the right environment is important. If your setup is not correct, it can slow you down later. So in this post, I will walk through how I set up my Terraform environment and connected it to AWS.

Step 1: Setting Up AWS Account

I already had an AWS account, so I didn’t need to create a new one. However, I made sure not to use my root account.

Instead, I created an IAM user with programmatic access using the AWS console and used it for my setup instead of my root account. This is more secure and is the recommended way to work with AWS.

Step 2: Installing AWS CLI

Next, I installed AWS CLI on my system.

sudo apt update
sudo apt install awscli -y

After installation, I checked that it was working by verifying the version. This confirmed that AWS CLI was installed correctly.

aws --version

Step 3: Checking the credentials
After installing AWS CLI, I configured it using my IAM user credentials.

I added:

Access key
Secret key
Default region

I did this by running aws configure and following the prompts.

To confirm everything worked, I checked my AWS identity. It returned my account details, which showed that my setup was correct.

To check

terraform version
aws --version
aws sts get-caller-identity
aws configure list

Output

Terraform v1.14.7
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v6.36.0
aws-cli/2.22.12 Python/3.12.6 Linux/6.6.87.2-microsoft-standard-WSL2 exe/x86_64.ubuntu.22
{
    "UserId": "AXXXXXXXXXXXXXXXXXXXV",
    "Account": "2xxxxxxxxxxxx4",
    "Arn": "arn:aws:iam::2xxxxxxxxxxx4:user/onyi"
}
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************5SNW shared-credentials-file
secret_key     ****************KJtJ shared-credentials-file
    region                eu-west-1      config-file    ~/.aws/config

Step 4: Installing Terraform

I installed Terraform on my system and confirmed it was working by checking the version.

During this step, I noticed that my Terraform version was outdated. I am currently fixing this by downloading the latest version from the official
Terraform website.

Step 5. Connecting Terraform to AWS

Terraform uses the AWS credentials configured through AWS CLI.

Step 6. Verifying the Setup

To make sure everything was working properly, I ran checks to confirm:

Terraform is installed
AWS CLI is installed
AWS authentication is working
AWS configuration is correct

Everything worked as expected, which means my environment is ready.

Challenges I Faced

The main issue I encountered was that my Terraform version was outdated.

I discovered this while verifying my setup and started fixing it by installing the latest version.

What I Learned

From this setup, I learned how Terraform connects to AWS through AWS CLI.

I also understood why using an IAM user is important instead of using root credentials. It improves security and gives better control over access.

Conclusion

From everything, using the AWS CLI is more secure than clicking the AWS console.

If this resonates with you, feel free to share it with others on a similar journey.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

What is Infrastructure as Code?

Ijay — Tue, 17 Mar 2026 10:00:00 +0000

Learning cloud and DevOps is good, but in the process of learning, I’ve come to understand that Infrastructure as Code is very important.

In this article, I will cover

What Infrastructure as Code is and the problem it solves
The difference between declarative and imperative approaches
Why Terraform is worth learning
My reason for taking on this 30-day challenge

What is Infrastructure as Code (IaC)

From my reading, Infrastructure as Code means using code to manage and set up infrastructure instead of doing everything manually. It is mostly used by DevOps and cloud engineers to provision resources in the cloud.

What problem does it solve?

IaC solves a lot of issues, especially what people call click ops. Instead of going to the cloud console and clicking around, which can lead to mistakes, you define everything in code. This makes it easier to repeat the same setup and avoid errors.

What are the ways Terraform is defined?

There are two ways Terraform is defined in editors:

Declarative
Imperative

1.Declarative: means you describe what you want, and the tool figures out how to achieve it.

For example, if you want to create an S3 bucket in AWS using Terraform, you just write:

resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"
}

In the example above, you are only saying, "Create a bucket with this name.” Terraform handles how it will be created.

2.Imperative: means you define every single step to get the result.

For example, using AWS CLI:

aws s3 mb s3://my-example-bucket

Which method is commonly used by developers?

In declaring a HashiCorp Configuration Language (HCL), most developers use declarative rather than imperative because you only define what you want, and the tool handles the process. It reduces errors and makes infrastructure easier to manage.

While imperative is useful for quick tasks, it is not for long-term and scalable systems. i.e., step by step

Why do we use Terraform basically

Terraform is used for provisioning infrastructure across different cloud providers. It is not limited to one cloud like CloudFormation, so it is more flexible and widely used.

My goal for the next 30 days

My goal is to challenge myself to build using IaC and stop relying on clicking around in AWS. I want to improve my skills, become better as a DevOps and cloud engineer, and get more comfortable building real things.

If this resonates with you, feel free to share it with others on a similar journey.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading