Looking at what we are Building

So now that you have a basic understanding of how Terraform works , before you start running any terraform command against a real AWS account, two things need to happen: you need an identity Terraform can authenticate as, and you need a mental picture of what you're about to create, so the plan output in Part 4 isn't just a list of unfamiliar resource names. Never Use Your AWS Root User! The root user (the email/password you signed up to AWS with) can do anything , including closing the account. It should basically never be used day-to-day. Instead, create a dedicated IAM user just for this project. In real life you would create a dedicated IAM user for your CI/CD pipeline to automate deployments: AWS Console → IAM → Users → Create user (e.g. terraform-voting-app ). Do not enable AWS Console access, this user only needs programmatic access, i.e. an API key pair. The AWS managed policy AdministratorAccess is the path of least friction, and is what you should use for the IAM user to test things out. but in real life you would go with least privilege approach, learn more about it in AWS EKS IAM policy examples . On the user's Security credentials tab → Create access key → choose "Command Line Interface (CLI)". You'll get an Access Key ID and a Secret Access Key , store them somewhere safe, we will be needing them later. Give Terraform those Credentials The rule: credentials never go inside a .tf file, and never inside terraform.tfvars . So in your local machine or CI/CD pipeline you need to export AWS_ACCESS_KEY_ID , AWS_SECRET_ACCESS_KEY , and AWS_REGION as environment variables in the shell. Then you won't be needing aws configure or aws login step anywhere, the aws provider has no access_key / secret_key arguments of its own, so it falls back to the AWS SDK's standard credential chain, which checks these exact environment variables first. The AWS CLI and, later kubectl read the same variables. In my local machine I do export an env variable files using a shell scrip