DEV Community: Margaret Fafa Amanfu

Where are Mali's schools most at risk? Building an Education Disruption Index from open data.

Margaret Fafa Amanfu — Sat, 07 Nov 2026 11:02:14 +0000

In conflict-affected countries, education is rarely disrupted by a single event. Schools close after attacks, families move away, roads become unsafe, and teachers stop coming. Organisations trying to keep children learning have limited money and limited field staff, so they face a blunt question:

Where is education access most likely to be disrupted, and where should we look first?

I built the Mali Education Disruption Index (EDI) to give a first, data-driven answer to that question. It scores all 50 of Mali's cercles (the country's second-level administrative areas, roughly a district) and puts the result on an interactive map.

🗺️ Live map: https://megphapha.github.io/EduDisruption-Index/
💻 Code and data: https://github.com/MegPhapha/EduDisruption-Index

The finished map: each of Mali's 50 cercles coloured by priority tier, with the five Critical cercles labelled by name.

This post walks through the data, the messy parts of cleaning it, the scoring formula, how I tried to stay honest about missing data, and one thing the finished map revealed about my own formula.

The data: three open sources

Everything comes from public datasets on the Humanitarian Data Exchange (HDX):

What	Source	Period
Conflict events and fatalities	ACLED	2020–2024
School status (open / closed)	OCHA Mali school registry	2023 snapshot
Population per cercle	OCHA Mali admin-2 estimates	2020

Across Mali, ACLED records 6,471 conflict events and 17,941 fatalities for 2020–2024. Of the 4,491 schools I could match to a cercle, 63% were recorded as closed.

The messy part: getting three files to agree

Joining three datasets on a place name sounds easy. It wasn't.

1. Names don't match. The same cercle can appear as Niafunké, Niafunke or NIAFUNKE depending on the file. Every join goes through a small normalisation function that lowercases and strips French accents:

def normalize(s):
    if s is None:
        return ''
    s = str(s).strip().lower()
    replacements = {
        'é': 'e', 'è': 'e', 'ê': 'e', 'ë': 'e',
        'à': 'a', 'â': 'a', 'ä': 'a',
        'ô': 'o', 'ö': 'o',
        'î': 'i', 'ï': 'i',
        'û': 'u', 'ü': 'u', 'ù': 'u',
        'ç': 'c'
    }
    for accented, plain in replacements.items():
        s = s.replace(accented, plain)
    return s

Matching also checks longer names first, so Tin-Essako is tried before shorter names that could match part of it.

2. The spreadsheets fight back. The school registry has three rows of metadata above its real header row. Rather than add pandas and openpyxl as dependencies, I treated the .xlsx for what it is, a ZIP archive of XML files, and read it with the standard library:

with zipfile.ZipFile('data/raw/mali_schools_2023.xlsx') as z:
    with z.open('xl/sharedStrings.xml') as f:
        strings = [el.text or "" for el in ET.parse(f).findall('.//{...}t')]
    # ...then walk the sheet's <row> elements, skipping the metadata rows

3. ACLED's summary file is "sparse". The cercle and year columns are filled in only on the first row of each group; the rows below leave them blank. A stateful reader carries the last-seen values forward:

cur_c, cur_y = None, None
for row in rows:
    if row_data.get('C'):          # new cercle starts here
        cur_c = match_cercle(row_data['C'])
    if row_data.get('H'):          # new year starts here
        cur_y = row_data['H']
    if cur_c and cur_y and year_start <= int(cur_y) <= year_end:
        stats[cur_c]['events'] += int(float(row_data.get('I') or 0))
        stats[cur_c]['fatalities'] += int(float(row_data.get('J') or 0))

The whole pipeline, cleaning plus scoring plus generating the web pages, is about 770 lines of Python with no third-party dependencies. That was deliberate: anyone can clone the repo and rerun it without setting up an environment.

The formula

Each cercle gets a score between 0 and 1:

EDI = 0.50 × closure rate
    + 0.25 × conflict events per 100k people
    + 0.25 × fatalities per 100k people

Each input is divided by the highest value of any cercle, so all three sit on a 0–1 scale before weighting.

School closures (50%) get the most weight because they measure the outcome itself: are schools working or not?
Conflict events per 100k (25%) capture what closure data misses, such as unsafe routes, displacement and fear of attending. Dividing by population stops big cercles winning on volume alone.
Fatalities per 100k (25%) add severity. One attack with many casualties is a different signal from many minor incidents.

Being honest about missing data

The biggest problem in this project wasn't code. It was coverage. Automated matching linked schools to only some cercles:

Coverage	Rule	Cercles
Full	10 or more schools matched	14
Partial	3–9 matched	9
Limited	1–2 matched	4
Conflict-only	none matched	23

That creates a trap. A cercle with one matched school that happens to be closed shows a "100% closure rate" and shoots up the ranking on the strength of a single data point.

Rather than hide this, I made it part of the output:

Data-Limited tier. Cercles with fewer than 3 matched schools and fewer than 100 conflict events per 100k people are taken out of the ranking and shown in grey. That's 22 of the 50. The message is "we can't tell yet", not "this place is fine".
Severe conflict overrides thin data. Cercles with weak school data but 100 or more events per 100k (such as Kidal and Tessalit) keep a conflict-driven tier, because that signal is strong enough to act on by itself.
A fixed-size Critical list. The top 5 cercles by score that have reliable school data (3 or more matched schools) are marked Critical. Using a fixed count instead of a score cut-off gives a short, defensible list no matter where the score boundaries fall.

What it found

Five cercles reach the Critical tier, about 856,000 people in total:

Cercle	Region	EDI	Schools closed
Ménaka	Gao	0.557	8 of 10
Tombouctou	Tombouctou	0.532	11 of 11
Bourem	Gao	0.522	4 of 4
Bankass	Mopti	0.519	29 of 30
Ansongo	Gao	0.516	4 of 5

They fall into three geographic clusters: the Niger River corridor in Gao (Ménaka, Bourem, Ansongo), Tombouctou, and Bankass on the central plateau near the Burkina Faso border.

Plotting the two main signals against each other shows where they agree. Cercles in the upper right have both high conflict and high closure rates. Cercles along the bottom edge are the data gaps: zero closures recorded, simply because no schools were matched.

Conflict intensity (log scale) against school closure rate. Each bubble is a cercle, sized by population. Hollow rings mark cercles with little or no school data, which is why so many sit at 0%.

Does the answer depend on the time window?

A ranking that flips when you nudge an assumption isn't much use for planning. So I reran the whole pipeline using only 2022–2024 conflict data and compared the results.

Four of the five Critical cercles stayed in place (Ménaka, Tombouctou, Bourem, Bankass). Only the fifth slot changed: Ansongo dropped out and Diré came in. Ansongo's ranking leans on heavy conflict in 2020–2021, while Diré's 100% closure rate doesn't depend on the window. That gives field teams a four-cercle core they can trust, plus one borderline slot worth discussing.

Turning it into a map people can use

The output is a static site on GitHub Pages: a map page and a dashboard page. A Python script writes both HTML files directly, with every number computed from the data at build time, so the text on the page can never drift from the analysis.

The map uses Leaflet with cercle boundaries from geoBoundaries (CC BY 4.0). A few design choices made the biggest difference:

Shaded areas, not dots. My first version drew one circle per cercle, placed at its main town and sized by score:

Before: one dot per cercle. It's accurate, but it's hard to see which areas are affected or how big they are.

Filling each cercle's real boundary by tier (the map at the top of this post) makes the geographic clusters jump out immediately. It also makes the data gaps visible: the big grey, dash-outlined block in the south-west is the Data-Limited tier.

A legend that says what to do. Each tier is paired with a suggested action: Critical → field-validate first, High → next phase of assessment, Data-Limited → verify data before ruling out. A colour scale on its own leaves the reader to work that out.

A story panel. A one-sentence answer, headline numbers with their sources, and cluster cards that zoom the map to those cercles when clicked.

The story panel answers the question before the reader has to interpret any colours. The cluster cards cover all five Critical cercles, plus one card for the data gap.

Show the numbers behind every score. Clicking a cercle opens its figures and a bar splitting the score into its three parts.

Clicking Bankass shows its raw figures and how its score of 0.519 is built. Hold on to that bar; it matters later.

Explain the rules on the page itself. Below the map, a "How to read this map" section sets out the three indicators with their weights and sources, and the rule for every tier in plain language, so nobody has to open the methodology file to understand a colour.

The "How to read this map" section and the link to the repository, where every figure can be reproduced.

A dashboard for the detail. A second page holds the charts: the top 10 cercles, the conflict-versus-closure scatter, the tier split and conflict by region.

The analytics dashboard. The Critical cercles are highlighted in red in the top-10 chart.

Two practical lessons:

Embed your boundaries. I inlined the simplified GeoJSON (rounded to 3 decimal places) straight into the page instead of fetching it at runtime. The page grew from about 75 KB to about 300 KB, but it works offline and can't break when someone else's URL changes.
Check your basemap. CARTO's free basemap tiles now need an API key, and without one they show an "API KEY REQUIRED" watermark. My live site was showing it before I noticed. I switched to Esri's light grey canvas, which still works without a key.

What the map taught me about my own formula

That score-breakdown bar turned out to be the most useful thing I built, because it exposed a weakness in the formula.

Look at Bankass above: 0.48 of its 0.519 comes from closures, and only 0.02 and 0.01 from conflict. That isn't because Bankass is peaceful. It recorded 313 conflict events and 1,170 fatalities.

The cause is normalising to the maximum. One cercle, Abeibara, a sparsely populated area in the Kidal region, has 1,072 events and 6,840 fatalities per 100,000 people. That's about 40 times the median cercle's event rate (25 per 100k). Because every cercle is divided by Abeibara's value, the conflict parts of most cercles' scores shrink to almost nothing. In practice, the "50/25/25" index ranks most of Mali by closure rate alone.

The fix is straightforward: cap each indicator at a high percentile (say the 95th) before scaling, or rank on a log scale. I haven't changed it yet, because the Critical list is the part people would act on and I want to check how much it moves first. But I would never have spotted this from the ranking table alone. Showing how each score is built is a check on your own method, not only a courtesy to readers.

Limitations

23 of 50 cercles have no school data matched. The Data-Limited tier makes this visible, but it doesn't fix it.
Closure status is a snapshot. The registry shows current status, not when a school closed or whether it has reopened.
ACLED fatality counts are conservative, and probably most under-reported in exactly the remote cercles where school data is also thin.
ACLED is licensed CC BY-NC, so the outputs can't be reused commercially.
No automatic refresh. The pipeline runs once; ACLED publishes weekly updates that a scheduled job could pull in.

The most useful finding is a disagreement

The map is a starting point for conversation, not an answer. Where it disagrees with what education teams know on the ground, that disagreement is the most valuable result. It points either to a gap in the data or to a condition the data can't see, and either one improves the method.

The approach isn't specific to Mali. Any country with ACLED coverage, a school registry and admin-level population figures can be scored the same way. The code, data, methodology and source notes are all public:

👉 https://github.com/MegPhapha/EduDisruption-Index

I'd appreciate feedback, especially from anyone who has built composite indices before. How would you handle the normalisation problem?

Next in the series: turning this index into a bilingual AI tutor that keeps students learning when the classroom is gone.

Cloud Security with AWS IAM: How I Controlled Access to EC2 Instances Using Policies, Tags, and the Policy Simulator.

Margaret Fafa Amanfu — Mon, 22 Jun 2026 13:21:09 +0000

Project Overview

Every AWS account has a question it needs to answer before anything else: who gets access to what?

In this project, I'll use AWS Identity and Access Management (IAM) to control exactly that; setting up users, groups, and policies that define what actions are allowed and on which resources. IAM sits at the foundation of cloud security, and getting it right is what separates a well-architected environment from one that's one misconfigured permission away from a serious incident.

It's a skill companies care about deeply enough that entire roles like IAM Engineers and Cloud Security Engineers exist around it. Today, I'm building that foundation from the ground up.

Tools and Concepts

Services I used:
Amazon EC2 to provision virtual server instances, AWS IAM to control access through users, groups, and policies, and the IAM Policy Simulator to validate permissions without touching live infrastructure.

Key concepts I learned:

Least privilege : granting users only the access they need, nothing more.

Tag-based access control : using Env: development and Env: production tags as policy conditions to enforce hard environment boundaries.

IAM policy structure : how Effect, Action, Resource, and Condition work together in JSON, and why explicit Deny always overrides Allow.

Group-based permission management : attaching policies to groups rather than individual users for scalable, consistent access control.

Policy simulation : validating IAM logic safely before it affects real resources.

Project Reflection

This project took me approximately 2 hours to complete, including the secret mission.

The most challenging part was understanding the IAM policy JSON rather than just copying and running it. Breaking down each statement; why the Condition block uses tag values to gate access, and why the explicit Deny on DeleteTags and CreateTags exists as a separate guardrail. It took deliberate effort to fully grasp. Getting that detail right required thinking like an attacker, not just a builder.

It was most rewarding to see the policy work end-to-end: from a JSON document I dissected and understood, to a real authorization decision in the AWS console, to a confirmed simulation result in the IAM Policy Simulator. That full loop from comprehension to validation is exactly what cloud security work looks like in practice.

Step 1: Tags

What I did in this step

To simulate a realistic cloud environment, I launched two EC2 instances; one tagged as a production server and one as a development server. This environment tag distinction is central to the IAM project: later, I configured policies that control which users can access which instance based on these tags, reflecting how access control works in real engineering teams where developers shouldn't have unrestricted access to production infrastructure.

EC2 launch screen showing Env tags

Understanding tags

Tags are key-value labels you can attach to AWS resources for organisation and management. A tag has two parts: a Key (the category) and a Value (the specific label). For example: Env : production.

They're useful for three things:

Organisation : filter and identify resources quickly across a large account without scrolling through everything manually.

Cost allocation : track spending by team, project, or environment using AWS Cost Explorer.

Policy enforcement : IAM policies can condition access based on tag values, so you can allow actions on development resources while blocking the same actions on production.

That third use is the focus of this project.

My tag configuration

The tag key I've used on both EC2 instances is Env, short for Environment. The values I've assigned are production for the first instance and development for the second, distinguishing the two environments that my IAM policies will later control access to.

Step 2: IAM Policies

What I did in this step

Next, I created an IAM policy that grants access to the development EC2 instance only.

The reasoning is straightforward: engineers testing new changes should never have unrestricted access to production infrastructure. A misconfigured script, an accidental stop command, or a wrong setting pushed during testing could take down a live environment. By scoping permissions to the development instance through an IAM policy, we enforce a hard boundary; testers can do their work freely without the risk of touching production.

This is the principle of least privilege in practice: give users exactly the access they need, and nothing more.

Understanding IAM policies

An IAM policy is a document that defines what actions are allowed or denied on which AWS resources, and under what conditions. Every permission in AWS flows through a policy; nothing is granted by default.

In plain terms: policies answer the question "can this user do this thing to this resource?" They can be attached to users, groups, or roles, and they evaluate every API call made in your account against a set of Allow and Deny rules.

In this project, my policy specifically allows actions on EC2 instances where the Env tag equals development, meaning the same user would be blocked from performing those same actions on the production instance.

The policy I set up

I created the policy using the JSON editor rather than the visual editor. JSON (JavaScript Object Notation) is the native format AWS uses to store and evaluate IAM policies. While the visual editor is a helpful starting point for beginners, writing directly in JSON gives you precise control over the policy structure, and more importantly, it's how policies are managed in real engineering workflows, through infrastructure-as-code tools like Terraform or AWS CloudFormation.

JSON policy editor

Policy effect

This policy has three statements that work together:

1. Allow all EC2 actions on development resources: the ec2:* wildcard grants full EC2 permissions, but only where the resource carries the tag Env: development. Any action attempted on the production instance is implicitly denied.

2. Allow read-only visibility across all instances: ec2:Describe* lets the user see all EC2 instances regardless of environment. This is necessary so they can actually view the AWS console without getting a blank screen; but seeing is not the same as touching.

3. Deny tag modification on all resources: ec2:CreateTags and ec2:DeleteTags are explicitly denied across the board. This is a critical guardrail: without it, a user could simply retag the production instance as development and bypass the first rule entirely.

Together, these three statements enforce a clean boundary; full working access to development, zero access to production, and no way to game the tagging system to escalate privileges.

Understanding Effect, Action, and Resource

The Effect, Action, and Resource attributes of a JSON policy define the three core elements of every permission statement.

Effect determines whether access is granted or blocked; it can only be Allow or Deny. When both apply to the same action, Deny always takes precedence.

Action specifies which AWS API calls the statement covers; for example, ec2:* for all EC2 actions, or ec2:Describe* for read-only operations only.

Resource defines which AWS resources the statement applies to. A * targets all resources, but this can be scoped to a specific resource using its ARN (Amazon Resource Name). In this project, resource-level targeting is handled through the Condition block instead, using the Env tag to distinguish development from production.

Think of a policy statement as a sentence: "[Allow/Deny] this [Action] on this [Resource]." The Condition block is what adds the "but only if..." clause, making policies precise rather than broad.

My JSON Policy

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Env": "development"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ec2:DeleteTags",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    }
  ]
}

Step 3: Account Alias

What I did in this step

Next, I created an account alias for my AWS account.

By default, the AWS IAM sign-in URL contains your account's numeric ID; a 12-digit number that's difficult to share and easy to mistype. An account alias replaces that with a human-readable name, making the sign-in URL clean and recognisable.

This matters in practice: when onboarding a new team member or sharing console access with an intern, you want to hand them a URL like https://intern-alias-fafa.signin.aws.amazon.com/console rather than a string of numbers. It's a small change with a real impact on how professionally access is managed.

Understanding account aliases

An account alias is a custom, human-readable name assigned to your AWS account that replaces the default 12-digit account ID in the IAM sign-in URL.

Instead of signing in at:
https://123456789012.signin.aws.amazon.com/console

You get:
https://intern-alias-fafa.signin.aws.amazon.com/console

Beyond readability, an alias signals professionalism. It's what you'd configure in a real company environment before sharing console access with a new team member or contractor. It also reduces the risk of someone accidentally signing into the wrong account when managing multiple AWS environments.

Setting up my account alias

Setting up the account alias took just a few minutes; one of the quickest wins in this project. My AWS console sign-in URL is now https://intern-alias-fafa.signin.aws.amazon.com/console. Clean, readable, and ready to share.

IAM dashboard showing alias confirmed

Step 4: IAM Users and User Groups

What I did in this step

Next, I created a dedicated IAM user group for interns and added a new IAM user to it.

Groups are how permissions scale cleanly in AWS. Rather than attaching policies to individual users, which becomes unmanageable as a team grows, you attach the policy once to the group, and every user in that group inherits it automatically. Onboard a new intern? Add them to the group. Remove someone's access? Remove them from the group. No policy editing required.

The IAM user I created represents our new intern: a separate identity with its own login credentials, scoped entirely to the permissions defined by the group policy; nothing more.

Understanding user groups

An IAM user group is a collection of IAM users who share the same permissions. Rather than attaching a policy to each user individually, you attach it once to the group and every member inherits those permissions automatically.

This is what makes access management scalable. In a real engineering team, you might have groups like developers, interns, or ops-team, each with a policy tailored to their level of access. Adding or removing a user from a group is all it takes to grant or revoke their permissions; no policy changes needed.

In this project, my interns group is attached to the IAM policy I created earlier, which scopes all access to the development EC2 instance only.

Attaching policies to user groups

I attached the policy I created earlier to the interns user group, which means every user in this group automatically inherits the same permissions; full access to the development EC2 instance, read-only visibility across all instances, and a hard block on modifying any resource tags.

This is the power of group-based access management: the policy is defined once and applied consistently across every member. If I onboard five more interns tomorrow, I simply add them to the group; no need to touch the policy or configure permissions user by user.

Understanding IAM users

IAM users are unique identities created within an AWS account, each representing a specific person or application that needs access to AWS resources. Every IAM user has their own login credentials. Sharing the root account credentials is a serious security risk, so each user gets their own login through the account alias URL: https://intern-alias-fafa.signin.aws.amazon.com/console

In this project, I created an IAM user named fafa-dev-InternFafa to represent our new intern. Their permissions are inherited directly from the interns group, meaning their access is already scoped to the development environment before they log in for the first time.

A key security detail: AWS displays the generated password only once at the point of user creation; a deliberate design choice that enforces secure credential handoff rather than leaving passwords retrievable indefinitely.

User created / retrieve password screen

Step 5: Logging in as an IAM User

Sharing sign-in details

There are two ways to share a new user's sign-in details:

Download as a .csv file: directly from the AWS console at the point of user creation. This file contains the sign-in URL, username, and generated password; everything the new user needs to log in.

Email the sign-in instructions: using the "Email sign-in instructions" option in the console. AWS generates a pre-formatted email containing the account sign-in URL and username, which you can send straight to the new user.

Both options are only available immediately after user creation. Once you navigate away, the password is no longer retrievable; which is why it's critical to share credentials securely at the point of setup, not after the fact.

Observations from the IAM user dashboard

Once I logged in as fafa-dev-InternFafa, the dashboard immediately showed the policy in action. The Applications widget displayed an Access denied to servicecatalog:ListApplications error, and the Cost and usage widget showed Access denied across both current month and cost breakdown; services the intern has no business accessing.

Dashboard with access denied errors

This is exactly what we want to see. The policy attached to the interns group doesn't grant broad AWS console access; it scopes permissions specifically to EC2 actions on the development instance. Any service outside that scope hits an implicit deny: IAM blocks everything that isn't explicitly allowed.

Those red access denied banners aren't errors. They're the policy working as designed.

Step 6: Testing IAM Policies

What I did in this step

I logged into the AWS console as the intern IAM user and tested access against both EC2 instances; attempting actions on the production instance and the development instance separately.

This is an important validation step. Creating a policy and attaching it to a group is only half the work; you need to verify that the permissions behave exactly as intended before handing credentials to a real user. A misconfigured policy that accidentally grants production access would undermine everything we've set up so far.

By testing from the intern's perspective, I can confirm that the principle of least privilege is actually enforced, not just configured.

Testing policy actions

I tested the policy by attempting to stop both EC2 instances as fafa-dev-InternFafa. The results confirmed the policy is working exactly as intended.

Two instances, two different tags, two completely different outcomes; from the same user, under the same policy. That's tag-based access control working in practice.

Stopping the production instance

When I tried to stop Prod-server-Fafa (i-0c2e3f0f509ccdf5e), the action failed immediately with an authorisation error: You are not authorized to perform this operation.

This was because the IAM policy attached to the interns group only allows EC2 actions on resources tagged Env: development. The production instance carries the tag Env: production, so the policy's condition check fails; and AWS blocks the action entirely before it can execute.

The error message itself is worth noting: it references fafa-dev-InternFafa by name and explicitly states that no identity-based policy allows the ec2:StopInstances action on that resource. AWS isn't just blocking the action; it's telling you exactly why, which is what makes IAM errors useful for debugging in real engineering environments.

Red authorisation error screen

Stopping the development instance

Next, when I tried to stop Dev-server-Fafa (i-057461c1ed516a0e4), it worked perfectly. The console confirmed Successfully initiated stopping of i-057461c1ed516a0e4 and the instance state immediately shifted to Stopping.

This was because the development instance carries the tag Env: development, which satisfies the condition in the IAM policy. AWS evaluated the request, matched the tag value, and allowed the ec2:StopInstances action to execute without restriction.

This is the exact outcome the policy was designed to produce; full working access to development, zero access to production, enforced automatically through tags rather than manual permission checks.

Green success banner + Stopping state

Step 7: IAM Policy Simulator (Secret Mission 🔐)

To extend this project, I used the IAM Policy Simulator to validate the intern's permissions without affecting any live AWS resources.

Directly testing permissions on real infrastructure, as I did in the previous step, isn't sustainable in a production environment. Every unnecessary instance stop risks disrupting running workloads and other engineers. The Policy Simulator lets me verify exactly what a user can and cannot do against any action or resource, without executing a single real API call. It's a faster, safer, and more professional approach to permission validation.

Understanding the IAM Policy Simulator

The IAM Policy Simulator is a tool that lets you test and validate IAM policies against specific actions and resources without executing anything in your actual AWS environment.

It's useful for verifying that a policy behaves exactly as intended before it affects real infrastructure. In a real team environment where policies are updated frequently; onboarding new roles, adjusting permissions, responding to a security incident; the Policy Simulator is the difference between testing safely and finding out something is misconfigured in production.

How I used the simulator

I set up a simulation for FafaDevEnvironmentPolicy, testing two EC2 actions; DeleteTags and StopInstances with the ec2:resourcetag/env context key set to development.

StopInstances came back allowed, confirming the policy permits actions on development-tagged resources. DeleteTags came back denied; the explicit Deny statement holds regardless of environment, blocking any attempt to retag resources and bypass access controls.

I had to adjust the simulation context manually by adding the ec2:resourcetag/env: development key-value pair under the StopInstances action. Without that context, the simulator has no tag information to evaluate the condition against and would return a denied result even for actions that should be allowed. This is an important nuance: the Policy Simulator only knows what you tell it about the resource context.

One simulation, two actions, zero infrastructure touched; and complete confidence that the policy is enforcing the right boundaries.

Policy Simulator results screen

⚠️ Don't Forget to Clean Up

If you followed along with this project, make sure to delete your AWS resources when you're done to avoid unexpected charges:

Terminate both EC2 instances : go to EC2 > Instances > select both > Instance State > Terminate
Delete the IAM user : go to IAM > Users > select fafa-dev-InternFafa > Delete
Delete the IAM user group : go to IAM > User Groups > select interns > Delete
Delete the IAM policy : go to IAM > Policies > filter by Customer managed > select FafaDevEnvironmentPolicy > Delete
Remove the account alias — go to IAM > Dashboard > Delete next to your alias

_Deletion/Termination of instances _

IAM group deletion screen

Policy deletion screen

AWS's free tier covers most of what we used here, but EC2 instances left running will accumulate charges. When in doubt, clean up.

Why I Did This Project

I chose to do this project today because cloud security is a non-negotiable foundation for the DevOps engineering path I'm building toward. IAM sits at the centre of every AWS environment; understanding how to design and validate access control policies isn't optional, it's foundational.

This project gave me hands-on experience with the exact skills that show up in cloud and DevSecOps job descriptions: least privilege, policy design, tag-based access control, and permission validation.

This project met my goals. I came in wanting to understand IAM beyond the theory, and I'm leaving with a working policy, a tested environment, and documentation I can publish and point to.

Something that would make learning with NextWork even better is more projects that chain together; where the IAM setup you build here feeds directly into a subsequent project on CloudTrail logging or AWS Config compliance rules. The security story feels most powerful when you see how the pieces connect.