Forem: KUSEH SIMON WEWOLIAMO

Stop Storing AWS Access Keys in GitHub Secrets — Use OIDC Instead to Authenticate GitHub Actions to AWS

KUSEH SIMON WEWOLIAMO — Thu, 12 Feb 2026 03:58:17 +0000

Introduction

If you’re storing AWS access keys in GitHub Secrets, you’re already behind modern cloud security practices.Let’s all be honest to ourselves, we have in one way or the other dump AWS access keys into GitHub Secrets or we might have read somewhere especially on Reddit about someone dumping AWS access keys into GitHub Secrets. Well, this works, but you’re carrying unnecessary risk. Access keys are long-lived credentials and don’t rotate automatically, and once leaked, they’re hard to contain.

OpenID Connect (OIDC) offers a better option for authentication without storing a long-lived credentials in GitHub secrets. In this post, I will walk you through how GitHub OIDC actually works, why it is more secure compared to long-lived credentials like access keys and how to integrate AWS with GitHub Actions using OIDC.
If you care about safer pipelines and cleaner CloudOps practices, this is one upgrade you don’t want to skip.

Feature	Access Keys	OIDC
Credential Type	Long-lived	Short-lived
Rotation Required	Manual	Automatic
Stored in GitHub	Yes	No
Blast Radius	High	Low

How GitHub Actions OIDC integrates with AWS to access resources

Step 1 Establish trust relationship: A trust relationship needs to be established between GitHub (the Identity Provider – IdP) and AWS (the Service Provider / Relying Party - RP). This relationship will register GitHub as a trusted OIDC provider and will tell AWS where to fetch GitHub’s public signing keys and which token claims AWS should trust.
Step 2 Authentication Request: When a workflow runs, GitHub generates a signed JSON Web Token (JWT) with identity claims that include repository name, branch or tag, workflow name, commit SHA, GitHub org, etc., which proves where the job is running at the moment.
Step 3 Token Validation: The Relying Party (RP), AWS, validates the token using the token signature, issuer, audience, and if token claims match IAM trust policy conditions. The checks either fail or succeed.
Step 4 Issues Short-Lived Credentials: If the validation is successful, it allows the workflow to assume an IAM role, and temporary credentials are issued via STS. The credentials have an automatic expiration period.
Step 5 Workflow Uses AWS: The workflow then executes/access AWS resources based on actions that are defined in the IAM role. After the job is completed, the credentials expire, requiring no cleanup.

Configuring GitHub Actions OIDC with AWS IAM

Step 1: Create an OIDC provider in your AWS IAM for GitHub

In this step, you will set up the OpenID Provider, which is GitHub. We will be using the AWS console but you can also use AWS CLI too if that is your preference.

Log in to AWS and open the IAM console, and select Identity providers in the left navigation menu
Click Add provider button, and in the provider details, enter these details:
- Provider type: OpenID Connect
- Provider URL: https://token.actions.githubusercontent.com
- Audience: sts.amazonaws.com
- Add tags: optional

Step 2: Create an IAM role

1.In the Identity providers screen, select the provider you just created and choose the Assign role button. Select Create new role and then choose Next.

Select Identity provider

Select Assign role

Select Create new role

2.Select Web identity and provide these details
- Identity provider: token.actions.githubusercontent.com
- Audience: sts.amazonaws.com
- GitHub organization: Provide your GitHub organization.
If you don't have a GitHub organization, you can use Creating a new organization from scratch to create one.

Select Web identity

Web identity details

3.On the Permissions page, search for AmazonS3FullAccess and select it for this demo, and select Next to continue
S3 Permissions

4.In the next step, enter a role name, for this demo, GitHubAction-AssumeRoleWithAction. You can optionally add a description. Review and click Create role.
Review and create role

Step 3: Create a trust policy condition to restrict access by repository, branch, or environment

In the IAM console, select the newly created role, GitHubAction-AssumeRoleWithAction, and choose the Trust relationship tab and select Edit trust policy.
Copy and paste this policy into the editor and save the changes. Make sure to replace <AWS_ACCOUNT_ID> with your AWS account ID, <OWNER> with your GitHub username, <REPO_NAME> with your repository name and <BRANCH> with your branch name.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:<OWNER>/<REPO_NAME>/ref:refs/heads/<BRANCH>"
                }
            }
        }
    ]
}

Understanding OIDC Token Claims (Advanced but Important)

When GitHub issues the OIDC token, it includes several claims that AWS evaluates in the trust policy. The most important claim is the sub (subject). The sub claim typically follows this format:

repo:OWNER/REPO:ref:refs/heads/BRANCH

example

repo:my-org/my-repo:ref:refs/heads/main

This means that the workflow is running in my-org/my-repo and it was triggered from the main branch. Restricting by repository name means that any branch in that repo can assume the role, but if you restrict by branch, only workflows from that branch can assume the role. This is the best security practice because it prevents:

Malicious pull requests
Feature branches gaining production access and
Unauthorized role assumption This is where OIDC becomes truly powerful — it allows fine-grained, identity-based authorization instead of relying on static secrets.

Step 4:Optional:

You can attach more permissions policies, either AWS or custom policies (remember to use the principle of least privilege), to the IAM role, defining what AWS actions are allowed when using the role.

Step 5: Add the IAM Role ARN to the GitHub repository as secrets

1. In your GitHub account, create a repo or select an existing repo that you want to use. The repo I am using is "Zero-Trust CI/CD: Using OIDC to Authenticate GitHub Actions to AWS".
2. Select the repo settings and, in the left menu, select Secrets and variables. Choose Actions in the sub menu and click on the New repository secret button. Add these details
- Name: AWS_OIDC_ROLE_ARN
- Secret: arn:aws:iam:::role/. NOTE Copy the role ARN and add it as a secret. You are now ready to use it in your workflows.

Step 6: Create a workflow to use the role ARN and specify the AWS region

In this next step, we will validate the integration of OIDC with AWS. To do this we will create a workflow. Create this workflow

.github/workflows/create-s3-bucket.yml

name: Create S3 Bucket with OIDC

on:
  workflow_dispatch:

permissions:
  id-token: write
  contents: read
  pull-requests: write
  security-events: write

jobs:
  create-bucket:
    runs-on: ubuntu-latest

    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v5.1.0
        with:
          role-to-assume: ${{ secrets.AWS_OIDC_ROLE_ARN}}
          role-session-name: GitHubAction-AssumeRoleWithAction
          aws-region: us-east-1


      - name: Create S3 bucket
        run: |
          aws s3api create-bucket \
            --bucket just-another-new-bucket-124 \
            --region us-east-1

Test the OIDC Connection by running the workflow.

Workflow ran successfully.

S3 bucket created

Conclusion

Building a secure CI/CD pipeline forms a crucial part of modern software development. Storing long-lived credentials in CI/CD pipelines is a bad security practice that is still being used by some teams. OIDC offers a better alternative for enhancing your workflows using identity-based and short-lived credentials. This approach reduces your attack surface and simplifies credentials management. Your pipelines still rely on stored AWS Access keys; the question is no longer “Why switch to OIDC?”
It’s “Why haven’t you switched yet?” Modern CloudOps is identity-driven. If you're still using static credentials in 2026, it's time to upgrade your pipeline security posture. I'd like to find out from you how you manage AWS credentials using GitHub Actions. Have you tried the OIDC approach? Please let me know in the comments.

AWS Community Builder Applications for 2026 is Now Open! Here's Why You Should Apply.

KUSEH SIMON WEWOLIAMO — Thu, 08 Jan 2026 17:15:46 +0000

I remember last year, I had a couple of people in my DM asking me how they could become an AWS Community Builder. Well,

it is that time of the year again when you get the opportunity to join and become an AWS Community Builder. This community is made up of AWS enthusiasts who are willing to learn and share their knowledge and expertise on AWS. By joining this amazing community, you get to network with like-minded people ready to help accelerate their growth. I have personally gained so much from being an AWS Community Builder.

The benefits that you get when you join AWS Community Builder include:

$500 AWS credits for personal projects
Discounted re:Invent tickets
A free AWS certification voucher
Learn about new services and features.
Exclusive trainings and events
Premium swag and resources

This community is mainly focused on AWS, but this year the aperture has been widened to bring in more builders who are not heavy users of AWS yet. What this means is that if you are someone who creates high-quality content in the areas of AI, MCP, containers, open-source projects, etc., then you are welcome to apply and be part of this amazing community.

Please DM me or get in touch with any current AWS Community Builder if you're interested and would need more information about the application process. You can also ask questions in the comments section, and I'll be pleased to assist you.

Apply using this link: https://lnkd.in/efmwMgcs

Best of luck.

Mastering AWS Lambda Layers: Build, Deploy, and Manage Reusable Components

KUSEH SIMON WEWOLIAMO — Mon, 02 Jun 2025 12:17:51 +0000

Introduction
Understanding Lambda Layers
- How Layers Work
- Layer Versions
- Benefits of Using Lambda Layers
- Common Use Cases for AWS Lambda Layers
Creating Your First Lambda Layer
- Prepare and package your Lambda layer Content
- Create and Publish your Lambda Layer in AWS
- Use the Layer in Your Lambda Function
Advanced Layer Techniques
- Multi-language Layers
- Layer Size Optimization
- Automated Layer Updates
Best Practices for Lambda Layers
Conclusion
References and Additional Resources

Introduction

Serverless computing is a computing technique and an execution model that enables you to build and run application code without having to think about provisioning and managing servers and/or back-end infrastructure. In AWS Lambda, a serverless service is the backbone when it comes to building serverless applications on AWS. AWS Lambda allows you to focus on your application code while it handles infrastructure management, auto-scaling and other heavy lifting.

As your serverless applications grow in complexity and the number of Lambda functions becomes numerous, certain challenges, such as dependency management and code reuse, are inevitable. To address these issues, our hero , Lambda Layers, comes to the rescue. In this article we will explore everything you need to know about Lambda Layers, from the basics to some advanced concepts.

Understanding AWS Lambda Layers

A lambda layer is a special container, a .zip file archive that contains supplementary code or data. Lambda layers serve as a distribution mechanism for function dependencies, custom runtime, or configuration files for your Lambda functions. Layers let you keep your function deployment packages small and organized by separating your function business logic code from its dependencies.

In the diagram shown above, using the traditional approach without layers, each of the Lambda functions packages contains everything it needs to function. Lambda Function A includes requests, pyshorteners , qrcode dependencies and custom runtime libraries (logging, authentication), along with its business logic code, (requests, pyshorteners, qrcode). Function B also uses the same dependencies and custom runtime libraries, plus its own business logic. With this approach, you can clearly see there is code duplication across the two functions, leading to larger deployment packages.

The optimized approach as shown in the diagram using Lambda Layers showsthat , both functions A and B now only contain their business logic code which has much smaller packages and dependencies requests, pyshorteners, qrcode are bundled into a layer. The custom runtime libraries (logging, authentication) are also put in another layer that is shared by both functions.

How Layers Work

A layer essentially bundles code or data into a ZIP archive that is automatically extracted by the lambda service into the /opt directory in your function’s execution environment. Your function code can then access the Layer's content during its execution.

Lambda Layers operate using a simple workflow.

1. First, you package your function's, dependencies or shared code into a ZIP file.
2. You then create and publish the Layer to the Lambda service.
3. After creating the layer, you can attach the layer to one or more lambda functions.
4. When your function executes, it can then access the Layer's content as if it were part of the function's deployment package.
5. You can then update the layer and create different versions of the layer depending on your needs.

Lambda allows you to add up to a maximum of five Layers per function, and the layer content still counts towards the function's deployment package size quota (i.e. 250MB for .zip file archives).
NOTE All the packages in your layer must be Linux compatible, since Lambda functions run on Amazon Linux.

The diagram above depicts three Lambda functions A, B, and C each function containing its own business logic code.Three shared Lambda layers, Layer 1, Layer 2 and Layer 3 are mounted at /opt in function A and B execution environments whiles Layer 1and Layer 2 are mounted at /opt in function C execution environment.

Layer 1 contains the common libraries that are used most frequently,such as requests and boto3 by most AWS applications. Layer 2, packages some custom utilities such as authentication and logging functionalities. Layer 3 bundles some ML models, that is only used by Functions A and B but function C doesn't use this layer.

Layer Versions

Lambda layers are versioned. A layer version is an immutable snapshot of a layer's specific release. When you add a new layer, Lambda creates a new layer version with the version number 1. When you publish an update to a layer, Lambda automatically increments the version number by 1 and creates a new layer version. Each layer version has a unique Amazon Resource Name (ARN). When adding a layer to a function, ensure you specify the layer version you wish to use.

Benefits of Using Lambda Layers

1.Reduced the size of a function's deployment packages:Instead of including all of your function dependencies in your deployment package, place them in a layer. This keeps deployment bundles simple and manageable.
2.Separation of Concerns: Layers can help separate your function's business logic from its dependencies and allows different team members to focus on different aspects of the application.
3.Code Reusability:Layers allow you to share dependencies across multiple lambda functions. Without layers, you need to include the same dependencies in each of your function's deployment package which goes agains the the DRY (Don't Repeat Yourself) principle in programming.
4.To use the Lambda console code editor:The code editor is a helpful tool for rapidly evaluating small changes to function code. However, if your deployment package is too big, you won't be able to use the editor. Layers allow you to use the code editor and reduce the size of your package.
5.Faster Deployment Times:When you use smaller Lambda deployment packages, your Lambda uploads are faster, resulting in faster function updates. This efficiency is especially useful in CI/CD pipelines, where deployment speed influences overall development velocity.

Common Use Cases for AWS Lambda Layers

1.Database Connectors: Database drivers and connectors in applications often include some complex dependencies, bundling such dependencies in a layer ensures that your database access patterns are uniform for all your Lambda functions.
2.Monitoring and Logging Utilities: You may have some instrumentation code used for monitoring, logging, and tracing in your applications, it is best practice to use a shared layer that can easily be used across functions without any changes. This makes sure that your applications uses the same observability best practices.
3.Internal Company Libraries: Many organisations mostly develop their own internal tools and libraries. Packing these tools and libraries as Layers encourages reuse and standardisation in multiple projects in the organization.
4.Frameworks and SDKs: Layers can be used to package complete frameworks or SDKs, ensuring that there is some consistency in functions. This approach is good for organization-specific frameworks or some huge third-party SDKs that might otherwise bloat your function packages.

Real-World Example of using layers

Shared Authentication Layer
Authentication is a common action that is often implemented in many applications and frequently needed by multiple lambda functions. A shared authentication layer that standardize the authentication process is commonly used for this functionality. An example of such functionality is demostrated in the code below.

# In the Lambda Layer (python/lib/python3.9/site-packages/auth_utils.py)
import jwt
import os

def verify_token(token):
    """Verify JWT token and return payload if valid"""
    try:
        secret = os.environ['JWT_SECRET']
        payload = jwt.decode(token, secret, algorithms=['HS256'])
        return {'valid': True, 'payload': payload}
    except jwt.InvalidTokenError:
        return {'valid': False, 'error': 'Invalid token'}
    except Exception as e:
        return {'valid': False, 'error': str(e)}

Multiple functions that need authentication can then use this shared athentication layer as in the below code:

# In the Lambda function
import json
from auth_utils import verify_token

def handler(event, context):
    # Extract token from event
    auth_header = event.get('headers', {}).get('Authorization', '')
    token = auth_header.replace('Bearer ', '') if auth_header else ''

    # Verify token
    result = verify_token(token)

    if not result['valid']:
        return {
            'statusCode': 401,
            'body': json.dumps({'error': 'Unauthorized'})
        }

    # Continue with authorized operation
    user_id = result['payload']['sub']
    # ...

Creating Your First Lambda Layer

In this section i will walk you through the process of creating and using Lambda Layers. In this demo i will be creating a python application that generates a short url given a long url. The main dependencies, will be bundled in a lambda layer.

First we will create a python virtual environments at install all the neccessory dependencies

Prepare and package your Lambda layer Content

Step 1 Creat a Python virtual environment

  python -m venv venv

Step 2 Activate the virtual environment and install the dependcies in the requiremnets.txt file

  source venv/Scripts/activate
  pip install -r requirements.txt

Step 3 Create a directory called python

  mkdir python

Important: The directory structure matters! Python packages must be in a directory named python to be automatically added to the PYTHONPATH when the layer is attached to a Lambda function.
Step 4 copy the content in venv/Lib/site-packages/ directory to python/

   cp -r venv/Lib/site-packages/* python/

Step 4 Zip the content of the python directory

  zip -r python.zip python

Create and Publish your Lambda Layer in AWS

Method 1:Using AWS Console

Login into your AWS account and open the AWS Lambda console
Navigate to Layersin the left navigation
Choose Create layer
Enter details:
- Name: Give your layer a descriptive name (e.g., url-shortener-lib)
- Description(Optional): enter a description of what's in the layer
- Upload ZIP: Upload your layer zip,python-layer.zip file. You can upload directly from you computer or Amazon S3
- Compatible architectures(Optional): Select one value or both values.
- Compatible runtimes(Optional): Select the appropriate runtimes (e.g., python 3.10 python 3.11 python 3.12, etc.)
- License(Optional): enter any necessary license information
Choose Create to publish your layer

Method 2:Using AWS CLI

  aws lambda publish-layer-version \
    --layer-name url-shortener-lib \
    --description "Layer contains all the dependecies for the url-shortener lambda function" \
    --zip-file fileb://python-layer.zip \
    --compatible-runtimes python3.10 python3.11 python3.12

Important: If the size of your python.zip file is greater than 10mb, it is recommended to uplaod the zip file to an S3 bucket and use the object ARN.

Create a Lambda Function

Method 1:Using AWS Console

Open the AWS Lambda console
Click the "Create function" button
Choose one of the creation options:
- Author from scratch: Start with a basic function ✅
- Use a blueprint: Use pre-built templates
- Container image:Deploy from a container image
- Browse serverless app repository: Use existing applications 4 Choose Author from scratch:
  - Function name: Enter a descriptive name (url-shortener)
  - Runtime: Select your preferred runtime (Python 3.12)
  - Architecture: Choose x86_64 or arm64
  - Permissions: Choose Create a new role with basic Lambda permissions
Click "Create function"
Upload the code from the python script, url-shortener.py.

Method 2: Using AWS CLI

  # Create a basic Lambda function
aws lambda create-function \
    --function-name url-shortener \
    --runtime python3.12 \
    --role arn:aws:iam::YOUR_ACCOUNT_ID:role/lambda-execution-role \
    --handler lambda_function.lambda_handler \
    --zip-file fileb://function.zip \
    --description "My url-shortener function"

Use the Layer in Your Lambda Function (url-shortener)

Now you can attach this layer to any Lambda function:

Method 1:Using AWS Console

Navigate to your Lambda function ,url-shortener
Go to the "Layers" section below the code editor
Click "Add a layer"
Select "Custom layers"
Choose your layer and version
Click "Add"

Method 2:Using AWS CLI

aws lambda update-function-configuration \
  --function-name url-shortener \
  --layers arn:aws:lambda:<REGION>:<ACCOUNT-ID>:<lLAMBDA LAYER NAME>:<VERSION>

Replace <REGION> and <ACCOUNT-ID> <lLAMBDA LAYER NAME> and <VERSION> with the respective values

Testing Your Lambda Function.

After you have successfully created your function and layer ,we need to test to make sure everything is working fine.

Click on the "Test" tab (located near the top, next to "Code" and "Configuration")
If this is your first test, you'll see "Configure test event"
Click Create new event
Give your test event a name (url_url-shortener)

{
  "url": "https://www.example.com/very/long/path/to/some/resource?param1=value1&param2=value2"
}

Click test.

expected response

{
  "statusCode": 200,
  "headers": {
    "Content-Type": "application/json"
  },
  "body": "{\"original_url\": \"https://www.example.com/very/long/path/to/some/resource?param1=value1&param2=value2\", \"short_url\": \"https://tinyurl.com/abc123\"}"
}

Advanced Layer Techniques

Multi-language Layers

A single Layer can support multiple runtimes by including the appropriate directory structure for each. For example:

layer-content/
├── python/
│   └── lib/
│       └── python3.9/
│           └── site-packages/
│               └── shared_package/
└── nodejs/
    └── node_modules/
        └── shared-package/

This approach is particularly useful for cross-language utilities or when implementing polyglot applications.

Layer Size Optimization

Your lambda layers, just like function deployment packages, have a size limit of 250 MB unzipped file. In order to optimize your layer size:

Only include production dependencies in your layer; make sure to exclude any development and testing dependencies that will bloat your layer size
Use specific and selective imports for large libraries, for example, do not import a whole library but rather import specific components that you need.
Try and compress static assets when possible
Remove some unnecessary files like documentation and examples, which are likely to increase the size of your layer
Always consider splitting very large dependencies into multiple Layers

Automating Layer Updates

When you have dependencies that require frequent updates, it is best you consider automating these layer updates:

You can first create a CI/CD pipeline that will:
- periodically checks for dependency updates
- builds a new Layer version when updates are available
- publishe the new Layer version
- and optionally updates functions that depend on the layer to use the new version
You can also use AWS EventBridge to trigger the pipeline on a schedule or in response to security breaches
Add testing and validation of new Layer versions before deployment.

Best Practices for using Lambda Layers

The following section describes the best practices that will help you get the most out of Lambda Layers.It is not everything belongs in a Layer. You should consider these guidelines as best practices when you want to opt for layers:

You only use layers when you want to share dependencies across multiple functions
You have large libraries that would bloat your lambda function packages
You want to use custom runtimes and some Organization-wide utilities
Separating your function business logic from dependencies.
Consider versioning your lambda layers for layer stability
Ensure you regularly scan Layer dependencies for vulnerabilities, and also make sure to audit third-party packages before including them in your Layers
As much as possible, avoid including sensitive data or any credentials in Layers
Monitor and debug functions that use layers. ## Conclusion AWS Lambda Layers represent are a great tool that lets you keep your function deployment packages small and organized by separating your function business logic code from its dependencies. This article dived deep into what lambda layers are, how to create and use layers and some advance concepts and best practices. ## References and Additional Resources

This blog post was last updated on May 21, 2025, and reflects the current Lambda Layers functionality as of that date.

AWS Trust Policy Complete Guide: How to Control IAM Role Access in 2025

KUSEH SIMON WEWOLIAMO — Wed, 28 May 2025 09:16:43 +0000

Introduction
What is AWS Trust Policy?
Trust Policy vs. Permission Policy
How trust Policy Works
Common Use Cases of Trust Policies
Best Practices for Trust Policies
Conclusion
References

Introduction

Most AWS architects and developers create and use IAM roles but do not understand how the permissions described in the policies attached to a role are assigned to principals. The permissions assigned to the principal are always temporary and short-lived. These short-lived credentials are generated by AWS Security Token Service (STS), but wait – what ensures that the right principals assume a role? In this article we will look at AWS Trust Policy, the security gatekeeper that ensures that the right principal can assume a role to perform its actions.

What is AWS Trust Policy?

A trust policy is a type of AWS resource-policy that controls which principals and under which conditions can assume a role. Trust policy essentially enforces " who can wear this hat" and under what condition. You can think of trust policy as the "front door" to a role, before anyone can use the permissions define in the role, they must first pass a trust policy to verify their eligibility.

Basic Trust Policy Structure

Just like AWS traditional policy document, a trust policy is made up of 3 main components,statement, Effect and Action, but because this is a resource -based policy there is an additional component, the Princpal that is required.

Trust Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

How trust Policy Works

First the principals, IAM user, AWS service or Federated Users (SAML/OIDC) will request to assume a role
The trust policy will then evaluate the request based on,who is making the request, if there are any conditions specified and Whether if the actions are allowed.
If the request is comming from right principal who is allowed to assume the role and meets the conditions specified, the request is approved.
If approved, the principal gets temporary credentials, Permission policies then control what actions the assumed role can perform on AWS resource

Principal Types

The principal component of a trust policy defines which principals can assume a role. The table below summarizes the various types of principals that can be used with a trust policy.

Principal Type	Example	Use Case
Service	`"Service": "lambda.amazonaws.com"`	AWS services assuming roles
AWS	`"AWS": "arn:aws:iam::123456789012:user/john"`	IAM users, roles, or accounts
Federated	`"Federated": "arn:aws:iam::123456789012:saml-provider/ExampleProvider"`	Identity federation
Root	`"AWS": "arn:aws:iam::123456789012:root"`	Entire AWS account

Adding Conditions to Trust Policies

It is possible to add conditions to a trust policy. Conditions add extra security layers and it is best practice to use conditions in your trust plocies.
EXAMPLE Require MFA

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/AdminUser"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "NumericLessThan": {
          "aws:MultiFactorAuthAge": "3600"
        }
      }
    }
  ]
}

EXAMPLE Restrict by Source IP

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/RemoteUser"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Trust Policy vs. Permission Policy

Trust Policy	Permission Policy
Controls who can assume the role	Controls what the role can do
Attached to the role itself	Attached to the role or inherited
Uses `sts:AssumeRole` action	Uses various AWS service actions
Defines principals (who)	Defines resources and actions (what)

Common Use Cases of Trust Policies

Trust policies are fundamental to AWS security architecture and enable secure, temporary access patterns without sharing long-term credentials.
Cross-account access: Allow users in Account A to access resources in Account B
Service roles: Allow AWS services (like EC2, Lambda) to access other AWS resources
Federation: Enable users from external identity providers to access AWS resources
Temporary access: Grant time-limited access to external parties or contractors
CI/CD pipelines: Allow deployment tools to assume roles for automated deployments

Common Trust Policy Examples

1. Allow EC2 Service to Assume Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

2. Allow Specific AWS Account to Assume Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

3. Allow Specific IAM User to Assume Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/DevOpsEngineer"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

4. Cross-Account Access with External ID

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-12345"
        }
      }
    }
  ]
}

5. Web Identity Federation (for Mobile/Web Apps)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": "your-app-client-id"
        }
      }
    }
  ]
}

6. SAML Federation

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": "your-app-client-id"
        }
      }
    }
  ]
}

Best Practices for Trust Policies

1.Principle of Least Privilege: Only grant assume role permissions to entities that actually need them
2.Use External IDs: For third-party access to prevent confused deputy attacks
3.Add Conditions: Use conditions to restrict when and how roles can be assumed
4.Regular Audits: Periodically review who has permission to assume critical roles
5.Avoid Wildcards: Be specific about which principals can assume roles and avoid using the wildcard,*.
6.Monitor Usage: Use CloudTrail to monitor role assumption activities

Conclusion

Security is paramount when it comes to the cloud. In this article, we dive deep into one of the security features of AWS, AWS Trust Policy, which controls who can assume an IAM role. In my next article, we will examine the service that generates temporal and short-lived credentials, AWS Security Token Service (STS). Till then, it's a bye for now. Don't forget to add a comment

References

Ultimate Guide to Using NGINX as a Reverse Proxy and Load Balancer:Best Practices and Tips

KUSEH SIMON WEWOLIAMO — Wed, 26 Feb 2025 16:06:43 +0000

What is NGINX and Why Use It?

Nginx (pronounced "engine-X) is an open-source high-performance HTTP web server that can also be used as a reverse proxy. Other uses cases of nginx include Load Balancing, API Gateway,SSL/TLS Termination and Content caching. Over the years Nginx has grown to become one of the most popular and widely used webserver for its high performance, scalability, and low resource usage. Some companies that use Nginx include Uber Netflix,Instagram,Airbnb etc.

This article will demonstrate how to configure and use Nginx as a Reverse proxy and a Load Balancer. We will configure nginx as reverse proxy and load balancer to distribute traffic between three django applications. Before we dive into the details of configuring nginx , lets first understand what reverse proxy and load balancer are.

Understanding Reverse Proxy and Load Balancing

What is a Reverse Proxy? A reverse proxy( proxy means to act on behalf ) is a special type of server that sits in front of other webservers and directs requests from clients (such as web browsers) to those servers. Reverse proxies are often used to improve security, performance, and dependability.

What is Load Balancing?Load balancing is a technique of distributing computational workloads between two or more computing nodes. Load balancing is often employed to evenly distribute network traffic among several servers. This reduces the strain on each server and makes the servers more efficient, speeding up performance and reducing latency.

Setting Up NGINX as a Reverse Proxy and Load Balancer

Prerequisites
To follow this guide, you should have

A Linux OS, preferably ubuntu.
Basic knowledge of using the terminal.
Docker Installed. The Official documentation will guide you through how to install Docker
Nginx Installed . You can follow the official Documentation to install Nginx on your preferred OS.

Step 1 Setting up docker Containers
We will be setting up 3 docker Containers to server as the backend servers.
The docker containers run will be running a django blog application.

1. Create a directory on your computer for the project:

  mkdr projects/DjangoApps

2. cd into the directory you created

  cd projects/Djangoapps

3. Create a docker-compose.yml file

 touch docker-compose.yml

open the docker-compose.yml file and past this code

version: '3'

services:
  app1:
    image: kodecapsule/django-blog-app:dark-server
    container_name: dark-server
    ports:
      - "8000:8000"
    restart: always

  app2:
    image: kodecapsule/django-blog-app:green-server
    container_name: green-server
    ports:
      - "8001:8000"
    restart: always

  app3:
    image: kodecapsule/django-blog-app:blue-server
    container_name: blue-server
    ports:
      - "8002:8000"
    restart: always

The above docker-compose.yml file setsup three Docker containers running different versions of the same Django blog application,
each tagged with a different server name (dark-server, green-server, blue-server) from the Docker Hub repository kodecapsule/django-blog-app.
Each container is mapped to a unique host port (8000, 8001, 8002) so they can be accessed individually, while internally all containers listen on port 8000. The restart: always policy ensures that the containers automatically restart if they fail or if the Docker service restarts.

4. Run the docker containers

 docker-compose up

This will download and run three docker containers dark-server, green-server and blue-server.Open your browser and make sure you are able to access the three applications

dark-server .
green-server
.
blue-server

Step 2 Configure NGINX as a Reverse Proxy
Nginx configuration is always in nginx.conf file. The nginx.conf file is the main file that is mainly used to configure nginx behavior.
By default this file is located in /etc/nginx/nginx.conf .

  worker_processes 1; 
  events{
     worker_connections 1024;
  }
  http{
      include /etc/nginx/mime.types;

      upstream django_servers {
              server localhost:8000;
              server localhost:8001;
              server localhost:8002;
          }  

      server {
        listen 8080;
        # Proxy requests to Django backend
        location / {
            proxy_pass http://django_servers;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;

            # Handle timeouts
            proxy_connect_timeout 60;
            proxy_read_timeout 60;
        }

    }


  }

The server context defines all the configuration needed for nginx to act as a reverse proxy.The NGINX configuration above defines a server with the listen directive listening on port 8080.
To configure Nginx as a reverse proxy the proxy_pass directive is used which enables nginx to forward all incoming requests to a group of backend Django servers. It sets headers like Host, X-Real-IP,
and X-Forwarded-For to pass client information to the backend servers, preserving the original request details.

Additionally, it configures timeout settings (connect and read) to control how long NGINX waits for a response from the backend servers, ensuring smooth handling of slow responses or potential server delays.

Step 3 Configure Nginx as a Load Balancer

configure nginx as load bala using round-robin

    upstream django_servers {
              server localhost:8000;
              server localhost:8001;
              server localhost:8002;
          }

The upstream block defines a load balancer named django_servers, which distributes incoming requests across the three Django application instances running on ports 8000, 8001, and 8002 on localhost.
By default, NGINX uses a round-robin strategy, sending each new request to a different server in sequence to balance the load.
This setup helps improve performance and reliability, as traffic is spread across multiple instances, preventing any single server from being overwhelmed.
You can read more about Using nginx as HTTP load balancer
Open your browser and enter localhost:8080. Reload several the site several time to see how nginx is able to route the traffic between the three servers.
Other load balancing algorithms that can be used are Weighted load balancing, Least connected load balancing,ip-hash

Common Errors and Troubleshooting

Below are some list of some errors you are likely to face when

🛑 1. NGINX Fails to Start or Reload
NGINX won't start or reload after changing the configuration. This is usually causee by Syntax or configuration errors in your nginx.conf
solution: Run a config test to catch syntax errors:

  nginx -t

If there's an error, it will show the line and reason, like this

 nginx: [emerg] "server" directive is not allowed here in /etc/nginx/nginx.conf:34

Fix the error, then restart nginx:

  sudo systemctl restart nginx

📛 2. 502 Bad Gateway
The browser shows a 502 Bad Gateway error. This error occures when nginx can't reach the backend servers ( Django containers).
Some common reasons maybe backend server(s) down or misconfigured, incorrect proxy_pass address, port mismatches (e.g., app runs on port 8000, but NGINX tries 8001).
solution:Check and make sure the backend servers are running.

⏳ 3. 504 Gateway Timeout
If the browser shows a 504 Gateway Timeout error , the error might be due to backend server(s)
takeing too long to respond, or NGINX can't establish a connection to the servers.
This maybe due to slow application responses (e.g., long-running DB queries) or timeout values are too low.

Solution:
Increase timeout settings in nginx.conf

  proxy_connect_timeout 120;
  proxy_read_timeout 120;
  proxy_send_timeout 120;

🚩 4. Connection Refused
If you have connection refused in logs this may likely be due to the backend server not accepting connections or is bound to the wrong address.

Solution:
Ensure the app listens on the right IP:

⚠️ 5. Load Balancer Not Distributing Traffic Properly

If you have only one server getting all the traffic, or traffic doesn't balance as expected.This maybe due to the default round-robin behavior or sticky sessions or caching issues.
Solution:
Check and make sure the you are using the right load balancing algorithm:

Default round-robin behavior:

  upstream django_servers {
            server localhost:8000;
            server localhost:8001;
            server localhost:8002;
          }

Least Connections behavior:

  upstream django_servers {
            least_conn;
            server localhost:8000;
            server localhost:8001;
            server localhost:8002;
          }

IP Hash behavior:

  upstream django_servers {
            ip_hash;
            server localhost:8000;
            server localhost:8001;
            server localhost:8002;
          }

Conclusion and Next Steps

Nginx is a versatal webserver that can be used as a reverse proxy and load balancer for any web application.
With Nginx's simple configuration and vast ecosystem, you'll have plenty of flexibility to adapt to your application's evolving needs.
So, what's next? Explore how to configure nginx for SSL/TLS termination connections, caching static content and other features of Nginx.

References and Additional Resources

https://nginx.org/
https://nginx.org/en/docs/http/load_balancing.html
https://en.wikipedia.org/wiki/Nginx
https://www.keycdn.com/support/nginx

Avoiding Playbook Failures:Techniques to Handle Errors in Ansible Like an Expert

KUSEH SIMON WEWOLIAMO — Tue, 18 Feb 2025 12:21:20 +0000

Article Outline

1. Introduction
2. Techniques to Handling Errors in Ansible
3. Breakdown of Error Handling in Ansible
4. Error handling Best practices
5. Conclusion
6. References

1. Introduction: Why Error Handling Matters in Ansible

Ansible, an open source IT automation tool used for configuration management, software provisioning and application deployment is
widely used among DevOps, Cloud and IT professionals. Ansible's main strengths are it's simplicity, agentless architecture and ease of use as compared to other tools in that domain. Despite Ansible's strengths unexpected failures can and will occur due to unreachable hosts, failed commands, or misconfiguration etc.If failures are not handled properly, these errors can disrupt entire deployments and cause downtime.

Writing robust playbooks with proper error handling in Ansible is essential to ensure reliability and resilience in your Ansible automation workflows.
In this article I will take you through common techniques and methods that can assist you to properly handle errors in playbook

2. Techniques to Handling Errors in Ansible

There are several techniques for handling errors in Ansible include using ignore_errors, failed_when ,block and rescue ,any_errors_fatal etc. In this section we dive into some of these techniques and methods and how and when to use each technique.

Ignoring Failed Commands: When Failure is Acceptable

Ansible will stop executing the current task and subsequent task(s) when it encounters an error and will stop executing a playbook entirely when there is an error in one of the task.
The "ignore_errors" directive allows continues executing of subsequent task(s) despite the failure of a task. The ignore_errors directive only works when the task is able to run and returns a value as "failed". This can be useful in scenarios where certain failures are expected or do not impact the overall automation process.
You can use ignore_errors in situations where there are no non-critical tasks, testing and debugging, checking for optional dependencies and Best-Effort Action.
Bellow is an example of how to use ignore_errors.

    - name: Restart Apache (ignore failure)
      ansible.builtin.service:
         name: apache2
         state: restarted
         ignore_errors: yes

Handling Unreachable Hosts.

One other failure types that can occur in playbooks is unreachable host. This failure usually occurs when Ansible cannot establish a connection with the host. Unreachable host errors can be due to network issues, incorrect SSH credentials, or a system/server being down. By default, Ansible will stop executing the current task and the playbook on that host if that host becomes unreachable. You can use ignore_unreachable to handle a task failure due to host(s) instance being ‘UNREACHABLE. When you use the "ignore_unreachable" directive, Ansible ignores the task errors but continues to execute future tasks against the unreachable host.

Usage of ignore_unreachable a task.

   - name: This executes, fails, and the failure is ignored
     ansible.builtin.command: /bin/true
     ignore_unreachable: true

  - name: This executes, fails, and ends the play for this host
    ansible.builtin.command: /bin/true

Usage of ignore_unreachable in a playbook

  - hosts: all
  ignore_unreachable: true
  tasks:
    - name: This executes, fails, and the failure is ignored
        ansible.builtin.command: /bin/true

    - name: This executes, fails, and ends the play for this host
        ansible.builtin.command: /bin/true

Handlers and Failure: Triggering the Right Actions

In Ansible handlers are special type of tasks that only run when they are notified by another task. They are usually runned at the end of each play and normally used to Restart a service only on successful execution that service. If a task notifies a handler but the next task fails in the that same play, by default the handler will not run leaving the host in an unexpected state. To override this default behavior you can use the "force-handlers" directive either in a play or in the ansible.cfg file and Ansible will forcefully run all notified handlers.

Usage of ignore_unreachable in a playbook

- name: Demonstrate force_handlers
  hosts: webservers
  force_handlers: yes  # Ensures handlers run even if a task fails
  tasks:
    - name: Deploy a web application
      ansible.builtin.command: /usr/local/bin/deploy_app.sh
      notify: Stop Web Service  # Handler will be triggered

    - name: Simulate a failure
      ansible.builtin.command: /usr/local/bin/failing_task.sh
      ignore_errors: no  # This will fail the playbook

  handlers:
    - name: Stop Web Service
      ansible.builtin.service:
        name: nginx
        state: stopped

Defining Failure and Change: Controlling When a Task Fails

There are some situations where you will want to explicitly trigger an error when certain conditions are met.
In Ansible , a task is considered failed when it returns a non-zero erro exit code but there are certain situations you may want to override this default behavoir.
Ansible allows you to override this default behavoir by defining custom failure conditions for a task by using the "failed_when" directive.

The "failed_when" directive commonly used for handling commands that return non-standard exit codes, conditional task failures based on some logic
and preventing false failures in debugging and logging. As with all conditions in Ansible you can use the "failed_when" with "and" and "or"

Handling Commands with Non-Standard Exit Codes

- name: Run a script that exits with code 2 on success
  ansible.builtin.command: /usr/local/bin/custom_script.sh
  register: script_output
  failed_when: script_output.rc != 0 and script_output.rc != 2

Handling Conditional task failures based on some logic

- name: Check available disk space
  ansible.builtin.shell: df -h / | awk 'NR==2 {print $5}' | sed 's/%//'
  register: disk_usage
  failed_when: disk_usage.stdout | int > 90

Aborting a Play on All Hosts: When to Stop Everything

In handling errors in Ansible playbooks there maybe some situations where you may want to abort the play on all host or some number of host
when there is a failure on a single host.
The "any_errors_fatal" and "max_fail_percentage" allows you to stop a playbook execution on all host or a number of host respectively.
In critical deployments, you may want to stop everything immediately to prevent further issues, in this case you need to use "any_errors_fatal"
in your playbook.

Stopping Execution on All Hosts if a Critical Task Fails

- name: Configure firewall rules across servers
  hosts: all
  any_errors_fatal: true
  tasks:
    - name: Apply firewall rules
      ansible.builtin.iptables:
        chain: INPUT
        protocol: tcp
        destination_port: 22
        jump: ACCEPT

In the code snippets above , if one server fails to apply the rules, the playbook stops execution for all servers to prevent security inconsistencies.

Controlling Errors with Blocks, Rescue, and Always

Ansible blocks are used to group common tasks in a logical manner and all tasks in a "block" inherit directives applied at the block level.
Blocks offers ways to handle errors compared to the way exceptions are handled in common programming languages. Blocks are used together
with "rescue" and "always" to handle errors. Rescue block contains a list of task to run whenever a task in a block fails. The rescue block will
only run when a task returns a "failed" state. Bad task definitions and unreachable hosts will not trigger the rescue block.
Always block will run all the time no matter what the task status of the previous block is.
when block,rescue and always blocks directives are used together , they offer a structured way to handle complex task failures.

Installing Nginx with Apache2 as a fallback

    - name: Install web server with error handling
  hosts: all
  become: yes
  tasks:
    - name: Attempt to install Nginx with fallback to Apache
      block:
        - name: Install Nginx
          ansible.builtin.apt:
            name: nginx
            state: present
            update_cache: yes
          register: nginx_install_status

      rescue:
        - name: Log failure and install Apache2 instead
          ansible.builtin.debug:
            msg: "Failed to install Nginx, installing Apache2 instead."

        - name: Install Apache2
          ansible.builtin.apt:
            name: apache2
            state: present

      always:
        - name: Cleanup temporary files......
          ansible.builtin.file:
            path: /tmp/install_logs
            state: absent

3. Summary of Error Handling in Ansible

Scenario	Error Handling Method	Best Practice
Task fails but should not stop playbook	ignore_errors: yes	Use when failure is non-critical but log output for debugging.
Host is unreachable but should not affect others	ignore_unreachable: yes	Useful in large environments with occasional host failures.
Define custom failure conditions	failed_when	Use when command output doesn't align with default error codes.
Play should stop if any critical task fails	any_errors_fatal: true	Use for high-risk changes like database updates.
Catch task failure and attempt alternative action	block, rescue, always	Ensures graceful error handling with a fallback mechanism.
Prevent unnecessary task execution	changed_when	Avoids triggering handlers when no real changes occur.

4. Some Common Errors in Ansible Playbooks

Syntax Errors: These occurs when there are some erroneous YAML formatting or incorrect Ansible syntax.
Module Errors:Caused by specific Ansible modules with incorrect parameters or incompatible versions of the same module..
Connection Errors: Problems with SSH connections to distant hosts.ts.
Resource Unavailability: A necessary resource is either missing or unavailable.
Task Failures: Tasks may fail because they do not meet particular conditions or are executed in an inappropriate execution environment. .
Variable Errors: Variables that are undefined or wrongly declared, causing the process to fail.
Dependency Errors: Errors caused by lacking dependencies between tasks, roles, or playbook.

5. Conclusion: Making Your Ansible Playbooks More Resilient

Overall effective error handling in Ansible is very essential for building resilient and fault-tolerant automation workflows.
By using some directives like ignore_errors for non-critical failures, failed_when for custom conditions, and block/rescue/always for structured recovery etc you can ensure that your playbooks can handle errors without disrupting the entire deployment.
Thats all for now till we meet again on my next article its by for now.

6. References: More Reading

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html
https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_error_handling.html
https://medium.com/@vinoji2005/day-13-error-handling-in-playbooks-ensuring-robust-ansible-automation-%EF%B8%8F-2abb62cd52f9
https://spacelift.io/blog/ansible-handlers

How I passed the AWS Solutions Architect Associate (SAA-C03) : Resources and my study strategies and Tips.

KUSEH SIMON WEWOLIAMO — Sun, 16 Feb 2025 20:05:40 +0000

At the beginning of this year one of my goals was to become an AWS solutions architect (Associate). So earning the AWS Solutions Architect Associate certification was going to be significant achievement for me in helping me build and advance my career in cloud computing. Many organizations are increasingly migrating to the cloud and AWS continues to dominate in the market as one of the most sought-after platforms for cloud deployment. AWS certifications have become a standard for validating your AWS cloud skills.

For me, the AWS Solutions Architect Associate exam was more than just earning a badge, it was an opportunity for me to deepen my understanding of AWS services and to prove my skills in designing scalable, cost effective and resilient solutions on AWS.

In this article, I will share with you the resources and my study strategies and tips I used on my journey to becoming AWS certified. I hope my experience will serve as a guide for anyone aspiring to pass the AWS Solutions Architect Associate exam.

Understanding the Exam structure and Format

One of the most import things to consider when preparing for any exam not only SAA-C03 is to understand how the exam is structured and the areas which are covered in the exam. This gives you an idea on the areas to study and focus your attention on and prevents you from focusing and wasting your energy and resources that are not relevant.

AWS has provided a detailed exam guide which explains the composition exam structure and the services that are covered by the SAA-C03 exams. The exam is mainly based on four domains:

Domain 1 Design Secure Architectures (30%)
Domain 2 Design Resilient Architectures (26%)
Domain 3 Design High-Performing Architectures (24%)
Domain 4 Design Cost-Optimized Architectures (20%)

I personally went through this guide most of the time to help me in the areas I should focus on in my preparation for the SAA-C03 exam. I suggest you use this as a guide in your exam preparation. More about this guide use this link, https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

My Study Plan and resources I used

The resources I used are of two types, paid and free.

Free Resources.

Solutions architect -Knowledge Badge readiness path on AWS Skill Builder: AWS skill builder has some amazing course and this course is one of them. The course consists of 32 modules that helped me in my preparation journey. After completing the course, you will also receive a badge after passing a final test. https://explore.skillbuilder.aws/learn/lp/1044/Solutions%2520Architect%2520-%2520Knowledge%2520Badge%2520Readiness%2520Path.
AWS Certified Solutions Architect Associate Practice Questions Playlist on Youtube by Sthithapragna. This Playlist is one of the best resources for you to use practice for your exams. The playlist consists of 41 videos. Sthithapragna does an amazing job by explaining into details all the possible answers and some keywords that will help you in selecting the right answers. https://www.youtube.com/watch?v=4Y6lDKCAGOQ&list=PL7GozF-qZ4KeQtVB9Nt_gXwDD0HvykrsD.
AWS documentation: AWS official documentations should be your go to resources whenever you need to read more about any service that you need deeper understanding on. I constantly and always refer to the documentation when I need clarification and deeper understanding on a particular topic or service.
AWS Free tier Account: The AWS free tier account played an essential part in my learning journey. I use the free tier account for hands on experience. I practice build some projects and gained some hands on experience with using this account.

Paid Resources

I purchased Stephane Maarek’s course, Ultimate AWS Certified Solutions Architect Associate SAA-C03 on Udemy. Maarek’s is an awesome teacher and explains complex topics in simpler ways for you to understand. The material is continuously updated, and the content slides are available in PDF format. https://www.udemy.com/course/aws-certified-solutions-architect-associate-saa-c03/?couponCode=KEEPLEARNING
I also purchase Practice Exams | AWS Certified Solutions Architect Associate by Stephane Maarek and Abhishek Singh. This practice exams helped me to identify the areas that I needed to focus on. This practice text also provides detailed explanation to all the answer options with links to AWS documentations for reference. https://www.udemy.com/course/practice-exams-aws-certified-solutions-architect-associate/?couponCode=KEEPLEARNING.

My key challenges and how I overcame them

Preparing for the AWS Solutions Architect Associate exam wasn’t without some challenges and hurdles. Here’s a breakdown of some of the major challenges I faced during my preparation journey and the strategies I used to overcome those challenges.

Balancing Studies with Work and Personal Life: Managing studies alongside a full-time job and personal responsibilities was my main headache. With limited free hours during the day, I am often overwhelmed and exhausted during the day. To overcome this challenge, I had a dedicated study period in the evenings, microlearning during short breaks and on commutes to work.
Handling some knowledge gaps in AWS Services. While I had some exposure to AWS, there were some services that I had some knowledge gaps. I read detailed about some those services in AWS documentation, practice some hands-on exercise and re-watch some videos on Stephane Maarek’s course and Youtube.
Overcoming Exam Anxiety: Despite my extensive preparation, the possibility of failing the exam created anxiety, especially as the exam day got closer. Because of this anxiety I had to reschedule my exam twice. I overcame this anxiety by doing more practice and reinforcing my knowledge on some concepts.

Conclusion

As I reflect and look back on my journey to becoming an AWS Certified Solutions Architect Associate, I realise how much it has transformed me. It wasn’t just about passing exam but it was also about learning more about AWS services, getting better at using them, and feeling more confident about designing secure, cost effective, resilient and scalable solutions on AWS.

I strongly recommend anyone who is willing to taking the AWS Solutions Architect Associate exam to do so. While the journey demands much efforts and dedication, the benefits greatly exceed the challenges. This certification will help you in advancing your career in cloud computing and validating your cloud skills.

I hope this was helpful. Good luck on your certification journey.

The Ultimate guide to creating and using Terraform modules: Deploying a static Website Using Amazon S3

KUSEH SIMON WEWOLIAMO — Fri, 14 Feb 2025 07:39:39 +0000

Article Outline

Introduction
Prerequisites
What are Terraform Modules?
Anatomy of a Terraform Module
Creating a Terraform Module (Step-by-Step)
Using a Terraform Module
Upload static files to S3.
Best Practices for Terraform Modules
Conclusion

1. Introduction

Terraform, an open-source tool developed by HashiCorp and one of the most popular , if not the most popular IaC tool is widely used by Cloud and DevOps engineers. As compared to other IaC tools, terraform is widely used because it is Platform Agnostic, employs a declarative language (HashiCorp Configuration Language (HCL)) , terraform is also allows for infrastructure to be modularized enabling reusable code and keeping your code DRY(Don't Repeat Yourself). Terrafrom also has an large community and ecosystem.

As your terraform code becomes more complex, it becames difficlut to manage and that is where Terraform modules comes to the rescue. Modules are the key ingredient to writing reusable,maintainable, and testable Terraform code

In this article, i will take you through how to write reuseable modules in terraform. if you are ready grap a cap of coffe and lets get started.

2. Prerequisites

Before you get started make sure you have the following:

Basic understanding of Terraform.
AWS account with AWS CLI installed and configured
Terraform Installed CLI.

3. What are Terraform Modules?

HashiCorp defines modules as a container for multiple resources that are used together.In simple terms , a Terraform module is a list of terraform configuration files in a single diretory. Terraform module is analogous to a function in general-purpose programming constracts, they have parameters(input variables) and return values (output values). A module can be as simple as a directory with one or more confiuration files.tf files. For example you can define a resuable VPC module which might include subnets, route tables and security groups.

Benefits of using modules

Here are some benefits of using Modules in terraform:

Code Reusability: Modules makes it easier to reuse configurations written either by yourself, your team members, or other Terraform practitioners.
Encapsulation of Configuration: Modules enables you to encapsulate configurations into distinct logical components which can help prevent unintended changes to your infrastructure as a result of a change in one part of your infrastructure.
Provide consistency and ensure best practices - Modules also help to provide consistency in your configurations
Organize configuration - Modules make it easier to navigate, understand, and update your configuration by keeping related parts of your configuration together.

4. Anatomy of a Terraform Module

The file structure of a terraform module:

    module_name/
            ├── LICENSE
            ├── main.tf
            ├── variables.tf
            ├── outputs.tf
            └── README.md

LICENSE: Contains the license under which your module will be distributed
main.tf: This file contains all the main configurations for your module
variables.tf: This is where you place all the variable definitions for your module. When your module is used by others, the variables will be configured as arguments in the module block.
outputs.tf: The outputs definition for your module is placed in this file. Module outputs are made available to the configuration using the module.
README.md: This is a markdown file that describes how to use your module. This file is not used by terraform but helps people understand how to use your module.

5. Creating a Terraform Module (Step-by-Step)

In this section of the article we will be creating a terraform module that creates an S3 bucket for hosting a static website.

Step 1. Clone/Create the directory structure
You can clone this directory into your prefered location: Below is the folder structure

terrform-modules/
├──modules/
│     └──static-S3-Website-bucket/
│         ├── main.tf              
│         ├── variables.tf        
│         ├── outputs.tf
│         ├── README.md   
│         ├── www/  
│         │   ├──index.html
│         │   └── error.html
│         └── LICENSE
├── .gitignore     
├── main.tf 
├── Readme.md   
└── outputs.tf

Step 2. writing the modules variables
There are only two variables used in this module for simplicity. You can modify and add your own variables if you want.

s3-bucket-name variable: The name to assign to your S3 bucket. The bucket name should be globally unique
tags variable: Defines a tag for your bucket, defualts to Dev if you do not provide.

variable "s3-bucket-name" {
    description = "Bucket name for the static website. The name must be globally uique "
    type = string  
}
variable "tags" {
    description = "Tags to set on the bucket."
    type = map(string)

    default = {
      "env" = "dev"
    }
  }

Step 3. writing the main configuration
This file creates all the resources that are needed to create a static S3 website. There are 6 resources in all

"aws_s3_bucket" resource: Creates an S3 bucket with the name and tag you provide as input variables
"aws_s3_bucket_website_configuration" resource: Configures your S3 bucket for static website hosting
"aws_s3_bucket_ownership_controls" resource: Configures S3 Bucket Ownership Controls
"aws_s3_bucket_public_access_block" resource: Enable public access
"aws_s3_bucket_acl" resource: Defines S3 access control list (ACLs)
"aws_s3_bucket_policy" resource: Configures S3 bucket policy

resource "aws_s3_bucket" "static-website-bucket" {
    bucket = var.s3-bucket-name
    force_destroy = true
    tags = var.tags  
}

resource "aws_s3_bucket_website_configuration" "s3-website-config" {
    bucket = aws_s3_bucket.static-website-bucket.id
    index_document {
      suffix = "index.html"
    }
    error_document {
      key = "error.html"
    } 

}

resource "aws_s3_bucket_ownership_controls" "bucket-owner" {
  bucket = aws_s3_bucket.static-website-bucket.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
  depends_on = [aws_s3_bucket_public_access_block.public-acl-block]

}

resource "aws_s3_bucket_public_access_block" "public-acl-block" {
  bucket = aws_s3_bucket.static-website-bucket.id  

  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false  

}

resource "aws_s3_bucket_acl" "s3-website-bucket-acl" {
    bucket = aws_s3_bucket.static-website-bucket.id
    acl = "public-read"  
  depends_on = [ aws_s3_bucket_ownership_controls.bucket-owner ]
}

resource "aws_s3_bucket_policy" "s3-website-bucket-policy" {
    bucket = aws_s3_bucket.static-website-bucket.id
    policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "PublicReadGetObject"
        Effect    = "Allow"
        Principal = "*"
        Action    = "*"
        Resource = [
          aws_s3_bucket.static-website-bucket.arn,
          "${aws_s3_bucket.static-website-bucket.arn}/*",
        ]
      },
    ]
  })


  depends_on = [ aws_s3_bucket_public_access_block.public-acl-block ]
}

Step 4. writing the outputs configuration file
The output file defines three outputs for the S3 bucket module:

bucket's ARN
website domain
bucket id These outputs allow other configurations to reference key attributes of the static S3 website bucket after it's provisioned.

output "bucket-arn" {
    description = "ARN for the S3 bucket static website"
    value = aws_s3_bucket.static-website-bucket.arn

}


output "bucket-id" {
    description = "Id of the static S3 bu;cket"
    value = aws_s3_bucket.static-website-bucket.id

}

output "website-domian" {
  description = "Domain for the static Website"
  value = aws_s3_bucket_website_configuration.s3-website-config.website_domain
}

Step 5. writing the Readme and License files
For the README file a dettailed description of how to use the module is proivded. A sample Licence is also provided in the LICENSE file. You can generate your own licencse file using Choose a License

6 Using a Terraform Module.

Step 1. Define the module block
To use the module you need to use the module block in the main.tf file that is at the root directory and provide the required input variables.
The root module also contains the configurations for terraform and AWS provider.

module block usage

module "static-S3-Website-bucket" {
    source = "./modules/static-S3-Website-bucket"
    s3-bucket-name = "kodecapsule-website-101"

    tags = {
      Environment:"DEV"
    }
}

Terraform and AWS provider configurations


terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-east-1"
}

Combined configurations


terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-east-1"
}


module "static-S3-Website-bucket" {
    source = "./modules/static-S3-Website-bucket"
    s3-bucket-name = "kodecapsule-website-101"

    tags = {
      Environment:"DEV"
    }
}

Step 2. writing the outputs configuration file

output "website_bucket_arn" {
  description = "ARN of the bucket"
  value       = module.static-S3-Website-bucket.bucket-arn
}

output "website_bucket_name" {
  description = "Name (id) of the bucket"
  value       = module.static-S3-Website-bucket.bucket-id
}

output "website_bucket_domain" {
  description = "Domain name of the bucket"
  value       = module.static-S3-Website-bucket.website-domian
}

Step 3. Running the code
To run the code use the following commands

terraform init will initialize the project and download the neccessory provider code

terraform init

terraform plan to preview the changes that Terraform will make to your infrastructure

terraform plan

The terraform apply command is used to apply the changes defined in your Terraform configuration files

terraform apply

7 Upload static files to S3.

After terraform creates the infrastructure , you can now upload your static files into the S3 bucket.
The static files for this peoject are found in the www folder.
You can upload the files using AWS console or AWS CLI.

1.Uploading static files using AWS CLI

aws s3 cp modules/static-S3-Website-bucket/www/ s3://<YOUR-BUCKET-NAME>/ --recursive

replace with the name of your bucket

8. Best Practices for Terraform Modules

Here are some best practices to follow when writing and using modules.

Always parameterize your modules.
Follow the "DRY" Principle (Don’t Repeat Yourself)
Write Documentation for your Modules
Avoid hardcoding sensitive data (e.g., keys, passwords) in your module variables.

9. Conclusion

Well well, we have come to the end of this deep dive into terraform modules. There are other advance topics about terraform modules that are not covered in this tutorial. To learn more about terrafrom modules , visit the official Terraform page . Don't forget to add your comments , till then keep coding.

Thanks

Terraform Architecture Explained , Terraform Core, State, and Plugins: How Terraform Works Under the Hood.

KUSEH SIMON WEWOLIAMO — Fri, 14 Feb 2025 07:18:35 +0000

Article Outline

Introduction
Terraform Architecture
Terraform Workflow
Terraform Best Practices
Conclusion
References

1. Introduction

Infrastructure as Code (IaC), is an approach to managing and provisioning infrastructure by writing code instead of the manual processes , “ClickOps”. IaC can be described as a mindset where you treat all aspects of operations (servers, databases, networks) as software. When you define your infrastructure using code , it enables you to automate and use all the best practices of software development. IaC eliminates human errors , speeds up infrastructure deployments and ensures infrastructure is version-controlled, just like software code.

Terraform is an open-source tool developed by HashiCorp and the most popular and widely used IaC tool used by DevOps, SREs and cloud architects. Terraform is widely used because of it’s declarative syntax, platform agnostic and its simplicity. Understanding how terraform works behind the hood will go along way to help you in write better terraform code.

In this article, we will explore Terraform architecture, its core components, and how it orchestrates infrastructure provisioning efficiently.

2. Terraform Architecture

Terraform follows a standard architecture to fulfill the necessary IaC tasks. Terraform architecture mainly consists of the following components:

Terraform core
Plugins (Providers and Provisioners)
Terraform State

Terraform core

Terraform core is the engine/brain behind how terraform works. It is responsible for reading configurations files , building the dependency graphs from resources and data sources, managing state and applying changes. Terraform Core does not directly interact with cloud providers but communicates with plugins via remote procedure calls (RPCs) and the plugins in turn communicates with their corresponding platforms via HTTPs.

Plugins (Providers and Provisioners)

Terraform ability is enhance by plugins, which enable terraform to interact with cloud services and configure resources dynamically. Plugins acts as connectors or the glue between terraform and external APIs such as AWS, Azure, GCP, Kubernetes, Docker etc. Each plugin is written in the Go programming language and implements a specific interface. Terraform core knows how to install and execute plugins. Provisioners in Terraform are used to execute scripts or commands on a resource after it has been created or modified.

Terraform State

State is one of the most important core components of Terraform. Terraform state is a record about all the infrastructure and resources it created. It is a costumed JSON file that terraform uses to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructures. By default, state is stored in a local file named “terraform.tfstate”. You can read more about terraform state here

There are two ways to manage state:

Local State: Local State refers to the default way by which Terraform stores state files (terraform.tfstate). It is suitable for small-scale projects or development environments and single person managing Terraform.
Remote State: Remote State refers to storing the Terraform state file (terraform.tfstate) in a remote backend rather than locally on your machine. This enables collaboration, prevents state loss, and supports features like state locking and versioning. Some common remote backends include AWS S3,Terraform Cloud, Azure Blob Storage etc. More on Remote State

3. Terraform Workflow

Terraform follows a structured execution flow to provision, update, and manage infrastructure. This process ensures that infrastructure is deployed in a controlled and predictable manner. Terraform workflow consist of mainly three steps:

Write: The first step is to write your terraform configuration just like any other code using any editor of your choice.
Plan: This is the step where you review your configurations. Terraform plan will define the infrastructure to be created, modified, or destroyed depending on the current configuration and infrastructure.
Apply: The final step in the workflow is Apply, where you are ready to provision real infrastructure. Once you approve of the changes ,terraform will go ahead perform the desired actions as defined execution.

4. Terraform Best Practices

You should never edit the Terraform state files by hand or write code that reads them directly. If for some reason you need to manipulate the state file which should be a relatively rare occurrence, use the terraform import or terraform state commands.
It’s a good practice to store your work in a version controlled repository even when you’re just operating as an individual.
When working as a team, it’s important to delegate ownership of infrastructure across these teams and empower them to work in parallel without conflicts.
Never Store your state file in a version controlled repository.
Always use state locking on your state files to prevent data loss, conflicts and state file corruption.
Integrate Terraform to your CI/CD pipelines to make your DevOps pipeline efficient.

5. Conclusion

Well well, we have come to the end of this deep dive into terraform Architecture.
To learn more about Terrafrom visit the official Terraform page . Don't forget to add your comments , till then keep coding.
.

6 References

https://developer.hashicorp.com/terraform/language/state
https://thinksys.com/cloud/terraform-architecture-best-practices/
https://developer.hashicorp.com/terraform/intro/core-workflow
https://spacelift.io/blog/terraform-architecture
https://developer.hashicorp.com/terraform/cloud-docs/recommended-practices
Terraform:Up & Running , Third Edition by Yevgeniy Brikman

A Beginner’s Guide to Django Web Framework: Creating Apps, Views, Configuring URLs and Templates

KUSEH SIMON WEWOLIAMO — Mon, 05 Aug 2024 08:49:50 +0000

Building Web Applications with Django ,A Practical Guide.🏗️ 🚀🐍🌐

Capsule 2: Creating Apps ,Views, templates and configuring route

Greetings comrades Welcome back to our Django tutorial series! it’s another week and we need to take our KodeCapsule of the week. In the previous article we, covered the foundations of Django framework, it’s architecture, Models, Views, templates and how to start a new project in Django. If you have not read the last article I suggest you go back and read that article, here before continuing. So, grab a cap of coffee and let’s dive in.

Outline of Article

Introduction
What is an app in Django?
Creating an App in Django
Creating Views for your App
Creating URLs for your app
Adding templates to your app
Conclusion
References

Introduction

In this tutorial we will dive deep into building and working with the core components of any Django project. We will look at how to create apps in Django, configuring settings, creating views to handle request and setting up URL routes. By the end of this tutorial, you should understand

How to create a new app in Django
How to include this app in your project’s settings
How to define URL patterns for your app
How to write views to display request and response
How to add templates to your app

Let’s Get Started!!!!!!!

What is an App in Django?

An app in django is a module that performs a specific function. An app can be as simple as a feature in your project like a contact form or a fully-fledged component such as a blog or a payment system. Apps are designed to be reusable across different projects. Organizing your code into apps enable code reusability, maintainability and scalability. The difference between an app and a project is that, an app does a specific function in your project and can be used in multiple projects but a project consists of a collection of configurations, apps for a particular website. Some key characteristics of an app are:

Modularity: Django Apps are modular in nature which means that you can develop and test your apps independently and reuse them. This makes your project more organized and manageable.
Reusability: Since apps are self-contained, you can easily reuse them in other Django projects. For example, you can create a blog app for one project and use the same app in another project without modifications.
Separation of Concerns: Each app handles a specific aspect of your project. This separation makes it easier to manage different parts of your application.
Encapsulation: Apps encapsulate models, views, templates, static files, and other components related to a specific functionality, keeping them organized within their own directories.

Creating an App in Django

In the previous article we have already setup our project. We will create our first app. This app is going to be a blog application.

1.To create the app, navigate into your project folder and in your terminal and run this command. Make sure you have activated your virtual environment.

python manage.py startapp blog

This command creates a new directory with all the necessary setup files in a folder structure described below:

├── blog/
│ ├── migrations/
│ │ └──init.py
│ ├── init.py
│ ├── admin.py
│ ├── apps.py
│ ├── models.py
│ ├── tests.py
│ └── views.py

I. migrations/: This folder stores all the database migrations for your app

II. init.py: This is an empty file that informs python to treat that directory as a python package.

III. admin.py: A configuration files for django admin interface. The function of admin.py file is to register your apps models in the django admin panel. We will look at Django admin later

IV. apps.py: This contains configurations for the app and can include the app’s metadata as well.

V. models.py: This script is where we fine the data models for our app.

VI. tests.py: The test.py script is where you write test cases for your app

VII. views.py: This script contains the views you define for your app. The views handle the business logic for your application.

2.Add your blog app into the list of installed apps in the project settings.

INSTALLED_APPS = [ 'django.contrib.admin', 
'django.contrib.auth', 
'django.contrib.contenttypes', 
'django.contrib.sessions', 
'django.contrib.messages', 
'django.contrib.staticfiles', 

#my apps
'blog',
]

Creating Views

Views play an important role in your application. The business logic for your application is defined in Views. Views act as the glue between the presentation layer and the data layer. There are two main types of views in Django, Function-based views and Class-based views (more details about this in the upcoming articles). In this tutorial we will stick to using function-based views.

1.Open the views.py file in your blog app

2.Import HttpResponse from the http package

from django.http import HttpResponse

3.Define a function called home (you can name the function whatever you want). The function will return an HttpResponse

from django.http import HttpResponse

 def home(request):
      return HttpResponse("<h1>Welcome to the Home Page</h1>")

Creating URLs for your App

For users to access different sections of your web app, you have to define access points for each feature/functionality of your app; in Django you do so by creating urls for your app. URLs patterns are mapped to specific views.

In Django, you can define all the urls for your project in the project urls.py script, but it is best practice to create a separate urls.py script for individual apps in your project.

1.In the blog app directory create a urls.py script.

2.Import the path function from the urls package in django. The path function takes three arguments, route, view, kwargs and name and returns an element. You can read more about this function here.

from django.urls import path

3.Import the views for your app

from . import views

4.Create a list called urlpatterns an define a url for the home page, this list is similar to the list in the project urlpatterns.

urlpatterns = [ path('', views.home, name='home_page' ]

5.Update the project’s urls. To make your app accessible you need to update the main project urls.py . Open your project’s urls.py file and import the include function from urls package and update the urlpatterns list.

 from django.contrib import admin
 from django.urls import path, include

 urlpatterns = [
     path('admin/', admin.site.urls),
    path('', include('blog.urls')),
   ]

6.After that save all your files and start the development server, using the usual command

python manage.py runserver

Open the url in your browser and the default django home page changes the response from the home function.

Adding templates to your App

In the previous section the repose from the home view return an http response that contains an HTML header tag. What if we want to return a whole page that contains a whole lot of HTML tags, what can we do? That’s where templates in django come in. Django templates allows you to define the HTML structure that will be displayed in the user's browser. Templates allow you to generate dynamic content using the Django Templating Language (DTL). In Django you put your templates in your app or at the root of your application( more details about django templates in my upcoming articles).

1.Create a template directory: create a template directory in your blog app. In the template directory create another directory called blog.
2.Create a template. Create and HTML file called

myproject/
    blog/
        templates/
            blog/
                index.html

3.Update the index.html file with this code:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Blog App</title>
</head>
<body>
 <h1>Welcome to the Home page</h1>
 <p>Lorem ipsum dolor, sit amet consectetur adipisicing elit. Voluptas maiores, modi facilis veritatis amet eum labore odio sit nemo eius?</p>
  </body>
</html>

4.Update the home view: Open your views file and import render from shortcuts. Update the function body to return the index.html using the render function.

from django.shortcuts import render
def home(request):
   return render(request, 'blog/index.html')

Save the changes and reload your browser.

Conclusion

We have come to the end of this week’s Kodecapsule . In this article we looked at creating your first app in django, creating views, configuring urls and rendering templates in django. In the next article we will take a look at models and templates into details.

Be sure to watch out for the articles in this series as I take you from Zero to an expert in Django.
Your Suggestions and Comments are always welcome.
Kuseh Wewoliamo

References

https://docs.djangoproject.com/en/5.0/topics/http/views/
https://docs.djangoproject.com/en/5.0/topics/templates/
https://docs.djangoproject.com/en/5.0/ref/urls/#include
https://docs.djangoproject.com/en/5.0/ref/urls/#path
https://www.w3schools.com/django/django_create_app.php

A Beginner’s Guide to Django Web Framework: Django from Novice to Expert

KUSEH SIMON WEWOLIAMO — Sun, 28 Jul 2024 16:00:46 +0000

Building Web Applications with Django ,A Practical Guide.🏗️ 🚀🐍🌐

Capsule 1, Introduction to Django

Greetings comrades, it’s another brand-new day and we need to take our KodeCapsule of the week. I will be starting a tutorial blog series on one of the most popular python web development framework (WDF), Django. This tutorial series will take you from an absolute beginner to an expert in using Django to build web apps and REST APIs. So, stay turned and enjoy the cruise as we dive into the world of Django.

Outline of Article

Introduction
What is Django?
Benefits of Django
Architecture of Django
Installing and Setting up Django
Django project folder structure
Conclusion
References

Introduction

What is a Web development Framework (WDF)?

Before we take a look at what Django is, lets first get to understand what a WDF and why we need web frameworks. In Simple terms a web development Framework (WDF) is a collection of tools that are purposely designed to help in the development of web applications including web services, web resources and web APIs. WDFs provide a standard approach to build and deploy web applications on the World Wide Web. The goal of WDFs is to automate the overhead associated with common activities that are carried out in web development. Some popular WDFs are,_ .NET (C#), Django(Python), Ruby on Rails (Ruby) Express (JavaScript/Node.js), Laravel (PHP), Spring Boot(Java)._

What is Django?

Django, as describe on the Django website, ( The web framework for perfectionists with deadlines) is a high-level Python web framework that encourages rapid development, clean and pragmatic design. It was created to help web developers move from applications concept to completion as quickly as possible. With Django, you can build and deploy web applications in less time with few lines of code. Django is designed by skilled developers and helps to handle a lot of the hassle of web development, so you can focus on writing your application without having to reinvent the wheel. Django is also an open-source project that was released in 2005. You can learn more about Django here.

Benefits of Django

Fast Development: Django is designed based on the “batteries-included” philosophy which simply means that Django comes with a lot of baked in features and tools out of the box for faster application development. Django offers a lot of built-in features (Django’s ORM,Authentication system etc) and functionalities that developers commonly use when building applications.
Highly Secured: Django has a lot of build in security features that helps app developers avoid a number of common security mistakes by providing a secure way to manage user accounts and passwords through its built-in authentication system. Django also has features that offer protection against common web exploits such as cross-site scripting (XSS), cross-site request forgery (CSRF) and SQL injection.
Scalable: One other benefit of using Django is that it enables your applications to scale smoothly. Django can scale quickly to handle huge volumes of traffic demands from the smallest to the largest web applications.
Versatile: Whether you’re building a content management system, a social network, a REST API, machine learning application, Scientific computing platforms, Django provides you with all the tools you need to build any type of web application.

Architecture of Django

Django is designed based on the Model View Template (MVT) architecture. MVT is a software design pattern.

Model: The model is the data access layer that is responsible for handling the data-logic and defines the structure for storing the application data in a database. Models are independent of the types of database used because Django has an inbuilt Object relational Mapper (ORM) that maps Python classes to database tables.
View: The view is the “glue” between the Model and the Template. The view handles the business logic. The view receives request from the user via a template, process the data using a model and return a response. A View in Django is the same as a controller in other frameworks like spring boot that uses the MVC architecture.
Template: The presentation layer is the template which is responsible for handling the layout and structure of the user facing application. The template defines how data should be presented to the user. The template contains static content such as HTML, CSS and JavaScript usually injected with Django Template Language (DTL) which allows dynamic content to be inserted into a template.

Note: Django has a URL dispatcher that maps URLS to corresponding views. Find more details about the URL dispatcher here.

Installing and Setting up Django

Step 1. Installing Python on your Computer

You have to have some basic knowledge of Python programming language.
Make sure you have Python installed on your computer. If you have not installed python visit the python website and follow the instructions for installing python on your preferred operating system. I will be using Windows OS in this tutorial series. Download and install Python.

Step 2. Setting Up a Virtual Environment, Installing Django and starting your first project.

A virtual environment is an isolated environment in which you can work on your Python projects independently of the Python that is installed on your system. You can set up the libraries and dependencies that your project needs without affecting the main Python libraries installed on your system.

1.Install virtualenv: virtualenv is a tool that is use to create isolated Python environments. To install virtualenv run this command in your terminal.

pip install virtualenv

2.Create a Virtual environment: Create a folder for your project and cd into the project folder in your terminal and run this command.

py -m venv django_venv

3.Activate virtual environment : To activate the virtual environment cd into your virtual environment using this command.

django_venv/scripts/activate

4.Install Django: Install Django in the virtual environment using this command.

pip install django

5.Confirm Django installation: To confirm that Django is install type this command. This command list Django and other modules that Django uses.

pip freeze

6.Start your first project: To start your first project run this command

django-admin startproject myproject .

7.Run development Server: cd into myproject folder and start the development server by running this command

python manage.py runserver

8.The development server will start at http://127.0.0.1:8000/ Copy the url to your browser. Congrats you have successfully installed and start a new project

Django project folder structure

Django organizes and structure your project into separate and different components. This structure encourages code reusability, maintainability, and scalability. When you created the new django project using this command, django-admin startproject myproject, in the previous section, the following directory structure was generated.

├── myproject/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── manage.py

manage.py: This script is a command-line tool that allows you to interact with your Django project. It contains collection of commands that you can use to perform various task in your Django project like starting the development server, running tests, and perform other administrative tasks.
init.py: This is an empty file that informs python to treat that directory as a python package.
settings.py: This script is the heart of your Django project. It contains all the settings and configurations for your project and determines how Django behaves. Some common settings include database settings, installed apps, template directories, middleware and more. Settings Reference: https://docs.djangoproject.com/en/5.0/ref/settings/
urls.py: This script defines all the URL patterns for your project. It acts as a URL dispatcher, mapping all incoming URLs (request) to specific views that handle those requests. Refer to the official Django documentation for a deeper understanding of URL patterns and the urls.py file, https://docs.djangoproject.com/en/5.0/topics/http/urls/
wsgi.py: This script is used by the web server to serve your application. Web Server Gateway Interface (WSGI) acts as a mediator that is responsible for conveying communications between a web server and a Python web application. It’s essential for deploying Django apps.
asgi.py:This script acts as the entry point for ASGI compatible web servers to serve your Django project. Asynchronous Server Gateway Interface (ASGI) is used to handle asynchronous tasks. ASGI is a spiritual successor to WSGI, intended to provide a standard interface between async-capable Python web servers, frameworks, and applications.

Conclusion

Well well , we have come to the end of the this weeks Kodecapsule. In this article we were introduced to Python web framework, Django, the benefits of using Django, it’s architecture and created our first project. In the next article we will take a look at Django apps, creating our own apps and getting our hands “dirty”.

Be sure to watch out for the articles in this series as I take you from Zero to an expert in Django.

_Your Suggestions and Comments are always welcome.

Kuseh Wewoliamo_

References

https://www.python.org/

https://www.djangoproject.com/

https://docs.djangoproject.com/en/5.0/ref/settings/

https://en.wikipedia.org/wiki/Django_(web_framework)

https://medium.com/@commbigo/wsgi-vs-asgi-for-python-web-development-9d9a3c426aa9

https://docs.djangoproject.com/en/5.0/howto/deployment/wsgi/

https://builtin.com/data-science/wsgi

https://www.freecodecamp.org/news/how-to-setup-virtual-environments-in-python/

Forem: KUSEH SIMON WEWOLIAMO

Stop Storing AWS Access Keys in GitHub Secrets — Use OIDC Instead to Authenticate GitHub Actions to AWS

Introduction

How GitHub Actions OIDC integrates with AWS to access resources

Configuring GitHub Actions OIDC with AWS IAM

Step 1: Create an OIDC provider in your AWS IAM for GitHub

Step 2: Create an IAM role

Step 3: Create a trust policy condition to restrict access by repository, branch, or environment

Understanding OIDC Token Claims (Advanced but Important)

Step 4:Optional:

Step 5: Add the IAM Role ARN to the GitHub repository as secrets

Step 6: Create a workflow to use the role ARN and specify the AWS region

Conclusion

AWS Community Builder Applications for 2026 is Now Open! Here's Why You Should Apply.

Mastering AWS Lambda Layers: Build, Deploy, and Manage Reusable Components

Table of Contents

Introduction

Understanding AWS Lambda Layers

How Layers Work

Layer Versions

Benefits of Using Lambda Layers

Common Use Cases for AWS Lambda Layers

Real-World Example of using layers

Creating Your First Lambda Layer

Prepare and package your Lambda layer Content

Create and Publish your Lambda Layer in AWS

Method 1:Using AWS Console

Method 2:Using AWS CLI

Create a Lambda Function

Method 1:Using AWS Console

Method 2: Using AWS CLI

Use the Layer in Your Lambda Function (url-shortener)

Method 1:Using AWS Console

Method 2:Using AWS CLI

Testing Your Lambda Function.

Advanced Layer Techniques

Multi-language Layers

Layer Size Optimization

Automating Layer Updates

Best Practices for using Lambda Layers

AWS Trust Policy Complete Guide: How to Control IAM Role Access in 2025

Table of Contents

Introduction

What is AWS Trust Policy?

Basic Trust Policy Structure

How trust Policy Works

Principal Types

Adding Conditions to Trust Policies

Trust Policy vs. Permission Policy

Common Use Cases of Trust Policies

Common Trust Policy Examples

Best Practices for Trust Policies

Conclusion

References

Ultimate Guide to Using NGINX as a Reverse Proxy and Load Balancer:Best Practices and Tips

What is NGINX and Why Use It?

Understanding Reverse Proxy and Load Balancing

Setting Up NGINX as a Reverse Proxy and Load Balancer

Common Errors and Troubleshooting

Conclusion and Next Steps

References and Additional Resources

Avoiding Playbook Failures:Techniques to Handle Errors in Ansible Like an Expert

Article Outline

1. Introduction: Why Error Handling Matters in Ansible

2. Techniques to Handling Errors in Ansible

Ignoring Failed Commands: When Failure is Acceptable

Handling Unreachable Hosts.

Handlers and Failure: Triggering the Right Actions

Defining Failure and Change: Controlling When a Task Fails

Aborting a Play on All Hosts: When to Stop Everything

Controlling Errors with Blocks, Rescue, and Always

3. Summary of Error Handling in Ansible

4. Some Common Errors in Ansible Playbooks

5. Conclusion: Making Your Ansible Playbooks More Resilient

6. References: More Reading

How I passed the AWS Solutions Architect Associate (SAA-C03) : Resources and my study strategies and Tips.

Understanding the Exam structure and Format

My Study Plan and resources I used

My key challenges and how I overcame them

Conclusion

How GitHub Actions OIDC integrates with AWS to access resources