DEV Community: Seth David Gyimah

E-Agent: Restoring Fairness to Ghana’s Rental Market

Seth David Gyimah — Mon, 02 Mar 2026 01:43:27 +0000

This is project is now live at https://agent.eivali.com

The Community

Renting a property in Ghana is often stressful, opaque, and financially exploitative.

Informal middlemen (“agents”) frequently:

Hijack property listings without owner consent
Inflate rental prices to profit on high commissions.
Incite / influence property owners to Demand excessive rent advances (sometimes 1–2 years’ rent upfront, although this is illegal)
Gatekeep properties to create artificial scarcity

This affects:

Young professionals relocating for work
Students searching for accommodation
Low- and middle-income families
General renting population of Ghana including me (I'm building this system to be used by me and all affected persons in Ghana)

At the same time, property owners also suffer:

They lose direct contact with potential renters

The result is a rental ecosystem driven by intermediaries instead of transparency.

I believe in information being freely available to those who need it, so I built this free platform E-Agent specifically for the Ghanaian rental community — to restore fairness, direct communication, and price integrity between property owners and renters.

Project goes live to the public soon, but demo is currently available for user testing. link included.

What I Built

I built a free, national real estate platform for Ghanaians (E-Agent) that removes exploitative middlemen and enables direct owner-to-renter interaction.
The system is accessible via a mobile friendly website and will soon support USSD Access since there are lots of areas in Ghana with poor internet connectivity.

Core Model

Property owners sign up and post listings directly.
Renters sign up to receive real-time notifications.
No agent commissions.
No listing hijacking.
Renters call up property owners directly, No artificial price inflation.

Key Features

🏠 Direct owner-to-renter property listings
📲 Real-time SMS alerts for new listings and updates
🔐 Secure OTP-based authentication
🚫 AI-powered spam and fraud detection (incoming feature)
📡 Real-time listing availability tracking
User based Anti Agent mechanism to prevent agents from using the platform (users can flag listings they deem as fraudulent or posted by agent) Users who exceed or ban activity threshold are automatically blocked.

Demo

🎥 Video demo: (Insert demo link here)

Live PROJECT link

Code

The project is organized into three separate private GitHub repositories:

Frontend (AWS Amplify Hosted App)
Serverless Backend (AWS SAM Infrastructure)
AI Moderation & Agent System

Dear organizers & judges, due to security and competitive reasons, the repositories are private and links cannot be shared; however, the repos will feature in the accompanying video demo

How I Built It

The platform is built almost entirely on AWS (99% of the stack), designed to scale nationally from day one.

Architecture

Frontend

AWS Amplify (Hosting + CI/CD)
Amazon Cognito (User authentication and OTP flows)

Backend

Amazon API Gateway
AWS Lambda (business logic)
Amazon DynamoDB (data storage)
Amazon S3 (image storage)
Amazon EventBridge (event-driven workflows)
Amazon SQS (asynchronous processing)
AWS Route 53 (DNS)

AI Layer (incoming feature)

Amazon Nova (AI reasoning)
Strands Agents running on AWS Bedrock Agentcore
Automated listing text and image moderation with Amazon Rekognition
Custom AI tools for safe listing updates

Notifications

Local Ghanaian SMS gateway for OTPs, alerts, and reminders

The entire system is fully serverless and event-driven.

AI Community Protection Layer (incoming feature)

To prevent the platform from becoming another exploited marketplace, I'm adding an AI-powered enforcement layer that:

Reviews listing and listing images for inappropriate or deceptive content
Temporarily suppresses suspicious listings
Alerts admin with detailed reasoning

Importantly:

Human oversight and approval will remain in place.

This project aims to remove systemic friction from one of the most essential human needs (housing) and replace it with transparency, fairness, and direct community access.

I @sdg000 am building the entire platform and its components alone. I'm an AWS Cloud Engineer, Solutions / AI Architect from Ghana.

Customizing Default AWS SAM GitHub Actions Pipelines for Real-World Control

Seth David Gyimah — Sun, 25 Jan 2026 11:49:16 +0000

If you’ve used AWS SAM long enough, you are probably familiar with this workflow:

sam init
sam build
sam deploy

“Nice! Everything works.”

A few weeks later…
“Why is everything deploying everywhere and why do I always have #to run cli commands to deploy new stuff?”

This is one of the most common issues I see with teams adopting AWS SAM for production.

SAM makes it easy to start, but you must implement customization beyond what is written in AWS documentation to make it scale safely.

This article shows why you should not rely blindly on the auto-generated SAM GitHub Actions pipeline, and how to evolve it into environment-specific pipelines with proper tagging, automation, and control as well as some notable gotchas while using AWS SAM

This article assumes you are familiar with building a CI/CD pipeline for AWS SAM

Quick Refresher: What AWS SAM Actually Is

AWS SAM (Serverless Application Model) is:

An extension of AWS CloudFormation
Optimized specifically for serverless workloads
Focused on Lambda, API Gateway, DynamoDB, SQS, SNS, etc.
Backed by CloudFormation under the hood

If you know CloudFormation, SAM feels familiar — just simpler and faster for serverless.

And yes, SAM supports OIDC authentication with GitHub Actions by default, which is already best practice (no access keys stored in GitHub secrets 👏).

The Problem with the Default SAM Pipeline

When you select 1 - AWS Quick Start Pipeline Templates after running
sam pipeline init --bootstrap

SAM allows you to generate a single pipeline for your choice of CI/CD system that provides this default setup:

Dev and prod deploy from the same pipeline without much specific environment or branch control
Focuses on speed not operational safety and scaling

This works for demos - not best for real world environments

The Better Approach: Environment-Specific Pipelines

Instead of the default pipeline.yaml, create multiple pipelines

To do this, copy content of default pipeline.yaml into the environment or stage specific pipeline and modify to keep only environment specific configurations and remove all others.
Example in the prod.yaml, you remove all development and test related resources and steps

By default, sam pipeline init allows configuration for only 2 environments or stages, to create a 3rd stage or environment for testing or staging;

Simply copy and run one of the auto generated cloudformation template in the 3rd account or region to create the supporting resources for that environment
Then update the relevant pipeline.yaml and pipelineconfig.toml in the project codebase
After creating all custom pipelines, delete the default `pipeline.yaml' file.
Finally, your .github/workflows/ should be looking like this

.github/workflows/ ├── dev.yaml ├── test.yaml └── prod.yaml

This ensures that, each pipeline

Triggers and deploy to a similarly named github branch or environment
Uses its own configuration
Applies environment / stage specific tags

Example: Branch-Based Deployment

yaml on: push: branches: - dev

yaml on: push: branches: - test

yaml on: push: branches: - main

Modifying `samconfig.toml for easier ci/cd pipeline setup

Sam auto generates samconfig.toml when you start a new sam project, it contains configuration of how sam deploys your resources.

Default `samconfig.toml`

version = 0.1
[default.global.parameters]
stack_name = "sam-article-project"

[default.build.parameters]
cached = true
parallel = true

[default.validate.parameters]
lint = true

[default.deploy.parameters] 
capabilities = "CAPABILITY_IAM" #must be changed
confirm_changeset = true # must be removed
resolve_s3 = true # remove # must be removed

[default.package.parameters] # must be removed
resolve_s3 = true # must be removed

[default.sync.parameters]
watch = true

[default.local_start_api.parameters]
warm_containers = "EAGER"

[default.local_start_lambda.parameters]
warm_containers = "EAGER"

This default configurations throws error when you configure a ci/cd pipeline for github actions to deploy resources because,
The following default configuration values are incompatible with ci/cd pipelines and lead to errors:

confirm_changeset = true causes cloudformation to require manually confirm cloudformation stack changes deploying, which is not possible in when deploying based on a predefined pipeline. So remove that configuration

resolve_s3 = true remove this config because s3 artifact buckets are precreated and don't need to be recreated during deployment

Another key change to make in your various custom or default pipelines as well as samconfig.toml
Change
--capabilities CAPABILITY_IAM
to
--capabilities CAPABILITY_NAMED_IAM
This is because sam needs permission when creating explicitly named resources such as buckets , roles etc.

So your final samconfig.toml should be looking like this:

Ci/Cd optimized `samconfig.toml`

version = 0.1

[default.global.parameters]
stack_name = "sam-article-project"

[default.build.parameters]
cached = true
parallel = true

[default.validate.parameters]
lint = true

[default.deploy.parameters]
capabilities = "CAPABILITY_NAMED_IAM"

[default.sync.parameters]
watch = true

[default.local_start_api.parameters]
warm_containers = "EAGER"

[default.local_start_lambda.parameters]
warm_containers = "EAGER"

Happy AWS Clouding.

Why I Switched from AWS IAM to AWS IAM Identity Center(Why you should Too)

Seth David Gyimah — Sun, 25 Jan 2026 08:09:07 +0000

If you’ve spent any serious time on AWS, you’ve met Identity and Access Management (IAM).
And if you’re like me, you’ve written a policy you thought looked perfect but still got AccessDenied.

As an AWS cloud trainer & engineer, I always tell my trainees one key thing about IAM:

IAM is annoying to wrap your head around, but it’s foundational. You must learn it first.

IAM is global, powerful, unforgiving, and absolutely essential. It teaches you how AWS security really works: policies, principals, trust relationships, permissions boundaries, and least privilege.

You cannot skip IAM.

But here’s the truth many practitioners eventually discover:

IAM is not how you want to manage access at scale.

That’s where AWS IAM Identity Center comes in.

IAM: Powerful, Necessary… and Easy to Outgrow

shines at:

Defining fine-grained permissions
Securing AWS services and workloads
Managing user access at small scale
Teaching you how AWS authorization actually works

But when you start dealing with:

Managing access to multiple AWS accounts

…it starts to feel like you’re fighting the platform instead of using it.

Enter IAM Identity Center (formerly AWS SSO)

IAM Identity Center doesn’t replace IAM — it builds on top of it.

Think of it as:

Centralized identity management
Role-based access done right
One login → many AWS accounts
Short-lived credentials by default
Built for humans, not just services

Recently, I migrated aws console and cli access management for my 20+ AWS Accounts from IAM based Authentication to IAM Identity Center.

And honestly?

I’ve never been happier., if you have only 1 AWS Account, using IAM based authentication to access it via web and cli is manageable and totally doable, but if you more than 3, I encourage the switch.
I use over 20 accounts for different projects and different environments.

Why Identity Center Feels Like “IAM, But Grown Up”

Here’s what changed for me:

🔐 One Login, All Accounts

I sign in once and get access to all my AWS accounts and roles — no more account hopping or credential juggling.

⏱️ No More Long-Lived Credentials

Identity Center issues temporary credentials automatically.
No access keys sitting on my laptop. No rotation scripts. No stress.

💻 CLI Access Without IAM Users

Yes — it works beautifully with the AWS CLI.
I authenticate once, and the CLI uses Identity Center–backed roles instead of IAM users.

Should You Ditch IAM Completely?

Short answer: No. And you shouldn’t.

IAM is:

The foundation of AWS security
Required knowledge for every AWS certification
Still critical for service-to-service access

But for human access, especially in multi-account environments?

IAM Identity Center is the future — and honestly, the present.

My Advice to AWS Learners & Practitioners

Learn IAM deeply first (policies, roles, trust relationships)
Feel the pain of errors, it teaches you important lessons (you will thank me later)
Then graduate to IAM Identity Center
Use it for console access, CLI access, and multi-account setups

Once you switch, you won’t want to go back.

If you’re still managing humans with IAM users and long-lived access keys in 2026,
there’s a better way — and it’s already built into AWS.

Happy clouding ☁️

Strategies to Pass Any AWS Certification Exam

Seth David Gyimah — Sun, 25 Jan 2026 07:28:20 +0000

If you’re preparing for an AWS certification, chances are you’ve already heard a lot of advice:

“Do more practice questions.”
“Memorize dumps.”
“Just book the exam and hope for the best.”

As an AWS Certified Instructor, I can tell you this clearly:

passing AWS exams is not about luck or memorization — it’s about process.

I’ve been providing AWS Cloud Trainings since 2023, and I’ve worked with over 500 trainees, many of whom have gone on to successfully earn AWS certifications across foundational, associate, professional, and specialty levels.

This article shares the exact strategy I teach my students — and the same approach I personally follow every time I sit an AWS exam.

Step 1: Learn the Services by Doing, Not Memorizing

Before touching practice questions, you must first understand the services.

AWS exams test how well you understand:

when to use a service
why one option is better than another
trade-offs (cost, performance, availability, security)

Best learning resources (in order of effectiveness):

AWS Skill Builder (free + paid): official content with hands-on labs
Hands-on labs (this is non-negotiable)
YouTube (great for visual learners)
Udemy courses (structured learning paths)

👉 The rule I give trainees:

If you can’t explain a service in simple words, you don’t understand it yet.

Practice questions — but use them correctly

Practice questions are diagnostic tools, not memorization tools.

Do not binge or memorize answers
Use each question to measure:
- What you understand
- What you think you understand
- What you don’t understand at all

Also:

Review the official AWS exam guide
Know what’s in scope and out of scope
Take the free official practice exams on AWS Skill Builder

Step 2: The 3-Read Rule for Answering AWS Questions

This is the single most important exam technique I teach.

Never choose an answer on the first read.

Read #1 — Casual Scan

Read the question once
Glance at the answers
Don’t decide anything yet

Read #2 — Eliminate

Read the question again, slowly
Look for keywords:
- most cost-effective
- least operational overhead
- highest availability
- fastest
Start eliminating answers that clearly don’t fit

Read #3 — Decide

Read the question a final time
Focus on what the question is really asking
Eliminate remaining distractors answers
Choose the best answer

👉 This applies to:

Practice questions
Mock exams
The real exam

Step 3: Booking the Exam

Book your exam via Pearson VUE.

My recommendation:

Physical test center if possible
Choose online only if:
- You have stable internet
- Quiet environment
- Reliable hardware
- Patience for strict proctor rules

Apply for exam accommodation

Request 30 extra minutes.

Even if you don’t need it, having it allows you to:

Apply the 3-read method properly
Reduce time pressure
Stay calm

Better to have extra time and not need it
than to need it and not have it.

Step 4: Exam Day Strategy

Arrive at least 1 hour early
Bring valid IDs
Get checked in calmly
If writing online, ensure to prepare your space, clear your desk, ensure stable internet (get backup if possible), ensure your laptop is well charged and you have your ids and mobile phone ready to download app to submit photos).

During the exam:

Use the flag feature
If unsure, flag and move on
Finish all questions first
Review flagged questions before submitting

The exam survey?

Skip it if you want.
It’s not mandatory and does not affect your score.

Step 5: The Anxious Wait

Results can take up to 24 hours.

AWS reviews exam compliance through Pearson VUE — that’s why there’s a delay.

Here’s the truth most people don’t realize:

15 questions are unscored
You don’t need 100%
Passing scores:
- 720 — Foundational & Associate
- 750 — Professional & Specialty

Still, I always advise:

Treat every question as if it’s scored.
Avoid complacency.

If you fail?

It’s not the end.

You can retake after 14 days
You now have exam experience
Follow the same strategy again — it works

Proof That This Strategy Works (For Me Too)

I don’t teach what I don’t practice.

Using this exact approach, I’ve passed every AWS exam on my first attempt — never failed an exam:

You can verify my badges here:

AWS Certified Security Specialty
AWS Certified Developer Associate
AWS Certified Solutions Architect Professional
AWS Certified Solutions Architect Associate
AWS Certified Cloud Practitioner
Planning to add more certifications soon. ( I will be sure to follow the proven advise)

Final Advice

AWS certifications are very passable if you:

Learn by doing
Understand why services exist
Apply a disciplined exam strategy
Stay calm and methodical

There’s no magic.
Just preparation, process, and practice.

Best of luck in your next AWS exam.

Connect on LinkedIn.