DEV Community: Akhtar Jalbani

What Happens When a Teacher Learns Agentic AI — And Brings It Into the Classroom

Akhtar Jalbani — Sat, 06 Jun 2026 11:02:07 +0000

I teach cloud computing using AWS Academy Learner Lab. Every semester, my students hit the same invisible walls:

They follow an AWS tutorial, ask an AI assistant for help, and get told to "create an IAM role" — which is blocked in Learner Lab
Their credentials expire mid-session and they don't know why their commands suddenly stopped working
Someone leaves an EC2 instance running overnight and burns through half the lab budget
A well-meaning AI suggests Route 53 or a NAT Gateway — neither of which behaves as expected in the lab environment

These aren't AWS problems. They're Learner Lab-specific constraints that no amount of official AWS documentation covers — and that AI coding assistants have absolutely no awareness of.

So I built something to fix that.

What Are Agent Skills?

Agent Skills are a relatively new open standard — SKILL.md files that give AI coding assistants structured, on-demand expertise. Think of them as a cheat sheet that loads automatically when relevant, without you having to re-explain the same context every session.

Microsoft published an Azure Agent Skills repo covering 193 Azure services. It works beautifully with Claude Code, GitHub Copilot, Cursor, and others.

I took that idea and built the AWS equivalent — specifically tuned for AWS Academy Learner Lab.

The Repo: aws-agentic-skill

👉 github.com/akjalbani/aws-agentic-skill

It contains 7 skills covering the core services students encounter in their first AWS courses:

Skill	What it teaches
🔬 `aws-learner-lab`	The most important one — LabRole constraints, credential refresh workflow, budget guardrails, unsupported services
⚡ `aws-lambda`	Serverless functions, triggers, packaging, CloudWatch logs
🪣 `aws-s3`	Buckets, uploads, permissions, static website hosting, boto3 usage
💻 `aws-ec2`	Launching instances, SSH, security groups, stopping to save budget
🔒 `aws-iam`	Why you can only use LabRole, passing roles to services, fixing credential errors
🏗️ `aws-cloudformation`	Infrastructure as Code, deploying and deleting stacks cleanly
🌐 `aws-vpc`	Default VPC usage, security groups, avoiding expensive NAT Gateways

What a Skill Actually Looks Like

Each skill is a SKILL.md file with YAML frontmatter and structured markdown. Here's the pattern:

---
name: aws-learner-lab
description: >
  Use this skill whenever working inside an AWS Academy Learner Lab environment.
  Provides critical constraints, workarounds, and best practices specific to
  Learner Lab sessions. Always load this skill before any other AWS skill when
  the user mentions "Learner Lab", "Academy", "vockey", or session-based credentials.
---

# AWS Academy Learner Lab

## ⚠️ Critical Constraints

### IAM Restrictions
- You CANNOT create IAM users — the lab blocks this
- You CANNOT create new IAM roles — use the pre-existing `LabRole`
- When a service asks "Choose or create a role", always select **LabRole**

### Credentials & Sessions
- Credentials expire when your lab session ends (~4 hours)
- To get credentials: click "AWS Details" → "Show" next to AWS CLI
- Always include aws_session_token — Learner Lab requires it

...and so on

The AI assistant reads the description field to decide when to load the skill, then uses the full content to answer correctly.

How It Works in Practice

Once the skills are installed, you just talk naturally to your AI assistant. No setup prompts, no repeating yourself every session.

I tested it myself — as a student would. I opened Claude Code in a fresh terminal and typed:

Using the aws-learner-lab and aws-s3 skills, create an S3 bucket and upload a test file to it

Here's what happened:

Step 1 — Claude Code starts and reads the installed skills

Claude Code launches and discovers the aws-learner-lab and aws-s3 skills automatically

Step 2 — Creates the S3 bucket using the correct Learner Lab approach

No IAM role creation attempts. No wrong region. Just the right command.

Step 3 — Uploads the test file

The upload command, correctly formed with region and credentials context

Step 4 — Lists all buckets to confirm

The bucket appears. It worked.

No AccessDenied errors. No suggestions to create IAM roles. No wrong region. The skill did its job — it gave the AI exactly the context it needed to operate correctly inside Learner Lab.

Installation (5 Minutes)

Prerequisites

Node.js (LTS)
Claude Code: npm install -g @anthropic-ai/claude-code
AWS CLI

Install the skills

# Clone the repo
git clone https://github.com/akjalbani/aws-agentic-skill.git

# Copy skills to Claude Code's global skills folder
# macOS/Linux:
cp -r aws-agentic-skill/skills/* ~/.claude/skills/

# Windows (Command Prompt):
xcopy /E /I "aws-agentic-skill\skills\*" "%USERPROFILE%\.claude\skills\"

For other AI assistants, change the destination:

Assistant	Path
Claude Code	`~/.claude/skills/`
GitHub Copilot	`~/.copilot/skills/`
Cursor	`{project}/.cursor/skills/`
Codex CLI	`~/.codex/skills/`

Connect to your Learner Lab

Every session, refresh your credentials:

Start your lab → wait for the green dot
Click AWS Details → Show next to AWS CLI
Copy the three lines into ~/.aws/credentials
Run aws configure set region us-east-1
Verify: aws sts get-caller-identity

You should see LabRole in the ARN — you're connected.

Why This Matters for Educators

The biggest time sink in a cloud lab session isn't the concepts — it's the environment friction. Students spending 20 minutes debugging an AccessDenied error aren't learning AWS. They're learning frustration.

Agent skills shift that. Instead of the AI giving generic advice that breaks in Learner Lab, it gives advice that's specific to the student's exact environment. The constraints are baked in. The guardrails are built in. The right commands appear first.

My plan for upcoming classes is to have students install these skills on day one — before they touch a single AWS service. The AI becomes their lab partner that already knows the rules of the lab.

What's Next

This is v1 — 7 skills, the core services. I'm planning to add:

aws-dynamodb — NoSQL tables, queries, DynamoDB from Lambda
aws-api-gateway — REST APIs connected to Lambda
aws-rds — managed databases with Learner Lab networking constraints
aws-sns-sqs — messaging patterns students encounter in later courses

The repo is open source and contributions are welcome. If you're an AWS Academy instructor and want to add a skill for a service your students use, the pattern is straightforward — follow the existing SKILL.md structure and open a PR.

Resources

Are you using AI tools in your cloud classes? I'd love to hear what's working — drop a comment below.

Top 10 AWS Cloud Security Misconfigurations (and How to Avoid Them)

Akhtar Jalbani — Mon, 14 Apr 2025 10:13:55 +0000

Cloud adoption has grown at a remarkable pace, but with that growth comes increased responsibility—especially when it comes to security. One of the most common pitfalls I see in AWS environments, especially among new users and even some experienced teams, is misconfigurations. These are not always malicious or intentional, but they can open the door to serious vulnerabilities.

As an AWS Community Builder working closely with both startups and educational institutions, I’ve compiled a list of the top 10 cloud security misconfigurations in AWS—and more importantly, how you can avoid them.

1. Publicly Accessible S3 Buckets:

What Happens:
Buckets are unintentionally configured to allow public access, exposing sensitive data such as backups, logs, or private documents.

How to Avoid:

Use S3 Block Public Access settings.
Enable bucket policies to enforce least privilege.
Regularly audit with AWS Trusted Advisor or Amazon Macie.

2. Overly Permissive IAM Policies

What Happens:
Granting *:* permissions (wildcards) can allow users or roles to perform any action on any resource.

How to Avoid:

Follow the principle of least privilege.
Use AWS IAM Access Analyzer to review policy impact.
Break roles down by responsibility and avoid "power users."

3. Disabled or Missing MFA for Root Accounts

What Happens:
The root user has unrestricted access. Without multi-factor authentication, it's a single point of compromise.

How to Avoid:

Enable MFA on the root account immediately.
Restrict the use of the root account—use IAM roles instead for daily tasks.

4. Unrestricted Security Group Rules (0.0.0.0/0)

What Happens:
Ports like SSH (22), RDP (3389), or database ports are open to the world, making brute-force attacks trivial.

How to Avoid:

Restrict access to trusted IP ranges.
Use AWS Systems Manager Session Manager instead of SSH where possible.
Set up automated checks with Config Rules.

5. Incomplete Logging and Monitoring

What Happens:
Without proper logging, you may never know if a breach occurred—or how.

How to Avoid:

Enable CloudTrail in all regions.
Use CloudWatch Logs, GuardDuty, and AWS Config for detailed insights.
Archive logs to S3 with retention policies for audit purposes.

6. Misconfigured VPC Settings

What Happens:
Incorrect routing tables, NAT gateway placement, or overly permissive NACLs can lead to exposure or blocked traffic.

How to Avoid:

Understand the flow of traffic between public and private subnets.
Keep databases and internal apps in private subnets.
Use VPC Flow Logs to monitor unusual patterns.

7. Unencrypted Data at Rest or In Transit

What Happens:
Data is vulnerable to interception or theft without proper encryption.

How to Avoid:

Enable encryptionon EBS volumes, RDS databases, and S3 buckets.
Use TLS for secure communication between services.
Employ KMS (Key Management Service) for key lifecycle control.

8. Lack of Resource Tagging for Security and Governance

What Happens:
Security teams struggle to track resource ownership, leading to "orphaned" services running unmonitored.

How to Avoid:

Create a standardized tagging strategy (e.g., Owner, Environment, Sensitivity).
Use tags for automation in security alerts, budgeting, and compliance.
Enforce tagging through **Service Control Policies **in AWS Organizations.

9. Insecure Use of Access Keys

What Happens:
Hardcoded access keys in source code or stored in public repositories can lead to account compromise.

How to Avoid:

Use IAM roles with temporary credentials.
Rotate access keys regularly and avoid sharing them across teams.
Monitor key usage with CloudTrail and revoke compromised keys immediately.

10. Ignoring Security Updates for Managed Services

What Happens:
Outdated RDS instances or neglected Lambda runtime versions can introduce known vulnerabilities.

How to Avoid:

Enable automated patching where supported (e.g., RDS, ElastiCache).
Set alerts for deprecated services or runtime versions.
Include patch cycles in your DevOps workflow.

Final Thoughts
Misconfigurations are often the silent threats in cloud environments. The good news? Most of them are preventable with a clear strategy, consistent policies, and the right AWS services in place.

Security isn’t a one-time setup—it’s a continuous process. The more visibility and automation you build into your AWS environment, the better protected your workloads will be.

_ If you’ve encountered any of these misconfigurations—or have lessons learned you’d like to share—feel free to drop a comment. Let’s build more secure cloud environments together._

🛡️ — Written by Akhtar Jalbani an AWS Community Builder passionate about secure cloud adoption.