Forem: Jha'

IAM Users vs Groups vs Roles: Explained for Data Analysts

Jha' — Sun, 08 Feb 2026 19:13:48 +0000

I Leaked My AWS Keys on GitHub. Here's What I Learned.

Early in my cloud journey, I made the mistake everyone warns you about: I hardcoded my AWS credentials into a Terraform script and pushed it to a public GitHub repo.

I caught it in under 30 minutes. A quick code review, an SNS alert, and a panicked credential rotation later, I got lucky. No unauthorized usage. No surprise bill. But that close call taught me something I should have understood from day one: why AWS has so many different ways to manage identity and access.

IAM Users. IAM Groups. IAM Roles. Policies. Instance profiles. When I first opened the AWS IAM console, it felt like overkill. Coming from Power BI, I understood permissions as a simple hierarchy: Admin, Member, Contributor, Viewer. Four roles. Done.

AWS has four pages of IAM documentation.

But here's the thing: once you understand the logic behind IAM, it clicks. And if you're coming from a data analytics background like me, you already have the mental model. You just need the translation.

Who This Is For

This post is for data analysts, BI developers, and anyone making the jump to cloud engineering who keeps hearing "just use an IAM Role" without understanding why.

If you've ever:

Confused IAM Users with IAM Roles
Hardcoded credentials because you didn't know another way
Nodded along in an interview when someone asked about least privilege
Wondered why AWS has 47 different ways to grant access

This is for you. I'll break down the core IAM concepts using analogies from Power BI, show you when to use each, and share the misconfigurations I've made so you don't have to.

The Mental Model That Made IAM Click

In Power BI, workspace permissions follow a clear hierarchy:

Power BI Role	What They Can Do
Viewer	View reports and dashboards
Contributor	Create and edit content, can't manage access
Member	All of the above, plus share content
Admin	Full control, including managing permissions

Simple. Four roles, increasing levels of access.

AWS IAM follows the same principle, but with more flexibility. Instead of fixed roles, you build permissions by combining identities (who) with policies (what they can do).

Here's the translation:

Power BI Concept	AWS IAM Equivalent
Workspace	AWS Account
User in a workspace	IAM User
Workspace role (Admin, Member, etc.)	IAM Policy attached to user
Group of users with same role	IAM User Group
Shared dataset accessed by another workspace	IAM Role (cross-account access)
Service account / app identity	IAM Role (assumed by services)

The key difference: Power BI gives you four preset roles. AWS gives you building blocks to create exactly the permissions you need. More complex, but more powerful.

IAM Users: The Individual Identity

An IAM User is a unique identity within your AWS account. One person, one user.

When you create an IAM User, that identity can:

Log into the AWS Console (with a password)
Make API calls (with access keys)
Access specific AWS resources (based on attached policies)

Key constraint: An IAM User belongs to one and only one AWS account. If you work across multiple accounts, you'll need a different approach (more on Roles later).

When to Use IAM Users

Use IAM Users when:

A human needs console access to a single AWS account
You need to track individual activity in CloudTrail
Your organization requires named accounts for compliance

Avoid IAM Users when:

An application needs AWS access (use Roles instead)
You're managing access across multiple accounts
You'd need to create dozens of users with identical permissions (use Groups)

The Power BI Parallel

Think of an IAM User like a named user in your Power BI tenant. They have their own login, their own activity history, and permissions assigned specifically to them. When they leave, you deactivate their account.

The Catch: Access Keys

IAM Users can have access keys for programmatic access. These are long-lived credentials. They don't expire unless you rotate them manually. This is where security problems start.

If you're using access keys, ask yourself: could this workload use an IAM Role instead? Nine times out of ten, yes.

IAM User Groups: Permissions at Scale

Managing permissions for one user is easy. Managing permissions for fifty users doing the same job is a nightmare. That's where Groups come in.

An IAM User Group is a collection of IAM Users. Attach policies to the group, and every user inherits those permissions. Add a new analyst? Drop them in the "DataAnalysts" group. Done.

How Groups Work

Groups don't have credentials. They're not identities. You can't log in as a group. They're purely an organization tool for managing permissions efficiently.

A user can belong to multiple groups. If Sarah is both a data analyst and a project lead, she can be in both the "DataAnalysts" and "ProjectLeads" groups. Her effective permissions are the combination of both.

When to Use IAM User Groups

Use Groups when:

Multiple users need identical permissions
You want to manage access by job function
You need to quickly onboard or offboard team members

Avoid Groups when:

You only have one or two users
Permissions are highly individualized with no overlap

The Power BI Parallel

This maps directly to Power BI workspace management. Instead of assigning "Contributor" to each analyst individually, you create a security group in Azure AD, assign that group the role, and manage membership in the group. Someone joins? Add them. Someone leaves? Remove them. Permissions stay clean.

IAM User Groups work identically. The group holds the permissions. The users inherit them.

IAM Roles: The Game Changer

If IAM Users are the first thing people learn, IAM Roles are what actually matters in production.

A Role is an identity with permissions, just like a User. But instead of belonging to one person, a Role is assumed by whoever or whatever needs it. A human can assume a Role. An EC2 instance can assume a Role. A Lambda function can assume a Role. Another AWS account can assume a Role.

The Key Difference: Temporary Credentials

When you assume a Role, AWS gives you temporary security credentials. They expire automatically. No long-lived access keys in a config file. No credentials to leak. No secrets to rotate manually.

This is why Roles are the standard for anything running in AWS. Your application doesn't store credentials. It assumes a Role, gets temporary credentials, does its work, and the credentials expire.

When to Use IAM Roles

Use Roles when:

An AWS service needs permissions (EC2, Lambda, ECS, EKS)
You're granting cross-account access
A human needs temporary elevated permissions
You want to eliminate long-lived credentials entirely

Avoid Roles when:

You need a persistent human identity for audit purposes (use a User, then have them assume Roles as needed)

That's about it. Roles are almost always the right answer for workloads.

The Power BI Parallel

This one's trickier. Power BI doesn't have a direct equivalent because it's built around persistent user identities.

The closest analogy: imagine if Power BI let you create a "Report Refresh" identity that your datasets could temporarily become when pulling data from a source system. The dataset doesn't have its own credentials. It borrows the identity, does the refresh, and the access expires.

That's what an IAM Role does for AWS services.

Instance Profiles: Roles for EC2

When an EC2 instance assumes a Role, it uses an instance profile. Think of it as the container that attaches a Role to an instance. When you launch EC2 and select an IAM Role in the console, AWS creates an instance profile behind the scenes.

You'll see "instance profile" in documentation and error messages. Just know: it's the mechanism that lets EC2 instances assume Roles.

Service-Linked Roles

Some AWS services create and manage their own Roles automatically. These are service-linked roles. You don't create them. AWS does when you enable certain features.

Example: When you set up AWS Config, AWS creates a service-linked role that gives Config permission to read your resources. You don't manage this Role. AWS does.

If you see a Role you didn't create with a name like "AWSServiceRoleForConfig," that's a service-linked role. Leave it alone.

When to Use Each: The Decision Framework

Scenario	Use This	Why
Human needs console access	IAM User	Trackable identity, password login
Multiple humans need identical permissions	IAM User Group	Manage once, inherit everywhere
Application running on EC2/Lambda/ECS	IAM Role	Temporary credentials, no keys to leak
Cross-account access	IAM Role	Trust policies define who can assume
Temporary elevated permissions	IAM Role	Time-limited, auditable
You're about to hardcode credentials	IAM Role	Stop. There's almost always a better way.

When in doubt, ask: "Can this use a Role instead?" Usually, yes.

Common Misconfigurations (Including Mine)

Hardcoded credentials in code.
I did this. Early in my cloud journey, I hardcoded AWS credentials into a Terraform script and pushed it to GitHub. I caught it in under 30 minutes through a code review and an SNS alert. I rotated the keys immediately. No damage, but I got lucky.

The fix: I moved secrets to AWS Secrets Manager and switched to IAM Roles for any service that needed AWS access. No more long-lived keys in code.

Other mistakes I see often:

Overly permissive policies. Granting "Action": "*" because it's faster than figuring out the exact permissions. This is how small misconfigurations become security incidents.
Not using Groups. Managing permissions user-by-user until onboarding and offboarding becomes a nightmare.
Long-lived access keys without rotation. If you must use access keys, rotate them. Better yet, use Roles and eliminate them entirely.

Key Takeaways

IAM Users are for humans. IAM Roles are for everything else. If an application, service, or cross-account workflow needs AWS access, use a Role. Temporary credentials beat long-lived keys every time.
Groups save your sanity. Don't manage permissions individually. Group users by function, attach policies to the group, and let inheritance do the work.
If you're about to hardcode credentials, stop. There's almost always a Role-based alternative. Secrets Manager exists for the rare cases where it doesn't.
Interview tip: When asked "What's the difference between an IAM User and an IAM Role?" the answer is: Users are persistent identities with long-lived credentials. Roles are assumed identities with temporary credentials. Roles are preferred for workloads because there are no keys to leak.

What's Next

This post is part of my "Data Analyst to Cloud Engineer" series. Next up: the $200 EKS mistake that taught me how Fargate pricing actually works.

If IAM still feels fuzzy, drop a comment. I'll answer what I can and turn common questions into future posts.

How I passed AWS DevOps Professional in under 3 months while working full-time

Jha' — Mon, 26 Jan 2026 19:52:34 +0000

The AWS DevOps Professional Is a Beast

As I took on this feat, I quickly recognized that achieving this goal would require a more strategic approach than earning my Power BI Data Analyst or AWS Solutions Architect certifications. I recommend acquiring your AWS Solutions Architect certification at a minimum before attempting this certification, as the SA certification provides a proper understanding of the AWS ecosystem.

Furthermore, the breadth of knowledge meant to be retained is vast, and the topics themselves are multifaceted. Take Domain 1: SDLC Automation (22% of the score—the bulk of the exam). It delves into Continuous Integration and Continuous Delivery (CI/CD), a double-edged sword of sorts, as one must understand the sequential actions involved in orchestrating AWS CodePipeline stages: building, testing, deploying, and load testing.

You must first learn the AWS services and their counterparts to begin building your AWS artifacts. Additionally, you must understand deployment strategies such as in-place, blue/green, and canary. That was a lot to take in, wasn't it? Well, that's just the beginning—and only the first domain. Before you know it, you're writing reproducible deployments via YAML—this is Infrastructure as Code (IaC). A key concept that every DevOps engineer must hone, as this makes the difference in the speed, accuracy, and reusability of application deployments.

Quick Context: Who I Am
Hi, I'm Jha'Mel Thorne and I'm welcoming you along my journey of landing my first full-time cloud or DevOps role.

In January 2025, I earned my AWS Solutions Architect Associate certification. But after passing, I wasn't exactly sure of my cloud destiny. I was certified but had limited experience building end-to-end solutions beyond tutorials and hands-on labs.

From March to June, I dedicated myself to filling that gap: Infrastructure as Code, CI/CD pipelines, containers, Kubernetes, Linux, and Python. Every week and a half felt like a new course in my self-paced "Data Analyst to Cloud Engineer" curriculum. By the end of June, I'd built AWS-native pipelines, 3-tier Terraform architectures, and Python-based Docker deployments.

What came next? After conversations with a few Solutions Architects and Cloud Engineers, the consensus was clear: bridge my cloud skills with the SDLC, networking, configuration management, and distributed systems. That meant pursuing the DevOps Professional certification.
Starting in July and earning my certification on October 12th, let me walk you through my exact guide to passing this exam in under 3 months.

The Strategy: Two Sessions, One Goal
Throughout my entire cloud journey, I've had to manage my 9-5 as a data analyst at a private markets firm. Some days are demanding and mentally intensive. Outside of that, include family, my relationship, and running 10Ks and half-marathons. Time is limited.

I started the course in mid-July, but I worked through the sections half-heartedly and built mini-projects until September. Work, travel, life. My DevOps cert journey started slowly. There were entire weeks I simply didn't study at all.

The course consisted of 17 hours of content. I purchased additional Tutorial Dojo practice exams and strategically allotted time to dissect course content into digestible bites, ensuring that I could articulate concepts in interviews. Each day, I'd sign into my Udemy account and start Stéphane Maarek's course at 6:30 AM, studying until 8:00 or 8:30 AM. The goal was to break my study routine into two distinct sessions.

Working Sessions
Session 1 (morning): Actual course content. I treated it like a lecture hall. Listening, taking notes, pausing where necessary, ingesting content from a passive standpoint.

Session 2 (evening): Aggressive mode. I'd operate as a true architect: drawing diagrams, connecting learnings to real-world examples, refining my expertise in the AWS console with hands-on practice from the morning session, and operating as if I'd be directly applying the day's learnings in an interview or my day-to-day role as a DevOps engineer.

In total, I'd spend about 3 to 4 hours daily for two straight weeks finishing the course. The course is 17 hours, but 1 hour of course content cannot be processed and retained in just 1 hour. It takes reflection. It takes switching tabs to dive deep into migrations, disaster recovery, CloudFormation templates vs. Terraform, or AWS Control Tower for governance and compliant multi-account environments.

Why SDLC Clicked for Me
Here's the thing. I didn't realize it at the time, but I was already living the SDLC as a data analyst. Every Power BI report I built followed the same pattern: gather requirements, design the data model, build the visuals, test with stakeholders, deploy to the workspace, and maintain it when the source data changed. That's the SDLC. The DevOps exam just formalized what I was already doing and added automation at every stage.

The Wake-Up Call: When Two Practice Exams Humbled Me
There's a science to AWS exams. I can't say I've mastered it completely, but I've found my edge. And it came from failure.

Quick backstory: I took my Solutions Architect Associate exam twice. First attempt: 60%. I took a month off, adjusted my approach, and passed on the second try. That adjustment is what carried me through the DevOps Professional exam on the first attempt. But not before two practice exams knocked me down.

The scores that shook me:
• Configuration Management and IaC: 45%
• Monitoring and Logging: 40%

I was shocked. These were the two domains in which I felt most confident. I'd done the hands-on labs. I'd aced the mini-quizzes. I could spin up CloudFormation stacks and configure CloudWatch alarms in my sleep. So what went wrong?

I wasn't playing by the rules of AWS exams.

The Shift That Saved Me
The DevOps Professional exam is 75 questions in 180 minutes. That's 2.4 minutes per question, technically. But here's the reality: questions get longer and more complex as you go deeper into the exam. By question 50, you're reading paragraph-length scenarios with four nearly identical answer choices. If you're spending 3 minutes per question early on, you're borrowing time you won't have later.

After those failed practice exams, I changed my approach:

1. First instinct, then validate
I stopped second-guessing myself. The first answer that stood out to me was usually correct, or close enough. I'd flag it, move on, and come back during review if I had time. Spending 4 minutes convincing myself to change an answer rarely improved my score.

2. Time awareness over time management
I stopped watching the clock obsessively. Instead, I built a rhythm: read the scenario, identify the actual question (it's usually in the last sentence), eliminate the obvious wrong answer, pick from the remaining three. If two answers looked identical, I'd find the one-word difference. That's where the right answer hides.

3. Simulate exam fatigue
I started taking full 75-question practice exams in one sitting, no breaks. By question 60, my brain wanted to quit. That's exactly what the real exam feels like. Training for that fatigue was as important as learning the content.

When I retook those domain-specific exams after adjusting my approach, my scores jumped to the 70s. Not perfect, but passing. And on exam day, that rhythm carried me to an 801.

The Real Cost: Under $200
Let's talk money. One thing I rarely see in certification guides is an honest cost breakdown. Here's exactly what I spent:

That exam fee deserves context. The actual cost is $300, but here's a tip most guides skip: once you pass any AWS certification, you receive a 50% discount voucher for your next exam. I used the voucher from my Solutions Architect Associate to cut my DevOps Professional fee in half. If you're planning multiple AWS certs, stack them strategically. Each pass funds the next one at half price.

What I didn't pay for:
I didn't buy AWS Skill Builder or any additional courses. Maarek's course plus Bonso's practice exams were enough. Your mileage may vary, but I'd rather put that money toward actual AWS spend for hands-on projects.

The hidden cost:
Time. Three months of 6:30 AM wake-ups, evenings spent in the console instead of on the couch, weekends where I chose practice exams over brunch. That's not a line item, but it's real.

What I'd Do Differently
Build buffer into your timeline
Two weeks before my DevOps Professional exam, I received an unexpected opportunity: an invitation to participate in a live interview prep workshop with real hiring managers. Round-table format, small group, 30 minutes of behavioral and technical questions with immediate feedback.

This was an incredible opportunity. It also completely rerouted my study plans.

Suddenly, I wasn't drilling infrastructure drift detection or memorizing deployment configurations. I was sharpening my STAR stories, refining my career narrative, and practicing how to articulate architectural decisions under pressure. Important skills, but not what the certification exam tests.

I passed anyway. However, those final two weeks could have been dedicated to review time, and instead they were split focus. If I'd scheduled my exam with a 4-week buffer instead of 2, I could have had both: the interview prep and a final exam push.

The lesson:
Life throws unexpected opportunities at you. Some of them are worth the disruption. But if your timeline has no slack, every surprise becomes a crisis. Build the buffer. You'll either use it for the unexpected, or you'll have extra review time. Either way, you win.

Balance theory with practice, but don't skip either
Initially, I underestimated the repetition needed. Watching a lecture once wasn't enough. I'd rewatch sections two and even three times before the concepts stuck. But the real retention came when I paired theory with practice. I'd watch Maarek explain CodePipeline stages in the morning, then build an actual pipeline that evening. The lecture gave me the "what" and "why." The hands-on gave me the "how it actually behaves." Neither alone was sufficient.

The Unexpected Edge: How Power BI Prepared Me for CloudWatch
Here's something I didn't expect: my years building Power BI dashboards gave me a head start on one of the exam's core domains, Monitoring and Logging.

Think about it. In Power BI, you're constantly asking:

• What metrics actually matter to stakeholders?
• How do I visualize trends over time?
• What thresholds trigger concern?
• How do I drill down from summary to root cause?

CloudWatch is the same mental model, different tooling.

When the exam asked about setting up alarms, configuring dashboards, or choosing which metrics to monitor, I wasn't starting from zero. I was translating.

The insight that clicked:
In Power BI, I learned that a dashboard nobody looks at is a waste of effort. The same principle applies to CloudWatch. The exam tests whether you understand what to monitor, not just how to configure it. My instinct for "what does the stakeholder actually need to see?" carried over directly.

If you're coming from a data background, lean into this. You already think in metrics, thresholds, and visualizations. CloudWatch is just a new dialect of a language you already speak.

Key Takeaways:

Get your Solutions Architect first
The DevOps Professional assumes you already understand VPCs, IAM, S3, EC2, and the core AWS ecosystem. Without that foundation, you'll spend half your study time filling gaps instead of learning DevOps concepts.
Two sessions beat one long session
Morning for passive learning (lectures, notes). Evening for active application (console, diagrams, practice). This isn't just time management. It's how retention actually works.
Failed practice exams are data, not defeat
My 40% and 45% scores hurt. But they revealed exactly where my approach was broken. Without those failures, I wouldn't have discovered the rhythm that got me to 801.
Train for fatigue, not just knowledge
75 questions in 3 hours is a mental marathon. Take full-length practice exams under real conditions. Your brain needs to know what question 60 feels like before exam day.
Your background is an asset, not a gap
Coming from data analytics, I thought in terms of metrics, dashboards, and stakeholder needs. That translated directly to CloudWatch and observability concepts. Find what transfers from your experience. It's there.

What's Next
This is the first post in my "Data Analyst to Cloud Engineer" series. I'm documenting this transition in real-time: the wins, the failures, the interview stories, and the technical deep dives.

Coming up:
• EKS on Fargate: The $200 Weekend Mistake That Taught Me Cost Optimization
• IAM Roles vs. Users vs. Service Accounts: Explained for Data Analysts
• 5 AWS Interview Questions That Stumped Me (And How I'd Answer Today)

If you're on a similar journey, or thinking about starting one, follow along. And if you've already made this transition, I'd love to hear what surprised you most. Drop a comment below.

How I Built a Terraform CI/CD Pipeline on AWS with GitHub Actions

Jha' — Tue, 05 Aug 2025 02:13:54 +0000

In my journey to transition from data analytics into cloud engineering and DevOps, I wanted to master Infrastructure as Code(IaC) and automation.

One of the projects I recently completed was building a CI/CD pipeline using Terraform Cloud and GitHub Actions to deploy AWS Infrastructure. This workflow reflects real-world workflows and DevOps practices where infrastructure is version-controlled, automated, and secure.

In this post, I'll cover:

The architecture of my Terraform Cloud pipeline
Key GitHub Actions & HCL configurations
Lessons learned and next steps for scaling this workflow

📌Project Overview
Objective: Automatically provision and update AWS infrastructure using Terraform Cloud whenever new commits are pushed to main.

Core Tools & Services Used:

Terraform Cloud - Remote backend, state management, and automated runs
GitHub Actions - CI/CD pipeline for VCS integration
Terraform & AWS - Infrastructure as Code and resource provisioning
AWS S3 + DynamoDB - Optional state backup (Terraform Cloud handles the primary state)
IAM Roles & GitHub Secrets - Secure authentication

Pipeline workflow:

Developer Commit -> GitHub Actions -> Terraform Validate-> Terraform Cloud Remote Plan -> Terraform Apply -> AWS Resources

This allowed me to version-control my infrastructure and deploy changes safely without manually logging into the AWS console.

🛠 Step 1: Terraform Cloud Setup

Created a Terraform Cloud Organization and workspace(workspace linked to github).
Configured HCL project files for VPC, EC2, and RDS resources.
Enabled remote execution so Terraform Cloud applies changes automatically.

Backend block in main.tf:

terraform {
   cloud{
      organization = "my-org"

      workspaces {
         name = "project2-dev"
    } 
  }
}

This eliminates the need to manage local state or S3/DynamoDB locks manually- Terraform Cloud takes care of it.

🛠Step 2: GitHub Actions Workflow for CI/CD
Instead of applying Terraform directly in GitHub Actions, my workflow validates the code and relies on Terraform Cloud for the plan/apply.

name: Terraform CI/CD
 on: 
   push:
      branches: 
       - main
jobs:
  terraform-cloud:
    runs-on: ubuntu-latest

      env:
        TF_CLOUD_ORGANIZATION: my-org
        TF_API_TOKEN: ${{ secrets.TF_API_TOKEN }}
        TF_WORKSPACE: poject2-dev

steps:
  - name: Checkout Repo
    uses: actions/checkout@v3  

  - name: Setup Terraform
    uses: hashicorp/setup-terraform@v2
    with:
       terraform_version: 1.11.4 #Pin version for consistency

  - name: Terraform Validate
    run: terraform validate

  - name: Trigger Terraform Cloud Run
    run: |
      terraform login --token=$TF_API_TOKEN
      terraform init
      terraform plan
      terraform apply - auto-approve

Key points:

GitHub Actions store the Terraform Cloud API token.
Workflow validates locally but delegates execution to Terraform Cloud.
Optional approval steps can be handled via Terraform Cloud's policy or run queue.

🛡 Step 3: Security and Secrets

Terraform Cloud handles the remote state securely.
No secrets or .tfstate files are committed to Github.
IAM roles use least privilege to limit AWS resource access.
AWS credentials were stored as GitHub Secrets

📊Lessons Learned

Terraform Cloud simplifies team collaboration - no local state headaches.
CI/CD + IaC improves reliability - every infrastructure change is tested and approved.
Version-controlled deployments provide a clear audit trail for cloud environments.

🚀Next Steps

Add multi-enviroment pipelines(dev, staging, prod)
Send Slack or Teams notifications on successful plans and applies.

💬 Have you automated Terraform with Terraform Cloud or another CI/CD tool? I'd love to hear how you handle multi-environment deployments and approvals.

aws #terraform #terraformcloud #devops #iac #cicd #githubactions