DEV Community: Rajesh Murali Nair

Deploy-Time Intelligence in AWS CDK: Custom Resources in Action

Rajesh Murali Nair — Mon, 19 Jan 2026 15:48:43 +0000

Introduction

In real-world AWS platforms, a single CDK codebase is often deployed across multiple AWS accounts, each representing a different environment such as development, staging, or production.

While AWS CDK excels at defining infrastructure, it has a limitation:
it cannot make decisions at deploy time based on values stored inside the account, such as values stored in AWS Systems Manager (SSM) Parameter Store.

In this blog, we solve a practical platform-engineering problem using a Lambda-backed Custom Resource to make environment-aware decisions when installing an EKS Helm add-on.

The Real-Life Problem

You are a platform engineer managing EKS clusters across multiple AWS accounts:

Environment	Expectation
Development	Low cost, minimal redundancy
Staging	Production-like but smaller
Production	High availability

Your organization already stores the environment type centrally as an SSM parameter:

/platform/account/env

with values like:

development
staging
production

Now you want to install **ingress-nginx **on every EKS cluster, but configure it differently:

development → replicaCount = 1
staging / production → replicaCount = 2

Why Not Use CDK Context? (Short Version)

At first glance, CDK context variables may seem like a simpler solution for environment-based configuration. However, context values are resolved at synthesis time, not during deployment. This means they must be provided externally (via cdk.json or CI/CD pipelines) and are unaware of account-level metadata such as values stored in SSM Parameter Store. In multi-account platforms, this often leads to manual coordination, configuration drift, and governance issues. Since the environment classification already lives inside the AWS account and should be owned by the platform, using a deploy-time Custom Resource ensures the configuration is accurate, consistent, and centrally controlled.

Why CDK Alone Is Not Enough

AWS CDK evaluates logic during synthesis, but the SSM parameter value is only reliably available during deployment.

This means:

You cannot use CDK if statements
You cannot hardcode environment values
You cannot rely on CDK context safely

What you need is deploy-time logic.

The Solution: Lambda-Backed Custom Resource

A Custom Resource allows CloudFormation to:

Invoke a Lambda function during stack creation or update
Wait for the result
Consume returned attributes as inputs for other resources

In this case, the Custom Resource:

Reads the environment value from SSM
Computes the correct Helm value
Returns it to CDK
CDK passes it into the Helm chart

Architecture Overview

Deployment flow:

CDK creates:
- EKS cluster
- SSM parameter /platform/account/env
- Lambda function
Custom Resource triggers the Lambda
Lambda computes Helm values
Helm chart is installed using returned values

This keeps:

One CDK codebase
Zero manual steps
Environment-aware behavior

CDK Stack Code (Python)

Below is the CDK stack that creates:

EKS cluster
SSM parameter
Lambda function
Custom Resource
Helm chart with dynamic values

from aws_cdk import (
    Stack,
    aws_eks as eks,
    aws_ec2 as ec2,
    aws_iam as iam,
    aws_ssm as ssm,
    aws_signer as signer,
    aws_lambda as _lambda,
    custom_resources as cr,
    CustomResource,
    Token
)
from aws_cdk.lambda_layer_kubectl_v34 import KubectlV34Layer
from constructs import Construct
import os

class TestStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, *, vpc: ec2.IVpc = None, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        aws_account_id = self.node.try_get_context("aws-account-id")

        # Create EKS Cluster
        cluster = eks.Cluster(
            self, "MyEKS",
            version=eks.KubernetesVersion.V1_34,
            endpoint_access=eks.EndpointAccess.PUBLIC_AND_PRIVATE,
            default_capacity=0,
            default_capacity_instance=ec2.InstanceType.of(
                ec2.InstanceClass.T3,
                ec2.InstanceSize.MEDIUM
            ),
            kubectl_layer=KubectlV34Layer(self, "kubectl"),
            vpc=vpc,
            vpc_subnets=[
                ec2.SubnetSelection(
                    subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS
                )
            ],
            cluster_name="MyEKS",
            tags={"Name": "MyEKS", "Purpose": "Swisscom-Interview"}
        )

        # EKS Admin Access
        admin_user = iam.User(self, "EKSAdmin")
        cluster.aws_auth.add_user_mapping(
            admin_user, groups=["system:masters"]
        )

        # Store environment in SSM
        ssm.StringParameter(
            self, "MyEnvParam",
            parameter_name="/platform/account/env",
            string_value="development",
            description="Environment Name"
        )

        # Lambda code signing
        signing_profile = signer.SigningProfile(
            self, "SigningProfile",
            platform=signer.Platform.AWS_LAMBDA_SHA384_ECDSA
        )

        code_signing_config = _lambda.CodeSigningConfig(
            self, "CodeSigningConfig",
            signing_profiles=[signing_profile]
        )

        # Lambda Function
        fn = _lambda.Function(
            self, "MySSMParamLambda",
            runtime=_lambda.Runtime.PYTHON_3_13,
            handler="index.lambda_handler",
            code=_lambda.Code.from_asset(
                os.path.join(
                    os.path.dirname(__file__),
                    "lambda_functions"
                )
            ),
            environment={
                "SSM_PARAM_NAME": "/platform/account/env"
            },
            code_signing_config=code_signing_config
        )

        fn.add_to_role_policy(
            iam.PolicyStatement(
                actions=["ssm:GetParameter"],
                resources=[
                    f"arn:aws:ssm:{self.region}:{self.account}:parameter/platform/account/env"
                ]
            )
        )

        # Custom Resource Provider
        provider = cr.Provider(
            self, "EnvToHelmProvider",
            on_event_handler=fn
        )

        env_cr = CustomResource(
            self, "EnvToHelmValues",
            service_token=provider.service_token
        )

        replica_count = Token.as_number(
            env_cr.get_att("ReplicaCount")
        )

        # Install ingress-nginx Helm chart
        cluster.add_helm_chart(
            "nginx-ingress",
            chart="nginx-ingress",
            repository="https://helm.nginx.com/stable",
            namespace="kube-system",
            values={
                "controller": {
                    "replicaCount": replica_count
                }
            }
        )

Lambda Code (Custom Resource Logic)

This Lambda:

Reads the environment from SSM
Computes the correct replica count
Returns values back to CloudFormation

import boto3
import os
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

ssm = boto3.client("ssm")
PARA_NAME = os.environ["SSM_PARAM_NAME"]

def get_parameter(para_name):
    parameter = ssm.get_parameter(Name=para_name)
    env = parameter["Parameter"]["Value"].strip().lower()

    if env == "development":
        value = 1
    elif env in ["staging", "production"]:
        value = 2
    else:
        raise ValueError(
            f"Invalid environment {env} in SSM Parameter {para_name}"
        )

    logger.info(
        f"Computed replicaCount={value} for env={env}"
    )

    return {
        "Environment": env,
        "ReplicaCount": value
    }

def lambda_handler(event, context):

    if event.get("RequestType") == "Delete":
        return {
            "PhysicalResourceId": event.get(
                "PhysicalResourceId", "env"
            ),
            "Data": {}
        }

    data = get_parameter(PARA_NAME)

    return {
        "PhysicalResourceId": f"{PARA_NAME}:{data['Environment']}",
        "Data": data
    }

Why This Pattern Works Well

This approach provides:

Single CDK codebase
Environment-aware behavior
No manual Helm overrides
Deploy-time decision making
Testable business logic

It scales well as you add more add-ons such as:

cert-manager
external-dns
cluster-autoscaler
logging agents

Conclusion

AWS CDK is declarative by nature, but real platforms require deploy-time intelligence. By combining Lambda-backed Custom Resources with CDK, you can make infrastructure decisions based on real account metadata, not hardcoded assumptions.

This pattern is a powerful tool for platform teams aiming for consistency, safety, and automation across environments.

Building a Receipt-Scanning Feature for a Budgeting App with Amazon Bedrock

Rajesh Murali Nair — Tue, 16 Dec 2025 12:57:17 +0000

Introduction

While building a budgeting app, I identified a feature that had value beyond personal expense tracking. By enabling users to scan supermarket receipts, the application can extract structured purchase data and analyze individual spending patterns automatically.

This capability not only simplifies budgeting for users but also highlights a broader opportunity for the retail industry. Receipt-level data can provide insights into consumer behavior and enable retailers to deliver more targeted, data-driven promotional offers tailored to specific customers.

Problem Statement: Manual Expense Tracking Doesn’t Scale

Tracking expenses manually is time-consuming and error-prone. Most budgeting applications rely on users to enter purchase details by hand, which often leads to incomplete data and poor long-term adoption.

Supermarket receipts contain rich information—item names, prices, categories, totals—but this data is usually locked away in unstructured formats such as images or PDFs. Without automation, extracting and organizing this information becomes a significant challenge, limiting both accurate budget tracking and deeper spending analysis.

This problem becomes more pronounced as transaction volume grows, making a scalable, automated receipt-processing solution essential.

Feature Overview

The receipt-scanning feature allows users to capture supermarket receipts and automatically convert them into structured expense data within the budgeting app.

From a user’s perspective, the workflow is simple:

The user uploads a photo of a supermarket receipt.
The application processes the image and extracts key purchase details such as store name, items, prices, total amount, and purchase date.
The extracted data is then categorized and stored, making it immediately available for budget tracking and spending analysis.

By automating this process, the feature removes the need for manual expense entry while enabling more accurate, item-level insights into consumer spending patterns.

Architecture Walkthrough: Receipt Processing Pipeline

This section walks through the architecture shown above, focusing on how each AWS service contributes to the receipt-scanning feature, from ingestion to persistent storage.

The goal of this design is to keep the workflow event-driven, scalable, and simple, while clearly separating responsibilities between OCR, AI reasoning, and data storage.

Architecture Diagram

1. Ingestion: Uploading Receipts to Amazon S3

The workflow starts when a user uploads a receipt image using either a mobile application or a web interface.

All receipt images are stored in an Amazon S3 bucket named receipts
S3 acts as a durable, cost-effective entry point for unstructured data (images)
The bucket is configured with an event notification that triggers processing as soon as a new object is uploaded

Using S3 for ingestion removes the need for a dedicated API layer just to accept images and ensures uploads scale automatically with usage.

2. Event Trigger: AWS Lambda (`receipt-analyzer`)

When a new receipt image is uploaded, S3 triggers an AWS Lambda function called receipt-analyzer.

When a new receipt image is uploaded, S3 triggers an AWS Lambda function called receipt-analyzer.

This Lambda function acts as the orchestrator for the entire pipeline:

It reads the S3 event metadata
Coordinates calls to downstream services
Normalizes and persists the final output

Because Lambda is event-driven and serverless, the system only runs compute when a receipt actually arrives.

import json
import boto3
from datetime import datetime
from decimal import Decimal

# Initialize clients
textract = boto3.client('textract', region_name='us-east-1')
bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
dynamodb = boto3.resource('dynamodb', region_name='us-east-1')

# Configuration
BEDROCK_MODEL_ID = 'anthropic.claude-3-sonnet-20240229-v1:0'
DYNAMODB_TABLE_NAME = 'receipt-processing-results'

def convert_floats_to_decimal(obj):
    """Recursively convert float values to Decimal for DynamoDB compatibility"""
    if isinstance(obj, list):
        return [convert_floats_to_decimal(item) for item in obj]
    elif isinstance(obj, dict):
        return {key: convert_floats_to_decimal(value) for key, value in obj.items()}
    elif isinstance(obj, float):
        return Decimal(str(obj))
    else:
        return obj

def lambda_handler(event, context):
    # Extract S3 bucket and object key from event
    bucket_name = event['Records'][0]['s3']['bucket']['name']
    document_name = event['Records'][0]['s3']['object']['key']

    # Step 1: Extract raw text using Textract OCR
    textract_response = textract.detect_document_text(
        Document={'S3Object': {'Bucket': bucket_name, 'Name': document_name}}
    )

    # Step 2: Concatenate lines of text
    text_lines = [block['Text'] for block in textract_response['Blocks'] if block['BlockType'] == 'LINE']
    full_text = "\n".join(text_lines)

    # Step 3: Prepare prompt for Bedrock
    prompt = f"""You are an AI assistant that extracts structured data from receipts. Given the receipt text below, return a JSON with the following fields:
- supermarket_name
- location (address)
- items (list of item name and price)
- total_amount
- date_of_purchase

Receipt Text:
\"\"\"
{full_text}
\"\"\"

Return only the JSON object, no explanation."""

    # Step 4: Invoke Bedrock
    bedrock_response = bedrock.invoke_model(
        modelId=BEDROCK_MODEL_ID,
        contentType='application/json',
        accept='application/json',
        body=json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 1024,
            "messages": [
                {
                    "role": "user",
                    "content": prompt
                }
            ],
            "temperature": 0.3,
            "top_p": 0.9
        })
    )

    # Step 5: Parse Bedrock response
    response_body = json.loads(bedrock_response['body'].read().decode())
    model_output = response_body['content'][0]['text'].strip()

    # Try to parse model output as JSON
    try:
        extracted_data = json.loads(model_output)
    except json.JSONDecodeError:
        extracted_data = {"error": "Failed to parse response", "raw_output": model_output}

    # Step 6: Convert floats to Decimal for DynamoDB
    extracted_data_decimal = convert_floats_to_decimal(extracted_data)

    # Step 7: Save to DynamoDB
    table = dynamodb.Table(DYNAMODB_TABLE_NAME)

    # Create DynamoDB item
    dynamodb_item = {
        'document_id': document_name,
        'bucket_name': bucket_name,
        'processed_timestamp': datetime.utcnow().isoformat(),
        'extracted_data': extracted_data_decimal,
        'raw_text': full_text
    }

    try:
        # Save to DynamoDB
        table.put_item(Item=dynamodb_item)

        return {
            'statusCode': 200,
            'body': json.dumps({
                'message': 'Receipt processed and saved successfully',
                'document_id': document_name,
                'extracted_data': extracted_data  # Return original for JSON serialization
            })
        }
    except Exception as e:
        return {
            'statusCode': 500,
            'body': json.dumps({
                'error': 'Failed to save to DynamoDB',
                'details': str(e),
                'extracted_data': extracted_data
            })
        }

3. Text Extraction: Amazon Textract

The first processing step inside the Lambda is optical character recognition (OCR) using Amazon Textract.

Textract extracts raw text from the receipt image
All detected LINE blocks are concatenated into a single text representation
No assumptions are made about receipt layout or formatting

At this stage, the data is still unstructured—just plain text—but it provides a reliable foundation for semantic analysis.

4. Semantic Parsing: Amazon Bedrock (Claude 3 Sonnet)

Once raw text is extracted, the Lambda invokes Amazon Bedrock using the anthropic.claude-3-sonnet model.

Instead of trying to manually parse receipts with rules or regex, the model is prompted to reason over the text and return a clean JSON structure containing:

Supermarket name
Store location
Item list (name and price)
Total amount
Date of purchase

The prompt explicitly instructs the model to:

Return only JSON
Follow a fixed schema

This approach dramatically simplifies downstream processing and makes the output predictable enough for database storage.

5. Persistence: Amazon DynamoDB

After successful extraction, the structured result is stored in Amazon DynamoDB, in a table named receipt-processing-results.

Each receipt is saved as a single item with the following attributes:

document_id (String, primary key)
bucket_name
extracted_data (structured JSON)
processed_timestamp
raw_text (original OCR output)

Example of extracted_data field:

{
  "location": {
    "S": "Markt 54, 3431 LB Nieuwegein"
  },
  "items": {
    "L": [
      {
        "M": {
          "name": {
            "S": "S. MARIA TORTILLA W.W"
          },
          "price": {
            "N": "2.99"
          }
        }
      }
    ]
  },
  "total_amount": {
    "N": "2.99"
  },
  "date_of_purchase": {
    "S": "14/06/2025"
  },
  "supermarket_name": {
    "S": "Dirk van den Broek"
  }
}

DynamoDB was chosen because it:

Scales automatically with receipt volume
Provides low-latency access for dashboards and queries
Works well for item-centric access patterns (one receipt per item)

Storing both structured data and raw text allows future reprocessing if extraction logic or prompts improve.

Why This Architecture Works Well

This design has a few key advantages:

Fully serverless – no servers to manage or scale
Event-driven – processing happens only when new data arrives
Separation of concerns – OCR, reasoning, and storage are cleanly isolated
Extensible – easy to add user IDs, GSIs, or analytics pipelines later

It also keeps the system flexible: Textract can be swapped or enhanced, prompts can evolve, and DynamoDB schemas can grow without breaking the ingestion flow.

Conclusion

This feature demonstrates how a focused, single-purpose workflow can deliver meaningful value when built with the right AWS services. By combining Amazon S3, AWS Lambda, Amazon Textract, Amazon Bedrock (Claude 3 Sonnet), and Amazon DynamoDB, unstructured receipt images are transformed into structured, queryable data with minimal operational complexity.

The event-driven, serverless design scales automatically with usage and keeps costs aligned with demand. Separating OCR from AI-based reasoning also makes the solution flexible—models, prompts, or extraction logic can evolve over time without requiring architectural changes.

Most importantly, this approach removes manual effort for users while creating a strong foundation for future capabilities such as spending analytics, budget insights, and personalized recommendations. With small incremental extensions, this same architecture can support more advanced financial intelligence use cases without sacrificing simplicity or scalability.

Exam Guide : GitHub Foundation Part 2

Rajesh Murali Nair — Mon, 01 Sep 2025 12:42:12 +0000

Contribution to open-source project on GitHub

Find an Open-Source Project That Needs Contributions

The easiest way to start contributing is to look at the projects you already use or want to use. Since you’re familiar with them, you’ll have a better understanding of how they work and where they can improve.

Here are some common opportunities to contribute:

Fix typos or broken links in the README or documentation.
Update outdated documentation to make it clearer for new users.
Report bugs or fix small issues you’ve encountered.
Add tests or improve existing test coverage.
Improve accessibility or translations to make the project more inclusive.

Understand Project Guidelines Before Contributing

Every open-source community is unique, with its own culture and participation rules. Once you’ve found a project you’d like to contribute to, take time to familiarize yourself with its guidelines. This ensures your contributions align with the project’s expectations and community standards.

Most open-source repositories include key documents at the top level:

LICENSE – Defines how the project can be used, shared, or modified. If no license is present, the project is not truly open source.
README – The welcome page of the project, usually explaining what it does, how to get started, and how to engage with the community.
CONTRIBUTING – Provides step-by-step instructions for contributing, including setup details and the review process.
CODE_OF_CONDUCT – Outlines expected behavior and community standards, ensuring a safe and welcoming environment.

Identify Tasks to Work On

Once you’ve chosen a project and reviewed its contribution guidelines, the next step is to find tasks where you can contribute.

You might start small—fixing a broken link, updating documentation, or reporting a bug you’ve noticed. To discover structured opportunities:

Visit the project’s /contribute URL, which highlights beginner-friendly issues.
Look for labels such as:
- good first issue – simple issues ideal for new contributors.
- help wanted – tasks where maintainers are actively seeking assistance.
- beginner-friendly – issues designed to welcome new contributors.
- discussion – opportunities to provide input or feedback.

Sponsor a project

Contributing to open source isn’t limited to writing code—financial support is also a powerful way to give back. Many open-source projects are maintained by volunteers who dedicate their time and skills to building, securing, and improving the tools we all rely on.

With GitHub Sponsors, you can directly fund individuals or projects. Sponsorship helps maintainers:
Continue improving their projects.
Cover costs for infrastructure, tools, or security.
Receive recognition for their work and community impact.

Contribute to an open-source repository

Once you’ve identified a task or area to contribute, the next step is preparing your contribution. Success in open source isn’t just about writing code—it’s also about clear communication and collaboration.

Why Communication Matters

It prevents duplication of effort (two people working on the same issue).
It ensures your contribution aligns with the project’s goals and practices.
It fosters collaboration and makes it more likely your work will be accepted.

Communicate Your Intent to Maintainers

Before diving into any work, it’s important to communicate your intent to contribute. This helps avoid duplication, ensures alignment with project goals, and opens the door for feedback from maintainers.

Working on an existing issue
- Check the Assignees section to see if anyone is already working on it.
- Look at the Linked pull requests section—if there’s a PR, someone may already be addressing the issue.
- Read through the comments to confirm no one else has claimed it.
- If the issue is available, post a comment to state your interest. This signals to others that you’re taking it on and invites maintainers to provide guidance.
Proposing a new issue or feature
- If your bug or feature isn’t listed in the issue tracker, create a new issue.
- Follow any issue template provided.
- Clearly explain the problem, your proposed solution, and your intent to work on it.
- For larger features or changes, wait for maintainer approval before moving forward.

Manage an InnerSource program by using GitHub

What is InnerSource?

Open source allows anyone to freely use, view, modify, and share software, with the belief that open collaboration leads to better and more reliable solutions.

InnerSource applies these open-source practices inside an organization. In other words, it’s like running an open-source project behind your company’s firewall. An InnerSource program mirrors the structure of open source—issues, pull requests, discussions—but limits access to the company’s employees.

Benefits of InnerSource

Internal Visibility
- Developers gain access to other teams’ code, issues, and project plans.
- Encourages code reuse and learning from existing solutions.
- Improves productivity by reducing duplication of effort.
Reduced Friction
- Teams dependent on fixes or new features can directly propose changes.
- If contributions can’t be merged, consumer teams can fork the project to meet their needs.
- Creates smoother collaboration between otherwise siloed teams.
Standardized Practices
- Promotes consistent contribution models across teams.
- Standardizes how processes and communication are documented.
- Makes it easier for any developer in the company to contribute to any project.

Set up an InnerSource program on GitHub

Set repository visibility and permissions

GitHub repositories can be configured with different visibility levels and permission levels to control who can see and interact with your project.

Repository Visibility

Public
- Visible to everyone, inside and outside your organization.
- Best for open-source projects.
Internal (GitHub Enterprise only)
- Visible only to members of the enterprise.
- Ideal for InnerSource projects.
Private
- Visible only to the repository owner and explicitly added users or teams.
- Use this for projects requiring restricted access.

Users who don’t meet the visibility requirement will see a “not found” page when trying to access the repo.

Repository Permission Levels

Once visibility is set, you can assign fine-grained permissions:

Read – View and discuss the project (good for non-code contributors).
Triage – Manage issues and pull requests without write access.
Write – Push code and actively contribute to the project.
Maintain – Manage repository settings (excluding sensitive/destructive actions).
Admin – Full access, including sensitive actions like security management or deleting the repo.

Create Discoverable Repositories

As your InnerSource program grows, it’s important to make repositories easy to find and use. Follow these best practices:

Use a descriptive name (e.g., warehouse-api, supply-chain-web).
Add a concise description (1–2 sentences explaining purpose).
License the repository so users know how they can use and share it.
Include a README.md as the landing page with setup and usage info.

How GitHub Surfaces Your README

When you add a README.md file, GitHub automatically displays it on the repository’s landing page. The file can be placed in:

.github directory (highest priority)
Repository root directory
docs directory

If multiple README files exist, GitHub follows this order of priority when deciding which one to display.

Manage Projects on GitHub

To make collaboration smoother, GitHub automatically looks for a CONTRIBUTING.md file in your repository (in the root, /docs, or /.github directory).

This file should outline your project’s contribution policy, including conventions, workflows, and expectations for contributors.

If a CONTRIBUTING.md file exists, GitHub will display a link to it whenever someone opens an issue or a pull request, encouraging contributors to follow your guidelines.

Create issue and pull request templates

GitHub lets you create starter templates for issues and pull requests to make contributions more structured and consistent.

Issue Templates (.github/ISSUE_TEMPLATE.md)
- Automatically load when someone creates a new issue.
- Help contributors provide all required details without referring back to CONTRIBUTING.md.
- Work like a form—users just fill in the template.
Pull Request Templates (.github/PULL_REQUEST_TEMPLATE.md)
- Provide a standard structure for PR descriptions.
- Encourage contributors to include details like the purpose of changes, testing steps, and related issues.

Maintain a secure repository by using GitHub repository

A secure development strategy is critical to protect data, prevent unauthorized access, and ensure compliance.

Key considerations:

Educate continuously – Security evolves, so ongoing training is essential.
Write secure code – Design and implement features with security in mind.
Ensure compliance – Test against regulations during development and after deployment.

Security Tab

GitHub offers security features that help keep data secure in repositories and across organization. Security Tab in a specific repository consists of the below options:

From the Security tab, you can add features to your GitHub workflow to help avoid vulnerabilities in your repository and codebase. These features include:

Security policies that allow you to specify how to report a security vulnerability in your project by adding a SECURITY.md file to your repository.
Dependabot alerts that notify you when GitHub detects that your repository is using a vulnerable dependency or malware.
Security advisories that you can use to privately discuss, fix, and publish information about security vulnerabilities in your repository.
Code scanning that helps you find, triage, and fix vulnerabilities and errors in your code.
Secret scanning that detects tokens, credentials, and secrets committed to your repo and can block them before the push. Push protection is enabled by default on public repositories.

Communicate a Security Policy with `SECURITY.md`

Include a SECURITY.md file in your repository to guide responsible disclosure of vulnerabilities. It helps researchers and contributors report issues safely and ensures faster resolution of security concerns.

Keep Sensitive Files Out of Your Repository with .gitignore

Accidentally committing sensitive files—like API keys or private configs—can expose serious security risks. A .gitignore file prevents this by telling Git which files or patterns to ignore during commits.

Helps avoid committing build artifacts, logs, or secrets.
Supports multiple .gitignore files; child directory rules override parent ones.
Maintain a root .gitignore for global rules, with optional project-specific files where needed.

Branch protection rules

Branch protection rules help enforce workflows and maintain code quality before changes are merged. For example, you can require an approving review or passing status checks for pull requests targeting protected branches.

Common workflows include:

Running builds to verify code compiles.
Running linters to enforce coding standards.
Running automated tests to catch regressions.
Enforcing reviews and status checks before merging.

Add a `CODEOWNERS` File

A CODEOWNERS file defines who is responsible for specific parts of a repository. When someone opens a pull request that modifies those files, GitHub automatically requests a review from the designated code owners.

Key points:

Place the CODEOWNERS file in the root, .github/, or docs/ directory.
Use file patterns to specify ownership (e.g., *.js @frontend-team).
Multiple owners can be assigned to the same file or directory.
Helps enforce accountability and ensures the right people review changes.

Automated Security in GitHub

GitHub provides several built-in automated security features to help you identify and remediate risks in your repositories.

Repository Dependency Graphs

GitHub scans package manifests (e.g., package.json, requirements.txt).
Creates a dependency graph to show all direct and indirect dependencies.

Dependabot Alerts

Monitors your dependency graph for known vulnerabilities.
Cross-references package versions with GitHub Security Advisories.
Sends alerts when a risk is detected.

Dependabot Automated Updates

Dependabot doesn’t just alert you—it can create pull requests to update vulnerable dependencies automatically.
Maintainers review, test, and merge these PRs to stay secure with minimal effort.

Automated Code Scanning

Scans your code for security vulnerabilities and coding errors.
Prevents new issues from being introduced in pull requests.
Powered by CodeQL, which lets you query code as data and use custom or community-maintained queries.

Secret Scanning

Detects hardcoded secrets (API keys, tokens, credentials) in repositories.
Enabled by default for public repos; can be enabled for private repos by admins.
Alerts service providers, who may revoke or rotate exposed credentials.

GitHub Administration

GitHub provides different levels of administration—team, organization, and enterprise—each offering specific controls and best practices for managing collaboration, security, and policies.

Administration at the Team Level

Teams are substructures within organizations that simplify permission management and collaboration.

Capabilities for team maintainers / repo admins:
- Create, delete, or rename teams.
- Add/remove members or sync membership with IdP groups (e.g., Microsoft Entra ID).
- Manage outside collaborators (consultants, contractors).
- Enable/disable team discussions and set visibility.
- Assign automatic code reviewers and schedule reminders.
Best practices:
- Create nested teams to reflect company hierarchy.
- Build interest/skill-based teams (e.g., JavaScript, data science) to streamline PR reviews.
- Use IdP synchronization to automate onboarding/offboarding and reduce manual updates.

Administration at the Organization Level

Organizations are shared spaces where multiple teams collaborate across repositories.

Owner/administrator capabilities:
- Invite or remove members.
- Create teams and grant maintainer permissions.
- Manage repository permissions and default settings.
- Add/remove outside collaborators.
- Configure security and billing.
- Apply organization-wide changes or migrations using scripts.
Best practices:
- Ideally set up one organization to simplify management.
- Multiple organizations increase setup effort, risk of misconfiguration, and may add costs.

Administration at the Enterprise Level
Enterprise accounts (GitHub Enterprise Cloud or Server) allow centralized management across multiple organizations.

Owner capabilities:

Enable SAML single sign-on with IdP integration.
Add or remove organizations.
Manage enterprise-wide billing.
Define global repository, project, and team policies.
Apply migrations or custom scripts across the enterprise.
Use GitHub Connect to integrate Enterprise Server with GitHub.com.

How does GitHub organization and permissions work?

Organizations in GitHub allow multiple people to collaborate on repositories while controlling access with permission levels, forking rules, and insights.

Repository Permission Levels
Repositories support five standard permission levels:
- Read – View or discuss project content (non-code contributors).
- Triage – Manage issues and pull requests without write access (ideal for project managers).
- Write – Push commits and make direct contributions (standard for developers).
- Maintain – Manage repository settings without destructive actions (for project leads).
- Admin – Full access, including sensitive actions like security management or deleting the repo (for admins/owners).
What is Repository Forking?

Forking creates a personal copy of a repository under your account. This allows experimentation or contributions without affecting the original project.

Public repos → Always forkable.
Private repos → Forking can be disabled or restricted to org members.
Internal repos → Can only be forked within the same enterprise account.

Note: If you disable forking for a private repository, no one (including organization members) will be able to fork it.

Viewing Repository Insights

The Insights tab provides data to track repository health, activity, and security.

Contributors – See commits, additions, and deletions by contributor.
Traffic – Monitor unique visitors and page views.
Commits – Analyze commit activity over time.
Code Frequency – Track lines added and deleted.
Dependency Graph – Identify and monitor dependencies for vulnerabilities.
- Best Practices with Insights:
Monitor contributor activity to identify engaged team members.
Track traffic trends to understand repository engagement.
Regularly review the dependency graph to address security risks.

Managing enterprise permissions

GitHub provides different permission levels at both the organization and enterprise levels. These roles help maintain security, proper access, and governance across teams.

Organization Permissions Levels

Role	Description
Owner	Full control of the organization. Can add/remove members. Should be limited to at least two people for safety.
Member	Standard role. Can create and manage repositories and teams.
Moderator	Manage community interactions in public repositories (block/unblock contributors, set interaction limits, hide comments).
Billing Manager	Manage organization billing information.
Security Manager	Manage security alerts and settings across the organization; read access to all repositories.
Outside Collaborator	External contributors (e.g., consultants, contractors) with access to one or more repositories, but not full org membership.

Enterprise Permission Levels

Role	Description
Owner	Complete control of the enterprise. Can manage administrators, add/remove organizations, enforce policies, and manage billing.
Member	Same permissions as organization members.
Billing Manager	View and edit billing information, manage billing managers.
Guest Collaborator	Limited access to specific repositories/organizations (Enterprise Managed Users only).

Team Synchronization

If your company uses Microsoft Entra ID or Okta as an identity provider (IdP), you can manage GitHub team membership through team synchronization. With team sync enabled, GitHub automatically mirrors IdP group changes—removing the need for manual updates or custom scripts.

This centralized approach simplifies:

Onboarding new employees
Adjusting access when users move between teams
Removing access when employees leave the organization

Requirement: Team sync requires your IdP admin to enable SAML SSO and SCIM provisioning.

Searching GitHub

Global search:
- Searches across all of GitHub.
- Returns results from code, issues, PRs, users, Marketplace, etc.
- Supports full search syntax (is:pr, is:issue, etc.), though not every filter works for every result type.
Context search:
- Scoped to the current repo and specific tab (Issues, PRs).
- Exposes type-specific filters (author, labels, projects, etc.).
- Best when searching inside a single repo.
Common search filters:
- is:open is:issue assignee:@me → Open issues assigned to me.
- is:closed is:pr author:contoso → Closed PRs created by @contoso.
- is:pr sidebar in:comments → PRs with “sidebar” in comments.
- is:open is:issue label:bug -linked:pr → Open bug issues without a linked PR.

Organizing Work

Milestones
- Group issues/PRs into goals (sprints, releases, phases).
- Track progress automatically (done vs remaining).
- Search by milestone: is:open is:issue milestone:"Sprint 1".
Labels
- Metadata to classify issues/PRs (bug, priority, team).
- Searchable with label:bug.
Assignees
- Assign issues/PRs to one or more people.
- Searchable with assignee:@me.

Git History & Collaboration

Git blame
- Shows commit history for each line of a file.
- Helps identify who changed what and when.
- GitHub adds a UI view for easy navigation.
Cross-linking
- Link issues, commits, PRs, and projects to provide context.
- Autolinks happen automatically with #123 or commit IDs.
Saved replies
- Prewritten responses for maintainers.
- Great for common feedback (setup instructions, bug triage).
Issue templates
- Better than saved replies for collecting structured info up front.
- Can define bug/feature request templates in repo settings.
Mentions (@username)
- Notifies specific users to join the discussion.
- Keeps context even after issues are closed.

Exam Guide : GitHub Foundation Part 1

Rajesh Murali Nair — Fri, 29 Aug 2025 11:50:07 +0000

Introduction to Git

What is Version Control?

A version control system (VCS) is a program or set of programs that tracks changes to a collection of files. One goal of a VCS is to easily recall earlier versions of individual files or of the entire project. Another goal is to allow several team members to work on a project, even on the same files, at the same time without affecting each other's work.

Another name for a VCS is a software configuration management (SCM) system.

What is Git?

Git is distributed, which means that a project's complete history is stored both on the client and on the server. You can edit files without a network connection, check them in locally, and sync with the server when a connection becomes available. If a server goes down, you still have a local copy of the project. Technically, you don't even have to have a server. Changes could be passed around in e-mail or shared by using removable media, but no one uses Git this way in practice.

What are Git Terminology?

Before diving into Git commands, it’s important to get familiar with some basic terms you’ll hear often:

Working Tree – The collection of files and directories you’re actively working on.
Repository (Repo) – The top-level directory where Git stores all history and metadata of your project.
Hash – A unique ID Git generates (using SHA-1) to track file changes.
Object – Core building blocks in Git (blobs, trees, commits, tags), each identified by a hash.
Commit – A snapshot of changes you’ve saved into Git’s history.
Branch – A series of commits with a name (like main), used to work on features independently.
Remote – A link to another repository, often called origin, used for pushing and pulling changes.
Commands, Subcommands & Options – How you interact with Git (e.g., git push, git reset --hard).

What is the key difference between Git & GitHub?

It’s easy to mix up Git and GitHub, but they are not the same thing.

Git is a distributed version control system (DVCS). It helps developers track changes in code, work with branches, and collaborate by pushing and pulling updates between local and remote repositories. Git itself runs on your computer and doesn’t require the internet to work.

GitHub, on the other hand, is a cloud-based platform built on top of Git. It provides an online place to host repositories, making collaboration much easier. Beyond storing code, GitHub adds collaboration tools such as:

Issues & Discussions – for bug tracking and communication.
Pull Requests (PRs) – for code review and merging changes.
Actions – for automating workflows like CI/CD.
Projects & Labels – for organizing and managing work.
Forks – for contributing to other projects.

In short: Git is the tool, GitHub is the platform. You use Git to manage your code versioning, and GitHub to share it, collaborate, and manage the bigger picture of software development.

Basic Git Commands

Git works like a camera taking snapshots of your project. Every time you make changes, you can decide whether to keep a “snapshot” (commit) so Git can track the history of your project. Here are some essential commands to get started:

Command	Description
`git status`	Shows the current state of the working directory and staging area
`git add <file>`	Stages changes in a file (prepares it for the next commit)
`git commit -m ""	Saves a snapshot of staged changes with a message describing the update
`git log`	Displays the history of commits with author, date, and commit messages
`git help`	Provides help for Git commands. `Use git <command> --help` for details.

Introduction to GitHub

What is GitHub?

GitHub is a cloud-based platform built on top of Git. While Git handles version control, GitHub makes it easier to collaborate, share, and manage projects online. It provides a website, command-line tools, and workflows that bring developers, teams, and organizations together.

At its core, GitHub Enterprise focuses on five pillars: AI, Collaboration, Productivity, Security, and Scale.

AI – GitHub leverages generative AI through tools like Copilot, Copilot Chat, and Copilot Agents. These help write code faster, generate documentation, suggest fixes, and even improve security by catching issues early.

Collaboration – With features like Repositories, Issues, Pull Requests, and Discussions, GitHub makes teamwork seamless. Teams can work in parallel, review code efficiently, and shorten delivery cycles.

Productivity – Built-in CI/CD pipelines (GitHub Actions) automate repetitive tasks such as testing, building, and deploying software. This lets developers spend more time solving problems rather than managing workflows.

Security – GitHub integrates security at every stage of development with tools like CodeQL, Dependabot, secret scanning, and a security overview dashboard. This ensures vulnerabilities are detected and resolved early.

Scale – GitHub powers the world’s largest developer community with 100M+ developers and 420M+ repositories. Its extensible platform continuously evolves through contributions from open source and enterprise developers alike.

What is a repository?

A repository (repo) is the home for your project in Git or GitHub. It contains all of your project’s files along with their entire revision history, so you can track changes over time, restore older versions, and collaborate with others.

What is Gists?

Gists are a GitHub feature designed for sharing small pieces of code, notes, or configuration files in a lightweight way. Unlike full repositories, gists are quick to create and perfect for sharing short, useful snippets. Since they are essentially mini Git repositories, you can fork, clone, and even apply version control to them.

Key Features of Gists

Public and Secret Gists
- Public Gists: Visible to everyone and discoverable through GitHub search. Great for sharing examples, fixes, or snippets with the community.
- Secret Gists: Hidden from search results and not publicly listed. However, anyone with the link can view them. Useful for sharing code privately with a limited group.
Version Control : Every change you make is tracked, so you can view edit history or roll back to previous versions.
Forking and Cloning : Just like repositories, gists can be forked and cloned, enabling others to adapt your snippet to their needs.
Embedding : Gists can be embedded directly into blogs, forums, or websites, making them ideal for tutorials or documentation.
Markdown Support : Gists support Markdown, letting you add headings, links, rich text, or even images alongside your code for better context.
Collaboration : Others can fork and comment on your gists, enabling lightweight collaboration around snippets and solutions.

Use Cases for Gists

Sharing quick code examples or bug fixes
Storing personal configuration files or scripts
Creating templates for reusable code patterns
Sharing error logs or debugging details with collaborators
Embedding snippets into blogs, articles, or documentation

Important Notes

Do not store sensitive information (like API keys, passwords, or secrets) in gists—even in secret gists.
Secret ≠ Private: Secret gists are simply hidden, but anyone with the link can still access them.

Limitations of Gists

Not suited for large projects or multi-file structures (use a repository instead).
Secret gists are still accessible via URL, so they are not a substitute for true privacy.

What are Wikis?

A wiki in GitHub is a dedicated space within a repository for long-form documentation. While a README gives a quick overview, a wiki is ideal for detailed guides, design notes, or tutorials. It serves as a living knowledge base for your project. For private repos, only users with read access can view the wiki.

Components of the Github Glow

The GitHub Flow is a lightweight, branch-based workflow designed for continuous collaboration and deployment. It is built around three main components:

Branches – A branch is where you do your work independently from the main codebase. You can experiment, fix bugs, or add features without affecting the default branch (main).
Commits – A commit saves your changes to the repository, capturing a snapshot of what the code looked like at a certain point in time. Each commit includes metadata like the author, timestamp, and a unique identifier.
Pull Requests – A pull request is how you propose changes to be merged into the default branch. It’s the place for discussion, feedback, code reviews, and automated checks before integration. GitHub also supports Draft Pull Requests, which let you open a pull request that's not yet ready for review.

File States in Git

Within a Git repository, every file goes through specific states as part of version control. Understanding these states is critical for working with Git effectively:

Untracked – A new file that Git doesn’t know about yet. It hasn’t been added to version control.
Tracked – A file that Git is monitoring. Tracked files can exist in several substates:
- Unmodified – The file hasn’t changed since the last commit.
- Modified – The file has been changed but not yet staged.
- Staged – The modified file has been added to the staging area (git add) and is ready to be committed.
- Committed – The file is saved in the repository’s database as part of a commit (the latest snapshot).

GitHub Flow

The GitHub Flow is a simple, lightweight workflow designed to help you safely make and share changes. It’s widely used because it supports continuous integration and continuous delivery (CI/CD) while keeping things easy to manage.

Git Flow

While GitHub Flow is simple, Git Flow is a more structured branching model—suited for projects with scheduled or versioned releases. It introduces long-lived branches and specific rules for release management.

GitHub Flow vs Git Flow

Feature / Aspect	GitHub Flow 🌐	Git Flow 🔀
Purpose	Lightweight workflow for continuous delivery and collaboration.	Structured branching model for release-driven development.
Default Branch	`main` (or `master` in older repos).	`master` (production) and `develop` (integration).
Branch Types	Feature branches → Pull Requests → Merge into `main`.	`master`, `develop`, `feature/`, `release/`, `hotfix/*`.
Simplicity	Very simple and easy to adopt.	More complex, with multiple long-lived branches.
Release Strategy	Continuous delivery—changes merged frequently.	Versioned releases with explicit preparation branches.
Use Cases	Startups, small/medium teams, fast-moving projects.	Enterprises, regulated industries, projects needing predictable release cycles.
History Management	Often uses squash merges or rebase for a clean history.	Requires merge commits to maintain branching structure.
Speed vs Control	Prioritizes speed and agility.	Prioritizes control and release planning.

GitHub Issues & Discussions

GitHub Issues are the primary way to track tasks, ideas, bugs, and feedback within a repository. They can be created in multiple ways and help teams stay organized. You can:

Use labels, mentions, and reactions to categorize and prioritize work.
Create issue templates to maintain consistency across contributions.
Convert discussions into issues when an actionable task emerges.

GitHub Discussions, on the other hand, are designed for open conversations not tied directly to code. They work like a community forum where you can share ideas, ask questions, or provide feedback. Discussions can be public or private, depending on repository settings.

Key points about Discussions:

Repository owners or users with Write access can enable Discussions.
Any authenticated user with repo access can create a discussion.
Maintainers can pin important discussions (e.g., announcements, FAQs, or active topics) for visibility.
Discussions can be converted into issues when needed.

GitHub platform management

Managing Notifications and Subscriptions

Staying updated on important activity is key when working in GitHub. Notifications let you track updates across repositories, teams, and projects, while subscriptions help you control what you actually want to hear about.

You can subscribe to notifications for:

Specific issues, pull requests, or gists
Repository activity (issues, PRs, releases, discussions)
Workflow statuses from GitHub Actions
All activity across a repository

How it works:

You’re automatically subscribed when you interact with something (e.g., commenting, opening an issue, or being assigned).
You can also manually watch, unwatch, or customize your subscriptions to match your preferences.
If updates become irrelevant, simply unsubscribe or adjust notification settings to reduce noise.

Subscribing to Threads and Finding Mentions

GitHub gives you fine-grained control over how you follow conversations and stay in the loop.

Subscribing to threads – You can manually subscribe to any issue, pull request, or discussion—even if you weren’t part of the original conversation. Simply click Subscribe in the right-hand sidebar.
Finding mentions – To locate conversations where you’ve been tagged, use the search qualifier:

mentions:<username>

This ensures you don’t miss discussions requiring your attention.

Filtering Notifications

You can adjust your watch settings on a repository to control the amount of updates you receive:

Watching – Get notifications for all activity.
Not watching – Only receive updates if you participate or are @mentioned.
Ignore – Receive no notifications for that repository.
Custom – Fine-tune notifications (issues only, PRs only, etc.).

Manage this by selecting Watch at the top of a repository page.

Configuring Notification Settings

GitHub also lets you choose where you receive notifications:

Email – Delivered to your registered address.
Web – Viewable directly in your GitHub dashboard.
Mobile – Push notifications via the GitHub mobile app.
Custom – Configure which events go to which channel.

These preferences can be managed under User Settings → Notifications.

What are GitHub Pages?

GitHub Pages is a free static site hosting service offered by GitHub. It allows you to create and host a personal, organizational, or project website directly from a GitHub repository.

It serves HTML, CSS, and JavaScript files straight from your repo.
Optionally, you can run the files through a build process (for example, with Jekyll) before publishing.
You can specify a source branch and folder (like /docs) as the content root for your site.
Once published, GitHub makes the site publicly accessible under a github.io domain or a custom domain you configure.

Introduction to GitHub's Products

GitHub accounts & plans

When working with GitHub, it’s important to understand two concepts:

Account Types – define who owns resources (personal, organization, or enterprise).
Plans – define what features are available (free or paid tiers).

GitHub Account Types

1.Personal Accounts

Identity on GitHub (username + profile).
Can own repositories, packages, and projects.
Supports GitHub Free or GitHub Pro plans.
Unlimited public and private repos (Free private repos have limited features).

2.Organization Accounts

Shared accounts where teams collaborate across projects.
Members log in with personal accounts; permissions are role-based (member, owner, security manager).
Can own repositories, packages, and projects.
Supports GitHub Free for Organizations or GitHub Team/Enterprise plans.

3.Enterprise Accounts

Designed for large-scale organizations with multiple teams and orgs.
Enterprise owners can manage orgs, enforce policies, and control billing centrally.
Supports GitHub Enterprise (Cloud or Server).

GitHub Plans Comparison

Feature / Plan	Free (Personal/Org)	Pro (Personal)	Team (Organizations)	Enterprise (Cloud/Server)
Repositories	Unlimited public & private (limited features on private for Free)	Unlimited public & private	Unlimited public & private	Unlimited public & private
Collaborators	Unlimited	Unlimited	Unlimited	Unlimited + org-wide policies
Support	Community only	Email support	Email support	Dedicated Enterprise support
GitHub Actions	2,000 minutes/month	3,000 minutes/month	3,000 minutes/month	50,000 minutes/month (Enterprise Cloud)
Packages Storage	500 MB	2 GB	2 GB	50 GB (Enterprise Cloud)
Codespaces	120 core hours + 15 GB storage/month	180 core hours + 20 GB storage/month	Org-level management + same limits as Pro	Custom enterprise limits
Security Features	Dependabot alerts, 2FA enforcement	Same as Free	Required reviewers, protected branches, code owners	Advanced Security (CodeQL, secret scanning, policies)
Collaboration Tools	Issues, PRs, Wikis, Pages (limited for Free orgs)	Wikis, Pages, Insights	Draft PRs, team reviewers, scheduled reminders, advanced insights	Centralized policies, GitHub Connect, EMU (Enterprise Managed Users)
Best For	Individuals or small teams starting out	Individual developers needing advanced insights	Teams needing structured collaboration	Large orgs needing compliance, governance, and scale
Hosting Options	GitHub.com	GitHub.com	GitHub.com	GitHub.com (Enterprise Cloud) or Self-hosted (Enterprise Server)

Enterprise Managed Users (EMU)

Enterprise Managed Users allow organizations to control identities using their identity provider, enabling central access management and increased security.

GitHub Mobile vs GitHub Desktop

Feature / Tool	GitHub Mobile (iOS/Android)	GitHub Desktop (Windows/macOS)
Primary Use	On-the-go collaboration & notifications	Local Git workflow management
Commit & Stage	❌ No (can edit PR files only)	✅ Yes
Manage Notifications	✅ Yes	❌ No
Review PRs & Issues	✅ Yes	✅ Yes
Edit Files	✅ In pull requests	✅ Locally with commits
Clone Repos	❌ No	✅ Yes
Verify Sign-in	✅ Yes	❌ No
Secure with 2FA	✅ Yes	❌ No
CI Status View	❌ No	✅ Yes
Platforms	iOS, Android	Windows, macOS

License Usage Stats in Machine and Peripheral Devices

Tracking license usage is essential in GitHub Enterprise for both cost optimization and security compliance. Machine accounts and peripheral services can consume licenses just like regular users, which directly impacts enterprise costs and resource allocation.

Understanding Machine Accounts and Peripheral Services

Machine Accounts

Special GitHub accounts used for automation, integrations, or running scripts.
Commonly tied to CI/CD tools (e.g., GitHub Actions, Jenkins, CircleCI).
Consume a GitHub license like any standard user.
Act independently of human users.

Peripheral Services

External services or tools interacting with GitHub via API requests.
Examples include:
- CI/CD Pipelines (GitHub Actions, self-hosted runners, Jenkins).
- Security Tools (Dependabot, CodeQL, Snyk).
- Third-party Integrations (Slack, Jira, Datadog).

What is GitHub Copilot and Its Different Plans?

GitHub Copilot is your AI-powered pair programmer that helps you write code faster and smarter. Built by GitHub and OpenAI, it uses the OpenAI Codex and newer models like GPT-4o to generate real-time suggestions in dozens of programming languages.

Research shows that developers using GitHub Copilot experience:

46% of new code written by AI.
55% boost in productivity.
74% feel more focused on meaningful work.

Copilot integrates directly into popular IDEs like VS Code, Visual Studio, JetBrains, and Neovim, offering code autocompletion, explanations, and even test generation.

GitHub Copilot Features

Copilot for Chat – AI-powered chat inside your IDE to explain code, generate tests, and suggest bug fixes.
Copilot for Pull Requests – AI-generated PR descriptions and tags, powered by GPT-4.
Copilot for the CLI – Helps compose complex terminal commands and flags, reducing time spent searching syntax.

GitHub Copilot Plans Comparison

Feature / Plan	Free (Individual)	Pro (Individual)	Pro+ (Individual)	Business (Teams/Orgs)	Enterprise (Large Orgs)
Code Completions	2,000/month	Unlimited	Unlimited (priority capacity)	Unlimited	Unlimited (personalized w/ internal code)
Chat Requests	50/month	Unlimited	Unlimited	Unlimited	Unlimited
AI Models	GPT-4o, Claude 3.5	Latest models, priority access	Premium models, priority infra	Org-wide access to latest models	Fine-tuned org-specific models
IDE Integration	VS Code, Visual Studio, JetBrains, Neovim	Same as Free	Same as Pro	Same as Pro + Mobile support	Deep GitHub integration + enterprise IDEs
Test Generation	❌ No	✅ Yes	✅ Yes	✅ Yes	✅ Yes + org customization
Pull Request Enhancements	❌ No	✅ Basic	✅ Basic	✅ AI-powered tags & security filtering	✅ Advanced PR summaries & org-wide policies
CLI Support	❌ No	✅ Yes	✅ Yes	✅ Yes	✅ Yes
Security Features	Basic (none)	Basic (none)	Basic (none)	Vulnerability filtering, IP indemnity, compliance tools	Advanced Security + org-wide governance
Management Tools	❌ No	❌ No	❌ No	Centralized management & policies	Enterprise-wide management & identity (EMU)
Customization	❌ No	❌ No	❌ No	❌ Limited	✅ Fine-tuned org/private models
Best For	Beginners exploring AI coding	Individual developers needing unlimited AI help	Power users needing priority performance	Organizations needing secure collaboration	Enterprises needing personalization, compliance, and scale

What is Code Scanning?

Code scanning is a GitHub feature that uses CodeQL to analyze the code in your repository for security vulnerabilities and coding errors. It helps developers catch problems early and ensure safer, cleaner code.

Availability:
- Enabled by default for all public repositories.
- Available for private repositories when GitHub Advanced Security is enabled.
How it works:
- When a potential vulnerability or error is detected, GitHub displays an alert in the repository’s Security tab.
- Once the issue is fixed, the alert is automatically closed.
- Developers can triage and prioritize fixes, preventing both existing and newly introduced issues.
Triggers for scanning:
- on:push – runs scans whenever new code is pushed.
- on:pull_request – scans pull requests before merging, ensuring vulnerabilities aren’t introduced.
- Scans can also be scheduled at specific days/times.
Powered by GitHub Actions:
- Code scanning workflows run on GitHub Actions.
- Each run consumes GitHub Actions minutes (free for public repositories and self-hosted runners).
- For private repositories, included usage depends on your GitHub plan.
- Usage beyond the free limit is controlled by spending limits (default $0/month for billed accounts, unlimited for invoiced customers).
- Minutes reset monthly, while storage usage accumulates until cleared.

What is GitHub Codespaces?

GitHub Codespaces is a cloud-hosted development environment powered by GitHub. It lets you spin up a fully configured, containerized workspace directly from a repository—without needing to set up dependencies or environments on your local machine.

Codespaces are configurable, so teams can define a repeatable environment for all developers, ensuring consistency across projects.

Codespace Lifecycle

Create – Start a Codespace from GitHub.com, VS Code, or the GitHub CLI.
Connect/Disconnect – You can disconnect and reconnect without interrupting processes.
Stop/Restart – Resume where you left off without losing changes.
Delete – Remove once work is complete (unpushed changes trigger a warning).

Ways to Create a Codespace

You can create a Codespace in four main ways:

From a template repository – to start a new project.
From a branch – for feature development.
From a pull request – to explore or review in-progress work.
From a specific commit – to investigate bugs at a certain point in history.

Key Features

Long-running vs Temporary – Use Codespaces for short tests or extended feature development.
Prebuilds – Admins can enable prebuilds to speed up environment setup.
Timeouts – Codespaces stop after 30 minutes of inactivity. Data is preserved until explicitly deleted.
Rebuilds – Rebuild to apply configuration changes. Cached images speed things up, while a full rebuild clears the cache for fresh setup.
Retention – Inactive Codespaces are automatically deleted after 30 days (configurable).

What You Can Customize in GitHub Codespaces?

GitHub Codespaces is highly configurable, allowing you to personalize and optimize your development environment. Here are the key customization options:

Settings Sync – Sync your VS Code settings between the desktop and web client.
Dotfiles – Use a dotfiles repo to set up scripts, shell preferences, and custom configurations.
Rename a Codespace – Change the autogenerated name to easily identify different Codespaces.
Change Your Shell – Use your preferred shell (bash, zsh, etc.), set a new default, or configure via dotfiles.
Change the Machine Type – Adjust CPU/RAM resources depending on workload.
Set the Default Editor – Choose how Codespaces open:
- VS Code (desktop or web)
- JetBrains Gateway (for JetBrains IDEs)
- JupyterLab (for data science workflows)
Set the Default Region – Decide where your data is stored geographically.
Set the Timeout – Change the default 30-minute inactivity timeout to longer or shorter intervals.
Configure Automatic Deletion – Define how long stopped Codespaces are retained (up to 30 days).

Project vs Projects (Classic)

Feature	Projects (New)	Projects (Classic)
Tables & Boards	Tables and Boards with flexible layouts (including Lists and Timeline).	Boards only.
Data	Sort, rank, and group items using custom fields (text, number, date, iteration, single select).	Columns and Cards only.
Insights	Create visuals and charts for historical and current progress tracking.	Simple progress bar.
Automation	Advanced automation via GraphQL API, Actions, and column presets.	Limited automation with column presets when issues/PRs are added, edited, or closed.

GitHub Actions with Workflows

GitHub Actions allows you to add powerful automation to your projects. By creating workflows, you can define tasks that run automatically when certain events occur in your repository.

A workflow is made up of one or more jobs, and each job runs a series of steps.
Workflows can be triggered by events such as issue creation, pull requests, or pushes to a branch.

AWS CDK: The Beginner’s Guide

Rajesh Murali Nair — Tue, 26 Aug 2025 16:27:31 +0000

Introduction

The other day, I had an interview with a bank for a Platform Engineer role, and one of the main tools they use is AWS CDK. Up until then, my go-to Infrastructure as Code tool had always been Terraform, so I was curious: How does CDK really work, and what should someone know before using it in the real world?

That curiosity gave me the idea for this blog. Instead of just keeping my learnings to myself, I wanted to share them with you in a beginner-friendly way. Throughout this series, I’ll be creating multiple small projects to break down the concepts step by step, so it’s easier to follow along and connect the dots. My goal is to give you a clear picture of what you need to know before using AWS CDK in any company or environment—so that when the time comes, you’ll be ready to confidently create and manage AWS resources.

What is CDK?

Before diving into the details, let’s start with the basics—what exactly is AWS CDK?

AWS CDK (Cloud Development Kit) is an open-source Infrastructure as Code (IaC) framework that allows you to define your cloud resources using familiar programming languages like Python, TypeScript, Java, or C#. Instead of writing long YAML or JSON templates, you can write actual code to describe your infrastructure.

Think of it like this:

With Terraform/CloudFormation, you usually declare what you want in a static way.
With AWS CDK, you get the power of a full programming language to describe what you want, along with the flexibility to use loops, conditions, and abstractions to make it reusable.

In short, AWS CDK lets you bring your developer mindset into infrastructure management.

Understanding Important AWS CDK Core Concepts

Projects

An AWS CDK project is just the folder where all your infrastructure code lives.

When you create a CDK project, some files are always there no matter which language you choose, while others are specific to the language you’re using.

Universal Files & Folders (common in all CDK projects)
- .git/ → Git repo for version control (if Git is installed).
- .gitignore → Tells Git which files to ignore.
- README.md → Basic instructions for your project (you can update it).
- cdk.json → Configuration for CDK (how to run the app).
Python-Specific Files & Folders
- .venv/ → Python virtual environment (for dependencies).
- app.py → The entry point of your CDK app (like main() in a program).
- my_cdk_project/ → Folder with your stack files (where you define resources).
  - __init__.py → Makes it a Python package.
  - *_stack.py → Defines your AWS resources.
- requirements.txt → Lists your Python dependencies.
- requirements-dev.txt → Extra dependencies for development only.
- source.bat → Helper script for Windows users.
- tests/ → Python unit tests for your stacks.

Constructs

Constructs are the basic building blocks of an AWS CDK application.
Think of them as Lego blocks each block represents one or more AWS resources (like an S3 bucket, a Lambda function, or a VPC) along with its configuration.

When you build a CDK app, you’re really just putting together constructs piece by piece to describe your infrastructure.

Types / Levels of Constructs

Level	Definition	Example	When to Use
L1	Direct CloudFormation resources (lowest-level)	`s3.CfnBucket`	For full control or new AWS features not yet in L2/L3
L2	AWS CDK abstractions with defaults and helpers	`s3.Bucket`	Everyday usage (balance of flexibility and ease)
L3	Pre-built patterns (multiple resources together)	`apigateway.LambdaRestApi`	Quick solutions for common use cases

Apps

An App in AWS CDK is like the top-level container for everything you build.

An App can have one or many Stacks.
Each Stack is a group of AWS resources.
Each resource is created using Constructs.

So the structure looks like this:

App → Stack(s) → Construct(s) → AWS Resource(s)

Think of it like a house:

The App = the whole house.
The Stacks = rooms in the house (living room, kitchen, bedroom).
The Constructs = furniture in each room (sofa, fridge, bed).

Example: Simple CDK App in Python

#!/usr/bin/env python3
import aws_cdk as cdk
from aws_cdk import aws_s3 as s3

class MyFirstStack(cdk.Stack):
    def __init__(self, scope: cdk.App, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        # Construct: An S3 bucket
        s3.Bucket(self, "MyFirstBucket",
                  versioned=True,
                  removal_policy=cdk.RemovalPolicy.DESTROY)

app = cdk.App()                        # App (the whole house)
MyFirstStack(app, "MyFirstStack")      # Stack (a room in the house)
app.synth()

What’s Happening Here?

App → cdk.App() is the root of your project.
Stack → MyFirstStack groups resources into one deployable unit.
Construct → s3.Bucket is the actual AWS resource created inside the stack.

When you deploy this app, AWS CDK creates a CloudFormation stack with one S3 bucket.

AWS CDK Stacks

A Stack in AWS CDK is the smallest unit you can deploy.
It’s basically a box that holds a group of AWS resources (like an S3 bucket, a Lambda function, or a VPC).

When you deploy a stack, all the resources inside it are created together in AWS as a CloudFormation stack.

If you delete the stack → all the resources inside it are deleted.
If you update the stack → AWS updates those resources as a group.

Example: A Simple CDK Stack (Python)

#!/usr/bin/env python3
import aws_cdk as cdk
from aws_cdk import aws_s3 as s3

class MyStorageStack(cdk.Stack):
    def __init__(self, scope: cdk.App, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        # Construct: An S3 bucket
        s3.Bucket(self, "MyStorageBucket",
                  versioned=True,
                  removal_policy=cdk.RemovalPolicy.DESTROY)

app = cdk.App()
MyStorageStack(app, "MyStorageStack")
app.synth()

AWS CDK Stages

A Stage in AWS CDK is a way to group one or more stacks together and treat them as a single deployment unit.

Stages are especially useful when you want to promote your infrastructure through different environments like Dev → Test → Prod. Instead of deploying stacks one by one, you wrap them inside a stage and deploy the stage as a whole.

Example: Stage with Multiple Stacks (Python)

stacks/app_stack.py

from aws_cdk import Stack
from constructs import Construct

# Define the app stack
class AppStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # The code that defines your application goes here

stacks/database_stack.py

from aws_cdk import Stack
from constructs import Construct

# Define the database stack
class DatabaseStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # The code that defines your database goes here

my_stage.py

from aws_cdk import Stage
from constructs import Construct
from .app_stack import AppStack
from .database_stack import DatabaseStack

# Define the stage
class MyAppStage(Stage):
    def __init__(self, scope: Construct, id: str, **kwargs) -> None:
        super().__init__(scope, id, **kwargs)

        # Add both stacks to the stage
        AppStack(self, "AppStack")
        DatabaseStack(self, "DatabaseStack")

app.py

#!/usr/bin/env python3
import os

import aws_cdk as cdk

from cdk_demo_app.my_stage import MyAppStage

#  Create a CDK app
app = cdk.App()

# Create the development stage
MyAppStage(app, 'Dev',
           env=cdk.Environment(account='123456789012', region='us-east-1'),
           )

# Create the production stage
MyAppStage(app, 'Prod',
           env=cdk.Environment(account='098765432109', region='us-east-1'),
           )

app.synth()

Conclusion

That’s a wrap on the beginner’s guide to AWS CDK—we covered what CDK is, how projects are structured, and the core pieces (apps → stacks → constructs → resources), with simple examples to get you moving.

Next up, I’ll dive into real-world setups: building and deploying multi-stack apps across multiple environments (Dev/Test/Prod) and setting up a pipeline using AWS CDK with Python. We’ll also touch on cross-stack references, environment configs, and CDK Pipelines basics.

Building Brick Breaker with Amazon Q: AI-Powered Retro Game Development

Rajesh Murali Nair — Tue, 10 Jun 2025 23:25:34 +0000

Why Am I Building a Game?

Inspired by the Build Games Challenge, I wanted to take a hands-on approach to rediscover the joy of classic game development. It’s more than nostalgia — it’s a fun and practical way to learn modern tools like the Amazon Q Developer CLI. Building a retro game gives me a focused, creative playground to explore coding, problem-solving, and AI-driven development workflows.

Why I Chose Brick Breaker

I selected Brick Breaker as it had brought back memories of my first telephone because of the iconic Nokia 3310. Snake and Brick Breaker were two of the games that I would play for hours and hours on it. They were simple, they were addictive, and it felt really satisfying clearing off all the bricks. To restore it now with the technology of the times and AI support is like a tribute to those good olden days of gaming.

How I Got the Most Out of Amazon Q (and Had Fun Doing It)

During my experience with AI, I realized that well-defined and worded questions yield the most precise results. I realized that whenever I explicitly specified the aim, organization, and setting of a task, the result was considerably more accurate. The following is the most effective prompt I have given:

Create a complete Brick Breaker game in Python using PyGame.
It should include a paddle controlled by left/right arrow keys, a bouncing ball, a grid of breakable bricks, game over when the ball falls, and a score tracker.

Why did it succeed?

It clearly defines the language, library, main mechanics, and play flow. Having it well-structured but concise allowed Q's answers to be clean and ready-to-run. I also found it beneficial that I introduced few enhancements in the game from the prompts like "Create multiple levels with increasing ball speed and more bricks", "Add sound effect for the ball collision with the brick" etc which did not modify the game flow rather enhanced my game.

How AI Solved Classic Game Dev Challenges

Challenge	Before Amazon Q	With Amazon Q
Collision Detection	Needed manual bounding-box logic; had bugs while deleting bricks while iterating	Created safe iteration using `bricks[:]`, handled direction of bounce of ball correctly
Angle-Based Ball Bounce	Math needed to account for angle based upon paddle hit location	Automatically generated offset-based reflection logic with `ball.centerx - paddle.centerx`
Smoother Paddle Controls	`KEYDOWN`/`KEYUP` were used by the developers, leading to laggy or nonresponsive paddles	Used `pygame.key.get_pressed()` with `clock.tick()` for smooth input
Power-Ups (such as additional ball)	Difficult to make fall behavior, randomness, collision and reset	Created random drop logic, tracking through lists, and paddle collision interaction
Brick Level & Layout Design	Tedious mathematical treatment of the coordinates, manual or repetitive code	Automated function for placement based on grids and even multi-level transfers
Sound Effects	Manual loading, event hooking, and format support needed	Q added bounce and brick-hit noises with `pygame.mixer.Sound()` properly
High Score Saving	Required file I/O with error handling (JSON or Pickle)	Implemented a permanent `highscore.json` with load/save functions
Game Over Screen & Restart	Necessary game loop pause + state reset logic	Q implemented game over UI, `Press R to restart` functionality, and safe initialization
Asset Management	Missing file errors or inconsistent file paths	Automated creation of `assets/` directory, generated asset-safe code

Automation That Saved Time

To my surprise, the entire game took only 30 minutes to build. The minimum playable version of Brick Breaker with paddle control, ball bounce, and bricks was created by Amazon Q in one prompt. I haven't typed in any line of code, but instead spent my time thinking about what features I should add next. Amazon Q's ability to code and debug fast allowed me to loop through ideas fast and spend more time on creative enhancements rather than boilerplate logic.

Screenshots & Gameplay

Here’s what the final game looked like:

Game Start

Ball Hitting Brick

Game Over Screen

Final Thoughts

I am genuinely impressed by the Amazon Q Developer CLI — it is way more than just an autocompleter. It felt like having an AI pair programmer by my side. I was shocked at its ability to think through abstract game logic, to refactor my code on the fly, and to provide thoughtful details like restart prompts and sound effects. I don't know if you are working on a retro mini-game or a larger prototype, but for me, Q has been a massive help — with Q I can work quickly and still maintain quality.

🔗 Github Repo : https://github.com/raju7258/brick-breaker

aws

Rajesh Murali Nair — Tue, 06 May 2025 09:57:05 +0000

My Experience Taking the AWS Solution Architect Exam: What’s New, What’s Harder, and Why It Still Matters

Rajesh Murali Nair — Tue, 08 Apr 2025 17:55:04 +0000

I. Introduction: Why I’m Writing and Why It Matters

So, I’ve recently renewed my AWS Certified Solution Architect – Professional, and I’ve got to tell you — it’s not what it used to be. In this article, I want to share what’s new, what caught me off guard, and why I still believe it’s totally worth the time and effort. Whether you're renewing or tackling it for the first time, this might just save you a headache or two.

Main Points:

The need to stay current in a fast-changing cloud world.
Why renewing every two years keeps your skills sharp and industry-relevant.
AWS certifications have a real impact on how you approach and design solutions, so they're more than just a resume boost.

II. Exam Format: More Questions, More Time, More Focus Needed

Overview:
Let’s start with the most obvious change — the number of questions and the overall exam structure. It’s a small shift on paper, but a big difference in reality.

Key Points:

The exam now includes 75 questions, up from the previous 65 questions.
The duration has been extended to 180 minutes to match the added complexity.
Increased mental fatigue — requires deeper focus and time management.
Tips from my experience: pacing strategies, how I flagged questions, and how I dealt with tricky scenarios.

III. SAP-C02: An In-Depth Look at Advanced Services

The new exam AWS Certified Solution Architect - Professional (SAP-C02) digs deeper into services you may not use on a daily basis — though you probably should. It really pushes you to think outside the box and consider architecture from a broader, more modern perspective.

Main Points:

There’s a stronger focus on Analytics, Machine Learning, Containerization, and Application Integration.
It challenges you to think not just in silos, but in terms of how these services work together to build something scalable and efficient.
I’ll walk you through what I studied, what surprised me, and how real-world experience with these services gave me a serious edge.
Some of the best prep resources for me: AWS whitepapers, hands-on labs, and a few workshop links that were absolute game-changers.

Workshop Reference Link : https://workshops.aws/

IV. Changes in the Process of Renewal: What to Consider

If you're renewing your AWS certification, there are some updated rules you’ll want to keep on your radar. The criteria around what gets renewed has shifted — and not necessarily in a way that benefits everyone.

Main Points:

At the moment, only the AWS Certified Solutions Architect – Associate is renewed automatically when you pass the Professional exam.
Previously, this renewal would also cover certs like AWS Certified DevOps Engineer - Professional, AWS Certified SysOps Administrator - Associate and AWS Certified Developer - Associate
So what does that mean for you? Well, depending on your job title or long-term goals, you might need to take on multiple exams just to keep everything active.
I’ll also drop a few suggestions that helped me stay on top of renewals — without burning out or overloading myself.

Reference Link : https://aws.amazon.com/certification/recertification/

V. My Proposal: We Should Make These Exams More Practical

After spending years working hands-on with AWS services, I’ve come to believe that these exams should do more than test how well you can pick the right answer from a list. They should test how well you can actually do the job.

Main Points:

It would be a game-changer if AWS introduced practical troubleshooting tasks or interactive lab-style challenges.
Sure, it would raise the difficulty — but it would also build real-world skills instead of just theoretical knowledge.
This shift is especially valuable for AWS Certified Solution Architect – Professional and AWS Certified DevOps Engineer - Professional exams.
A few ideas? Think drag-and-drop architecture design, fixing broken deployments, or tracking down permission errors in IAM under pressure.

AWS AFT: Automating AWS Account Management – Benefits, Challenges, and Lessons Learned

Rajesh Murali Nair — Wed, 05 Feb 2025 13:41:13 +0000

Understanding AWS AFT: A Practical Perspective

AWS AFT, or AWS Account Factory for Terraform, is a powerful tool designed to simplify the provisioning and management of AWS accounts. Built on top of AWS Control Tower, it streamlines enterprise account management using Terraform. By adopting infrastructure-as-code principles, AWS AFT automates the creation and configuration of accounts based on predefined templates and policies, ensuring consistency, governance, and compliance across an organization.

AWS AFT integrates seamlessly with Terraform, a popular open-source infrastructure-as-code tool, allowing users to define, update, and manage their cloud resources in a declarative way. Enterprises often find this integration particularly valuable as it bridges the gap between AWS account governance and DevOps practices, fostering efficiency and scalability.

Why AWS AFT Matters

Managing multiple AWS accounts manually can be tedious and prone to errors. AWS AFT helps solve these issues by automating and standardizing account management. Here’s why enterprises find it valuable:

1. Simplifying Account Management

Setting up and managing multiple AWS accounts for different teams or departments takes time. AWS AFT automates this process, reducing manual effort and ensuring every new account adheres to company policies.

2. Enforcing Consistency

Keeping configurations, security policies, and best practices consistent across multiple AWS accounts can be difficult. AWS AFT makes it easy by allowing organizations to define standard configurations that apply across all accounts, eliminating discrepancies.

3. Strengthening Security & Compliance

For industries with strict security and compliance requirements, AWS AFT ensures every account follows necessary security standards automatically. This reduces the risk of misconfigurations and potential vulnerabilities.

4. Scaling Without the Headache

When managing dozens or even hundreds of AWS accounts, scaling becomes a challenge. AWS AFT makes this process much easier by automating tasks and reducing administrative overhead.

How AWS AFT Fits in Enterprise Workflows

AWS AFT isn’t just about account creation—it integrates deeply into enterprise operations, bringing several benefits:

Centralized Governance: Works alongside AWS Control Tower for a unified governance model across multiple AWS accounts.
Increased Automation: Reduces repetitive manual tasks, allowing DevOps teams to focus on more strategic initiatives.
Optimized Cost Management: By enforcing standardized configurations and governance policies, organizations can control costs and avoid unnecessary spending.

With its ability to enhance automation while maintaining governance, AWS AFT is a must-have for enterprises looking to efficiently scale their AWS infrastructure.

Challenges I Had to Overcome with AWS AFT

While AWS AFT brings immense value, I encountered a few roadblocks along the way. Here are some of the key challenges and how I tackled them:

1. Lack of Clear Documentation

Although AWS AFT is a well-structured tool, I found that its documentation lacked detail, making it challenging to troubleshoot issues. I often had to rely on trial and error or engaging with the GitHub community to find solutions.

2. Workspaces Assigned to Default Projects

One unexpected issue I faced was AWS AFT creating Terraform workspaces under the default Terraform Enterprise (TFE) project instead of my designated ones. This required additional manual intervention or modifications to the AFT code to ensure workspaces were properly assigned for better visibility and control.

3. No Automated Deletion Process

AWS AFT doesn’t include a built-in method to automatically delete Terraform workspaces, AWS accounts, or related resources. This meant manually tracking and cleaning up resources to avoid unnecessary costs and clutter.

4. Lack of Third-Party Network Integration

AWS AFT lacks built-in integration with external networking components. Organizations using third-party networking solutions had to implement additional customization and logic to bridge this gap effectively.

Final Thoughts

AWS AFT is a game-changer for enterprises looking to manage AWS accounts efficiently while maintaining compliance and security. By automating account provisioning, enforcing best practices, and improving scalability, it significantly reduces the operational burden on cloud teams.

However, like any tool, it comes with challenges. Addressing documentation gaps, workspace assignments, and lack of automated cleanup can help make the implementation smoother. With the right workarounds and best practices, AWS AFT can become an indispensable part of an organization’s cloud automation and governance strategy.

A Practical Comparison of Terraform Organization and Team Tokens

Rajesh Murali Nair — Wed, 22 Jan 2025 12:20:36 +0000

When managing access and resources in Terraform, the distinction between Organization Tokens and Team Tokens can seem subtle but is critical to efficient and secure operations. I’ll admit, I only noticed the differences recently when I encountered an issue that left me scratching my head. A routine task in Terraform failed unexpectedly, and after some digging, I realized it was due to confusion between the scope of an organization token and a team token. This experience taught me how crucial it is to understand these tokens to avoid similar pitfalls.

In this blog, we’ll break down the differences between these two types of tokens, explore their use cases, and provide practical insights to help you make the right choice for your Terraform workflows.

What Are Terraform Tokens?

Tokens in Terraform are access keys used for API authentication and authorization. They act as a way to securely interact with Terraform Enterprise or Cloud, enabling operations ranging from managing resources to initiating runs. By using tokens, you can automate tasks without relying on user-specific credentials, improving security and scalability.

Terraform provides different types of tokens to cater to various levels of access: organization tokens and team tokens. Understanding their distinct scopes and use cases is essential to managing your infrastructure effectively.

What Are Organization Tokens?

Organization Tokens are designed for administrative tasks that apply to the entire organization. They provide access to organization-wide settings and resources, such as managing teams, workspaces, and policies.

Key Characteristics of Organization Tokens:

Scope: Grants access to the entire organization.
Use Cases: Ideal for high-level administrative tasks, like creating teams, configuring organization settings, and managing workspaces.
Management: Can only be created or revoked by members of the "owners" team.
Permissions: Cannot initiate runs or create configuration versions.

Security Considerations:
Due to their extensive access, organization tokens must be carefully managed. Limit their use to trusted administrators, rotate them regularly, and store them securely to minimize security risks.

What Are Team Tokens?

Team Tokens, on the other hand, are scoped to specific teams and provide access only to the workspaces that the team is authorized to manage. Unlike organization tokens, team tokens are not tied to an individual user but instead to the team as a whole.

Key Characteristics of Team Tokens:

Scope: Limited to specific workspaces assigned to the team.
Use Cases: Ideal for performing API operations on workspaces, such as queuing plans and applying runs.
Management: Each team can have one active token, which can be generated or revoked by team members or restricted to organization owners.
Permissions: Inherits the permissions of the team, enabling actions like starting runs and managing configurations if allowed.

Security Considerations:
Since team tokens are often used for operational tasks, ensure they are issued only to teams with specific workspace access. Review token usage regularly and disable unused tokens to reduce potential vulnerabilities.

Key Differences Between Organization and Team Tokens

Here’s a quick comparison to highlight the key differences:

Aspect	Organization Tokens	Team Tokens
Scope	Organization-wide; access to all organization settings.	Team-specific; limited to assigned workspaces.
Use Cases	Administrative tasks like creating teams and configuring policies.	Workspace-specific operations like queuing plans.
Management	Managed only by the "owners" team.	Can be managed by team members (or restricted).
Permissions	Cannot start runs or modify configurations.	Can perform actions allowed by team permissions.

When to Use Organization Tokens vs. Team Tokens

Use Organization Tokens:

For creating and managing teams and organization-level settings.
For configuring organization-wide policies and governance.

Use Team Tokens:

For API operations at the workspace level.
For shared access among team members managing specific resources.

Choosing the right token type depends on the task’s scope. For broader administrative access, organization tokens are essential, while team tokens are better suited for granular, team-specific operations.

Best Practices for Managing Terraform Tokens

Adhere to the Principle of Least Privilege: Only grant the access necessary for a task.
Securely Store Tokens: Use tools like HashiCorp Vault or environment variables to store tokens securely.
Rotate Tokens Regularly: Replace tokens periodically to reduce the risk of misuse.
Audit Token Usage: Monitor logs to detect unauthorized or unusual token usage.
Restrict Token Management Permissions: Limit who can generate or revoke tokens to prevent accidental or malicious changes.

Conclusion

Understanding the differences between Terraform organization and team tokens can save you from potential issues and ensure smoother workflows. Organization tokens are your go-to for administrative tasks, while team tokens excel in managing workspace-specific operations. By choosing the right token type for each scenario and adhering to security best practices, you can optimize your Terraform workflows and maintain robust access control.

AWS Terraform Provider v6.0.0 Changes: Overwrite Argument Deprecated for SSM Parameter Store

Rajesh Murali Nair — Fri, 17 Jan 2025 17:09:57 +0000

Introduction

Terraform is a powerful tool for managing AWS infrastructure as code (IaC). Many developers rely on the overwrite argument in the AWS SSM Parameter Store resource to manage configurations and secrets efficiently while avoiding the pitfalls of hardcoding sensitive values. The overwrite argument has been a convenient way to update existing parameters automatically, streamlining workflows and reducing operational overhead.

However, AWS Terraform Provider v6.0.0 has not yet been released. The deprecation of the overwrite argument was first announced in the v5 upgrade guide to give users time to prepare. This change introduces challenges for teams with extensive configurations relying on this feature, requiring them to refactor their code and adopt alternative approaches.

If you're planning to upgrade to AWS Terraform Provider v6.0.0 in the future, understanding the implications of this change is crucial. In this article, we’ll explore:

The role of the overwrite argument and the reasons behind its deprecation.
The challenges this change introduces for Terraform users.
Workarounds and strategies to manage parameter updates effectively in AWS Terraform Provider v6.0.0.

The Role of the Overwrite Argument and the Reasons Behind Its Deprecation

The deprecation of the overwrite argument in AWS Terraform Provider v6.0.0 aims to align the AWS SSM Parameter Store resource with Terraform's standard practices. Previously, the overwrite argument allowed two behaviors that are now considered problematic:

Adopting existing resources during creation ("import-on-create").
Skipping updates without lifecycle rules.

By removing the overwrite argument, Terraform encourages the use of explicit imports and lifecycle rules, providing better clarity and control over resource management.

1. Import on Create

Current Behavior:
Setting overwrite = true automatically adopts existing parameters created outside Terraform. This implicit behavior bypasses Terraform’s explicit resource import process, potentially causing unintentional changes.
Future Behavior:
In AWS Terraform Provider v6.0.0, overwrite will be removed, and the provider will default to treating all create operations as new (overwrite = false). To manage existing resources, you’ll need to explicitly import them using the CLI or an import block.

Example:

import {
  to = aws_ssm_parameter.example
  id = "/some/param"
}

resource "aws_ssm_parameter" "example" {
  name = "/some/param"
  # (other arguments...)
}

2. Skipping Updates Without a Lifecycle Rule

Current Behavior:
Setting overwrite = false skips updates when changes occur, without needing lifecycle rules.
Future Behavior:
In AWS Terraform Provider v6.0.0, this behavior will no longer be possible. The overwrite argument will be removed, and the provider will default to always allowing updates (overwrite = true). To skip specific updates, you’ll need to use the ignore_changes lifecycle rule.

Example:

resource "aws_ssm_parameter" "example" {
  name  = "/some/param"
  type  = "String"
  value = "foo"

  lifecycle {
    ignore_changes = [value]
  }
}

3. Changes Introduced in AWS Terraform Provider v5.0.0
The deprecation of the overwrite argument began in AWS Terraform Provider v5.0.0 to give users time to adjust their configurations before its full removal in v6.0.

How to Prepare for v6.0:

Replace overwrite = true with an explicit import block for managing existing resources.
Replace overwrite = false with an ignore_changes lifecycle block to skip updates.
Until v6.0, keep overwrite = true if your setup relies on it for updates. Removing it prematurely in v5.x will default it to false, potentially causing configuration issues.

The Challenges This Change Introduces for Terraform Users

The removal of the overwrite argument in AWS Terraform Provider v6.0.0 introduces significant challenges for users, especially those who heavily rely on it in their existing configurations. This change, which was already marked for deprecation in AWS Terraform Provider v5.0.0, requires extensive code refactoring and the development of alternative logic, such as using explicit import blocks or lifecycle rules, to manage resource updates and existing parameters. Without proper preparation, upgrading to AWS Terraform Provider v6.0.0 may lead to broken pipelines, failed deployments, and increased complexity for DevOps teams. For many, adapting to this change under tight deadlines could be overwhelming, turning the transition into a time-intensive and stressful process. While the update promotes best practices, it demands careful planning and testing to ensure a smooth migration.

Workarounds and strategies to handle parameter updates effectively in AWS Terraform Provider v6.0.0

With the removal of the overwrite argument in AWS Terraform Provider v6.0.0, managing updates to AWS SSM Parameter Store requires alternative approaches. Below is a workaround that mimics the behavior of overwrite = true, ensuring parameters can be updated even when there are no changes to the parameter value. This method relies on using a dynamic resource to force updates when needed.

Example: Using random_id to Trigger Updates
The following configuration demonstrates how to manage parameter updates without the overwrite argument:

# Store the notification email ID in SSM Parameter Store
resource "aws_ssm_parameter" "notification_group_email" {
  name  = "/path/to/ssm"
  type  = "String"
  value = var.ssm_value

  lifecycle {
    create_before_destroy = true
    replace_triggered_by = [ random_id.force_ssm_update_trigger ]
  }
}

# Dynamic resource to trigger updates
resource "random_id" "force_ssm_update_trigger" {
  byte_length = 8
}

How This Works:

create_before_destroy:
Ensures that a new parameter is created before the existing one is destroyed, avoiding downtime during updates.
replace_triggered_by:
Links the parameter to the random_id resource. Any change to the random_id resource forces a replacement of the parameter.
random_id Resource:
Acts as a trigger for updates. By modifying or reapplying the configuration, the random_id value changes, causing the parameter to be updated.

Benefits of This Approach:

Mimics the behavior of overwrite = true without requiring manual intervention.
Provides control over when updates occur, even when the parameter value hasn’t changed.
Ensures smooth updates with minimal disruption.

For more details, check the official discussion.

Optimizing Security and Efficiency in AWS Database Migration with DMS: Understanding Outbound-Only Connectivity

Rajesh Murali Nair — Thu, 05 Dec 2024 22:54:30 +0000

Introduction

Migrating your databases to the AWS cloud using the Database Migration Service (DMS) is a smart choice for businesses seeking enhanced scalability, reliability, and cost-efficiency. When configuring your DMS instance, one crucial aspect to consider is network security. In this blog, we will explore why DMS instances require outbound-only connectivity, eliminating the need for incoming connections.

Understanding DMS Connectivity

DMS operates by reading data from a source database, processing it, and writing it to a target database. This migration process is designed to be an outbound-oriented operation. Here’s why DMS instances do not need incoming connections to themselves:

Outbound-Only Operations: DMS, as the name suggests, is a migration service. It’s responsible for transferring data from the source to the target database. This means that the DMS instance is the initiator of connections to both the source and target databases. In other words, it doesn’t need incoming connections from the outside to perform its core functions.
Enhanced Security: By limiting inbound connections to your DMS instance, you are significantly improving its security. You are reducing the attack surface, making it less vulnerable to potential threats. AWS and industry best practices recommend minimizing the exposure of resources by restricting inbound access.
Easier Security Management: When working with multiple DMS instances or various services in your AWS environment, maintaining and managing security can become complex if you need to define and maintain inbound security rules for each service. With outbound-only connectivity, you simplify the security group and Network Access Control List (NACL) configurations.
Regulatory Compliance: Many organizations, especially those in regulated industries, have stringent compliance requirements that restrict or prohibit incoming connections to certain resources. By adhering to outbound-only connectivity, you can maintain compliance with these security policies.
Network Isolation: By isolating your DMS instances from incoming connections, you reduce the risk of unintended access or breaches. This is particularly essential in sensitive or regulated environments where data security and isolation are paramount.

Configuring DMS for Outbound-Only Connectivity

To configure your DMS instance with outbound-only connectivity, you need to ensure that your security groups and network configurations are set up properly. While the DMS instance doesn’t require incoming connections, the source and target databases may require specific configurations to allow traffic from the DMS instance. This ensures that DMS can successfully read data from the source and write it to the target without exposing itself to unnecessary risks.

Conclusion

When using the AWS Database Migration Service, understanding the necessity of outbound-only connectivity for your DMS instance is key to optimizing security and efficiency. By embracing this approach, you can minimize security risks, simplify management, adhere to compliance requirements, and ensure the success of your database migration to the AWS cloud. Outbound-only connectivity is a secure and effective way to leverage the power of DMS while safeguarding your resources.

DEV Community: Rajesh Murali Nair

Deploy-Time Intelligence in AWS CDK: Custom Resources in Action

Introduction

The Real-Life Problem

Why CDK Alone Is Not Enough

The Solution: Lambda-Backed Custom Resource

Architecture Overview

CDK Stack Code (Python)

Lambda Code (Custom Resource Logic)

Why This Pattern Works Well

Conclusion

Building a Receipt-Scanning Feature for a Budgeting App with Amazon Bedrock

Introduction

Problem Statement: Manual Expense Tracking Doesn’t Scale

Feature Overview

Architecture Walkthrough: Receipt Processing Pipeline

Architecture Diagram

1. Ingestion: Uploading Receipts to Amazon S3

2. Event Trigger: AWS Lambda (receipt-analyzer)

3. Text Extraction: Amazon Textract

4. Semantic Parsing: Amazon Bedrock (Claude 3 Sonnet)

5. Persistence: Amazon DynamoDB

Why This Architecture Works Well

Conclusion

Exam Guide : GitHub Foundation Part 2

Contribution to open-source project on GitHub

Find an Open-Source Project That Needs Contributions

Understand Project Guidelines Before Contributing

Identify Tasks to Work On

Sponsor a project

Contribute to an open-source repository

Communicate Your Intent to Maintainers

Manage an InnerSource program by using GitHub

What is InnerSource?

Benefits of InnerSource

Set up an InnerSource program on GitHub

Set repository visibility and permissions

Repository Visibility

Repository Permission Levels

Create Discoverable Repositories

How GitHub Surfaces Your README

Manage Projects on GitHub

Create issue and pull request templates

Maintain a secure repository by using GitHub repository

Security Tab

Communicate a Security Policy with SECURITY.md

Keep Sensitive Files Out of Your Repository with .gitignore

Branch protection rules

Add a CODEOWNERS File

Automated Security in GitHub

GitHub Administration

How does GitHub organization and permissions work?

Managing enterprise permissions

Organization Permissions Levels

Enterprise Permission Levels

Team Synchronization

Searching GitHub

Organizing Work

Git History & Collaboration

Exam Guide : GitHub Foundation Part 1

Introduction to Git

What is Version Control?

What is Git?

What are Git Terminology?

What is the key difference between Git & GitHub?

Basic Git Commands

Introduction to GitHub

What is GitHub?

What is a repository?

What is Gists?

Key Features of Gists

Use Cases for Gists

Important Notes

Limitations of Gists

What are Wikis?

Components of the Github Glow

File States in Git

GitHub Flow

Git Flow

GitHub Flow vs Git Flow

2. Event Trigger: AWS Lambda (`receipt-analyzer`)

Communicate a Security Policy with `SECURITY.md`

Add a `CODEOWNERS` File