Forem: Laura

Course 3 of 3: AIOps ☁️💪

Laura — Tue, 07 Apr 2026 23:14:10 +0000

Introduction
You Can't Fix What You Can't See
1. Monitoring
2. Observability
3. Monitoring vs Observability
Observability + AIOps = Smarter IT Operations
AWS AIOps Tools
1. AWS CloudWatch Anomaly Detection
2. AWS X-Ray insights
3. AWS DevOps Guru
Better Dev Experience
1. Amazon Q DeveloperClosing Thoughts
Closing Thoughts

Introduction

Welcome to the third and final blog post of this 3-part series🎉 where I share my learning process in getting the DevOps and AI on AWS Specialization certification. The first blog is about Upgrading Apps with Gen AI and the second one is about CI/CD for Generative AI Applications .

This course is all about Artificial intelligence for IT operations (AIOps), which means using AI to maintain infrastructure. To learn more about what is AIOps, what are the benefits and use cases check this link out from Amazon website.

You Can't Fix What You Can't See

Monitoring

Monitoring checks systems health by collecting and analyzing data from systems, based on a predefined set of metrics and logs. In DevOps, it helps teams keep an eye on application health, catch known failures early, and avoid downtime.

Where monitoring really shines is spotting long-term trends, reveals how the app performs and how usage patterns changes over time. But, to be effective teams must know which metrics and logs to track.

Observability

Observability means being able to make sense of what's happening inside a complex system from it's external outputs. When a system is observable, engineers can pinpoint the root cause of a performance issue by analyzing the data already available, directly from telemetry data. Allows us to understand why an issue occurred.

The three pillars of observability are

Logs (application logs, what's is happening when a failure occurs?)
Metrics (CloudWatch metrics, how much CPU utilization? or app specific metrics)
Traces (A trace contains data from each services used to better understand what's the issue and where the error occurred).

Monitoring vs Obersavility

Monitoring	Observability
Tracks system's performance over time, it's main focus is in finding systems problems and notify stakeholders. Metrics could respond to questions like "Is my app up an running?"	Uses telemetry data to get a complete picture of the of overall network performance, making it easier to get the root cause of the issue.
Monitoring tools rely on predefined metrics and logs to identify systems errors, usage patterns and know failures but can't provide enough context by itself (Is the app online? Is it offline? Is it experiencing latency issues?)	Gives a team a complete view of the entire architecture, capturing configurations and data from across the network. Observability tools enhance telemetry data with additional context about the network environment.
Gather data on usage trends and performance, revealing what is happening within a system but they can't respond to "why this event occur?"	Observability tools goes deeper, provide more context and correlate seemingly unrelated system events.
Monitoring tools typically present system data trough dashboards to view key metrics. However fall short in tracing the origins of the system's errors.	Observability tools build maps and connect system errors to their root causes, automating the analysis process and making troubleshooting faster and easier.

Observability + AIOps = Smarter IT Operations

Improving observability means making sense of a large amounts of data coming from many different resources. This is where AIOps proves it's value, by automating the correlation of logs, traces, and metrics, identifying anomalies in real time, and reducing manual intervention for repetitive analysis tasks. Instead of digging into raw data, teams can focus on solving bigger issues. For example, when a latency spike shows up, AIOps points you straight to the service or component causing it.

Using AIOps It's like an AI assistant that constantly monitors you infrastructure identifying patterns and anomalies so the team doesn't have to monitor everything themselves.

Key Capabilities of AIOps:

✅ Anomaly Detection: The AI looks at your system's logs and metrics for suspicious activities, to catch issues before they become a problem. In my previous post I mentioned a CloudWatch feature that utilizes AI-powered Anomaly Detection.

✅ Predictive Analysis: Predicts future events based on historical data.

✅ Automated Root Cause Analysis: When something breaks, engineers typically have to manually check through logs to identify the issue. Automated root cause analysis saves time by streamlining this process.

✅ Remediation: Doesn't just tell you what's wrong, it can take action to fix it based on policies or real-time learning.

It can help you monitor and track the entire CI/CD pipeline in real-time to keep things running smoothly.

AIOps is focused on operations management. This includes: monitoring logs, real-time system health analysis and automated corrective actions

AWS AIOps Tools

AWS CloudWatch Anomaly Detection

CloudWatch is a comprehensive monitoring and observability platform for your cloud resources and applications. The core components are alarms (notify me you when a metric crosses a defined threshold), metrics (data points collected over time) and logs.

When talking about alarms, how do we determine the appropriate threshold to set? CloudWatch can analyze your metrics and establish these thresholds for you. To accomplish this, you can use a feature called CloudWatch anomaly detection.

AWS X-Ray Insights

AWS X-Ray insights is a feature that keeps a continuous watch over trace data in your account to identify any issues that may occur. It uses machine learning to detect anomalies and patterns that could cause issues. When anomalies, error rates or fault rates surpass the expected range, it generates an insight that documents the issue and monitors its impact until it's resolved. It also helps you identify the issues's severity and the priority.

AWS DevOps Guru

DevOps Guru uses machine learning to improve application availability by detecting any anomalous behavior. How does it work? DevOps Guru employs machine learning to identify anomalies, when an anomaly is detected it generates an insight, which is a compilation of related anomalies within an analyzed resource.

There are two types of insights:

👉 Reactive Insights: Contain anomalies with recommendations, related metrics and events.

👉 Proactive Insights: Tells you about issues that are predicted to affect your application in the future.

You can receive notifications when an issue arises by setting up an SNS notification topic and configure an email to be alerted.

Better Dev Experience

Amazon Q Developer Security Scanning

This tool helps write secure code and is designed to support developers during the development process. While AIOps concentrates on operational aspects post-deployment, Amazon Q Developer primarily targets the development phase. Both AI-powered tools enhance processes, but at different stages.

We always want to minimize and prevent vulnerabilities to reach production, here's where Amazon Q Developer could be beneficial. It offers a security scanning feature that scans your code and allows you to catch vulnerabilities early in the process, before reaching production. You can view details about a finding, relevant information and It can also provide suggestions for fixing the issue.

As security policies evolve, this tool incorporates this new detectors ensuring the scans are up-to-date.

Closing Thoughts

And this is the last blog post in this 3-part series where I share my journey of obtaining the DevOps and AI on AWS Specialization Certification 🎉💪

I learned a lot, and this specialization added tremendous value to me. I highly recommend it. Thanks for reading through. Sharing my journey with you all is a pleasure🙌.

I'm happy to connect with you on LinkedIn, feel free to send a DM and share your thoughts on this blog series.

Course 2 of 3: CI/CD for Generative AI Applications ⚒️

Laura — Tue, 07 Apr 2026 23:06:07 +0000

Introduction
Intro to DevOps
Infrastructure As Code (IaC) in DevOps
1. The Hidden Cost of Manual Processes
2. IaC Benefits
3. AWS IaC Tools Overview
Code, Build And Test Phases
1. Code Phase
2. Build Phase
3. Test Phase
AI Capabilities in DevOps Workflows
Testing GenAI Apps
Tests in the CI Flow
Continuous Integration (CI)
Hands-on Labs: Set Up a CI/CD Pipeline
1. Create the CodePipeline
2. Create the CodeDeploy project
3. Adding CodeDeploy to CodePipeline
Serverless Deployment Strategies
AWS CodeDeploy in Your Pipeline
CI/CD for Infrastructure
Automate Infra Deployment With CDK in CI/CD Pipeline
Monitoring Your Infrastructure
1. Monitor, Log, and Audit With CloudTrail
2. AWS CloudWatch
3. A Powerful Mix: CloudWatch + CloudTrail
4. Monitoring with AWS X-Ray
Operating with Confidence
1. Configuration Change Detection with AWS Config
2. AWS Systems Manager
Wrapping Up Part Two: The Journey Continues

Introduction

This is the second blog post in a series of three, where I share my experience studying and earning the DevOps and AI on AWS Specialization from Coursera. If you didn't read the first blogpost, here's the link in case you want to have a look :)

Intro To DevOps

The heart of the first module is about what's the problem DevOps methodologies are solving: Get software updates to production as quickly as possible and keep quality at a high-level. DevOps mainly focus on two things: collaboration and automation.

When talking about the steps involved in creating and deploying software, we refer to sharing our work in source code repositories, building (creating an artifact to deploy the application), and then testing the application to ensure everything functions as expected. We usually automate this process with continuous integration to automatically build and run tests, so developers integrate their changes frequently.

After we have the artifact built and test, we are ready to release and deploy, the software is ready to go. We take this artifact and deliver to the servers that host the application. We can use tools for continuous deployment.

Another important aspect is automating the creation and updating of infrastructure and, ideally, we aim to include a step for proactive anomaly detection to quickly identify any unusual activity that might degrade our application's performance.

In summary, the process involves continuous integration, automated testing, continuous deployment, and infrastructure as code.

Infrastructure As Code (IaC) in DevOps

What is Infrastructure as Code? Let's see the definition based on AWS website:

Infrastructure as code (IaC) is the ability to provision and support your computing infrastructure using code instead of manual processes and settings. Any application environment requires many infrastructure components like operating systems, database connections, and storage. Developers have to regularly set up, update, and maintain the infrastructure to develop, test, and deploy applications.

Manual infrastructure management is time-consuming and prone to error—especially when you manage applications at scale. Infrastructure as code lets you define your infrastructure's desired state without including all the steps to get to that state. It automates infrastructure management so developers can focus on building and improving applications instead of managing environments. Organizations use infrastructure as code to control costs, reduce risks, and respond with speed to new business opportunities.

The ultimate goal is to automate as much of the tasks as possible. We move away from the manual approach. We want to have the task described as files.

Going back to the TravelGuide App in Course 1 of this DevOps and AI Specialization on AWS, we understand that the application's code requires a platform to operate, such as compute resources (in this case an EC2 instance).

Our application upgrade also requires the creation of certain cloud resources. We are utilizing a Bedrock knowledge base that needs an S3 bucket as a data source. The EC2 instances running the application will need a VPC network. Additionally, an IAM role is required for authentication, along with IAM policies to manage permissions.

Infrastructure also includes the configuration of these resources. This configuration is not static, eventually, we'll need to modify and maintain the infrastructure, and we must be agile when making these changes.

In AWS, this is essential for scaling and automating tasks, particularly in AI-driven applications such as the generative AI feature in the TravelGuideApp.

Adopting IaC eliminates repetitive manual tasks, ensuring infrastructure changes are documented, consistent, and easily auditable.

The Hidden Cost of Manual Processes

💸 Manually stopping and starting EC2 instances or modifying configurations is time-consuming.

💸 Inconsistent changes across instances increase the likelihood of mistakes.

💸 Managing large numbers of resources is impractical without automation (hard to scale).

💸 Limited traceability: Manual changes lack documentation and a change history (limited traceability).

IaC Benefits

👉 Documentation: The code can act as a form of documentation. We can check the changes on the source control (full history changes).

👉 Pull requests reviews: Other members of the team can comment on the infrastructure changes.

👉 Scale: Manual work consumes time that could be better spent on other tasks. Is better at scale when I need to make hundreds of changes.

👉 No human error: Automating tasks removed the human error with manual process.

AWS IaC Tools Overview

The AWS CloudFormation is a service that helps you model and set up your AWS resources . You create a template (JSON or YAML files) that describes all the AWS resources that you want. It uses a declarative language to define the desired state.

The AWS Cloud Development Kit or CDK is an open-source framework we use to model and provision cloud-based applications with familiar programming languages. CDK uses CloudFormation to create resources.

More on this tools on the "CI/CD for Infrastructure" section later.

Code, Build And Test Phases

Code Phase

Without developer and operation teams being integrated and collaborating on a regular basis, it might take a while to figure things out when something goes wrong. With DevOps this has evolved, these two teams can work together as a unified team. This impacts how developer writes and manage the code from the beginning to deployment.

Both teams work together more closely, collaboration becomes a key player here. They help each other and understand more about the whole application lifecycle. Developers needs to be mindful of how the code will be deployed, how can me monitored, maintained and perform in different environments.

Operations could provide feedback on how the application is performing and provide insights to developers so they can optimize the application of fix bugs. They may also assess code for security, observability, monitoring, and performance.

Occasionally, code changes can affect operations in ways developers might not immediately consider. Involving individuals with different perspectives can help address potential issues early on. Proactive communication enables both teams to anticipate issues earlier in the development cycle.

Without DevOps, much of the development process might be manual, making automation crucial. You would want to have processes that automates the application and infrastructure deployment.

Infrastructure-as-code tools allow you to create templates for infrastructure, write scripts for testing, and use automated deployment tools. This ensures that your code not only functions correctly but also includes the necessary assets for building, testing, and deploying through an automated pipeline.

How developers commit or deploy code can change with continuous integration and continuous deployment or delivery or CI/CD. This enables your code to be tested more frequently with automated tools, allowing for incremental deployment of changes. By making numerous small updates instead of infrequent, larger ones, changes reach end-users more quickly, accelerating the feedback loop.

Developers should adopt the best practice of committing smaller, more frequent changes. Additionally, each commit must be production-ready, as it could be deployed to users at any moment.

Finally, monitoring and feedback loops become integral to the development process. Developers become more aware in the operation of the application, integrating tools for logs and metrics to quickly identify issues.

Build Phase

This phase comes right after the code phase. The build phase will take the code and compile it if needed, depending on the programming language being used. This phase also includes automated testing and some linter process (linters ensure higher code quality).

The end result of this phase would be an artifact to be deployed.

If any of these steps (retrieving dependencies, compiling, packaging, or testing) fails, it results in a broken build. A broken build indicates that the code in the deployment branch is not in a functional state. In this case we want to get our code back to a good state as quick as possible.

In modern DevOps practices, it's typical to run a build with every commit. There's a service called AWS CodeBuild, is a fully managed service. It compiles your source code, runs unit tests, and generates artifacts ready for deployment. It integrates with other AWS services like AWS CodePipeline and AWS CodeDeploy.

AWS CodeBuild is the tool we use for continuous integration, it can scale up and run multiple builds while multiple developers are working on the application code.

To configure builds for your application, include a buildspec.yml file with your source code. This file outlines your desired build process, which AWS CodeBuild reads and executes.

Test Phase

Testing can also save money. The earlier we catch errors in the development process, the less expensive they are to fix.

We have Functional and Non-functional Testing. We conduct various types of testing to prevent issues from occurring in production.

While discussing continuous integration, we can add automated tests to every build. Functional testing begins with unit testing, these tests run quickly and provide feedback. We can include a linter to assess code quality. The goal of all tests is consistent: to prevent any defects from reaching production.

By incorporating DevOps principles, we can automate much of our testing, ensuring rapid feedback if any changes introduce defects.

AI Capabilities in DevOps Workflows

Generative AI applications, such as those using AWS Bedrock, present distinct challenges and opportunities within a DevOps workflow.

Returning to the TravelGuide App from course 1, we aim to follow good DevOps practices, and you might wonder if working with GenAI changes anything in the process. The app calls the AWS API in the same way other services do. Their behavior can vary based on customizations like prompt engineering and model fine-tuning. What sets it apart are the features of Bedrock that allow us to customize our responses.

We can customize by fine-tuning or pre-training a model, and it is relatively straightforward to operationalize because we access features through an API rather than building our own model. If we customize something we want to monitor the benefits of this customization, have these changes improved my app? To measure improvement, Bedrock metrics are being created by model, we can run tests and check the metrics created by Bedrock.

Useful metrics

InvocationLatency (Measure response time changes due to prompt/model updates)
Input/Output Token Count (Track token usage to optimize cost and performance)
Number of Invocations (Monitor service usage patterns)
Custom Metrics (CloudWatch, capture user feedback directly through the application).

Testing GenAI Apps

The responses from Bedrock are non-deterministic, the same input can yield different outputs or behaviors in different runs, resulting in unpredictable and non-repeatable behavior.

We can test the code in isolation because the unit tests never talk to Bedrock. We can write our own simulated responses instead of having to do setup to reproduce the same specific edge case. You can now get a sense of this isn't going to be too different from writing regular unit tests that is expecting a response from a database. I would want to mock the response so I can control exactly the response I get from Bedrock service.

Let's explore how to perform API calls to retrieve and generate data from the Bedrock knowledge base. First, we need to examine the response from the retrieve and generate API.

HTTP/1.1 200
Content-type: application/json

{
   "citations": [ 
      { 
         "generatedResponsePart": { 
            "textResponsePart": { 
               "span": { 
                  "end": number,
                  "start": number
               },
               "text": "string"
            }
         },
         "retrievedReferences": [ 
            { 
               "content": { 
                  "audio": { 
                     "s3Uri": "string",
                     "transcription": "string"
                  },
                  "byteContent": "string",
                  "row": [ 
                     { 
                        "columnName": "string",
                        "columnValue": "string",
                        "type": "string"
                     }
                  ],
                  "text": "string",
                  "type": "string",
                  "video": { 
                     "s3Uri": "string",
                     "summary": "string"
                  }
               },
               "location": { 
                  "confluenceLocation": { 
                     "url": "string"
                  },
                  "customDocumentLocation": { 
                     "id": "string"
                  },
                  "kendraDocumentLocation": { 
                     "uri": "string"
                  },
                  "s3Location": { 
                     "uri": "string"
                  },
                  "salesforceLocation": { 
                     "url": "string"
                  },
                  "sharePointLocation": { 
                     "url": "string"
                  },
                  "sqlLocation": { 
                     "query": "string"
                  },
                  "type": "string",
                  "webLocation": { 
                     "url": "string"
                  }
               },
               "metadata": { 
                  "string" : JSON value 
               }
            }
         ]
      }
   ],
   "guardrailAction": "string",
   "output": { 
      "text": "string"
   },
   "sessionId": "string"
}

Response Elements (from official docs):

citations: A list of segments of the generated response that are based on sources in the knowledge base, alongside information about the sources.
guardrailAction: Indicates whether a guardrail intervention is present in the response..
output: Contains the response generated from querying the knowledge base.
sessionId: The unique identifier of the session. When you first make a RetrieveAndGenerate request, Amazon Bedrock automatically generates this value. You must reuse this value for all subsequent requests in the same conversational session. This value allows Amazon Bedrock to maintain context and knowledge from previous interactions. You can't explicitly set the sessionId yourself.

The citation has a property retrievedReferences, this is one or more knowledge bases and metadata. The unit test will loop through the citations array and build a response that contains the generated response.

Tests in the CI Flow

At this point, the unit tests are running locally on my environment but what if I like to add these to the CI pipeline? AWS CodeBuild is great to run our tests.

We may have a local script for running the tests, and we need to configure the steps that CodeBuild will execute in a buildspec file. This file will specify what we want AWS CodeBuild to do, what commands you want to run in an specific build.

Here's the official docs in case you want to have a look.

Continuous Integration (CI)

We would like to run the tests every time a developer push a commit. We need to decide which step goes before the other, like an orchestrator. For this we can use a service called AWS CodePipeline. We can set up a pipeline once, it will detect when a new commit is being pushed and restart the pipeline whenever changes are detected.

The pipelines are built with stages (logical pieces that describe a phase in the pipeline, e.g., Source, Build, Test). We can add different stages later on, like a deploy stage. Approval and invoke actions are also available, to control what get's deployed to production or not. Waiting on this final check is an extra layer of safety.

We can also define actions (tasks executed within each stage) to run custom scripts, trigger other systems or perform checks. The customization is pretty good.

When we release changes in an execution pipeline, push a new commit, or merge a pull request, the source stage monitors the repository for changes, and each execution receives its own ID. When we run our pipeline, we can view the progress in real time and the status of each stage. If an action fails, we can retry it and also view the build logs, which is very useful for debugging.

Hands-on Labs: Set Up a CI/CD Pipeline

Create the CodePipeline

We'll set up the pipeline for CI/CD, starting with a CodeBuild project to perform linting, unit testing, and code coverage reporting.

At the top of the AWS Management Console, in the search bar, search for CodePipeline and Build Custom Pipeline.

On the Choose pipeline settings page, give it a name and configure the service role.

Continue to Add source stage page and configure the source.

On the Add build stage page, configure the build provider.

Select a name for your project and Create project. This launches a new browser window to create the CodeBuild project.

Select the Service role, you can either select an existing service role or a new service role.

In the Buildspec section, select Use a buildspec file.

Continue to CodePipeline. At this point, you can add a test page, but this time I choose Skip test stage and Skip deploy stage.

On the Review page, choose Create pipeline.

Once the pipeline is created, it automatically starts. Wait for both stages to display a status of Succeeded.

In the Build stage, click the AWS CodeBuild link and review the build logs. You can inspect both the Code Coverage and Test reports on the Reports tab.

Create the CodeDeploy project

In this task, we'll create the CodeDeploy app and deployment group to deploy the application to an EC2 instance.

Head over to the AWS console and search for a service called CodeDeploy.

Choose Applications and Create application. Select EC2 / On-premises and Create application.

Next, choose Create deployment group and select the service role.

Configure the environment, choose Amazon EC2 instances.

In the Agent configuration with AWS Systems Manager section, for Install AWS CodeDeploy Agent, select Never.

For Load balancer, clear Enable load balancing and choose Create deployment group.

Adding CodeDeploy to CodePipeline

In this task, we'll update the pipeline to add a new stage for deploying application updates to the EC2 instance. On the AWS Management Console search for CodePipeline.

Choose your app, in my case travelapp-pipeline pipeline, then choose Edit. Under Edit: Build, choose ＋ Add stage.

For Stage name, enter Deploy, then choose Add Stage.

Under Edit: Deploy, choose ＋ Add action group.

And add the following configuration

Finally, Save.

Go back to CodePipeline, scroll to the top of the pipeline, and select Release change. To confirm, click Release. Wait for the new Deploy stage to show Succeeded. The application has been successfully deployed by CodeBuild.

Serverless Deployment Strategies

Various strategies exist for deploying serverless applications. To deploy them effectively, it's important to understand these strategies and consider factors such as rollback, scaling, and monitoring.

Here's the definition of each deployment strategies from official documentation:

Blue/Green Deployment

Blue/green deployments provide releases with near zero-downtime and rollback capabilities. The fundamental idea behind blue/green deployment is to shift traffic between two identical environments that are running different versions of your application. The blue environment represents the current application version serving production traffic. In parallel, the green environment is staged running a different version of your application. After the green environment is ready and tested, production traffic is redirected from blue to green. If any problems are identified, you can roll back by reverting traffic back to the blue environment.

Linear Deployment

Linear deployment means traffic is shifted in equal increments with an equal number of minutes between each increment. You can choose from predefined linear options that specify the percentage of traffic shifted in each increment and the number of minutes between each increment.

Canary Deployment

The purpose of a canary deployment is to reduce the risk of deploying a new version that impacts the workload. The method will incrementally deploy the new version, making it visible to new users in a slow fashion. As you gain confidence in the deployment, you will deploy it to replace the current version in its entirety.

All-at-Once Deployment

All-at-once deployment means all traffic is shifted from the original environment to the replacement environment all at once.

Selecting the appropriate deployment strategy depends on the application and its specific requirements.

AWS CodeDeploy in Your Pipeline

After the continuous integration phase completes all tests and receives approval, AWS CodeDeploy is now ready to deploy the application to the production environment.

To incorporate the continuous deployment phase, we need to update the pipeline to include CodeDeploy in the CI/CD process. We can add a new stage and call it deploy and then select CodeDeploy as the action provider.

CI/CD for Infrastructure

A good practice is to maintain 2 different pipelines, one for the application code and one for the infrastructure changes.

Let's discuss elevating your automation by using infrastructure as code with AWS CloudFormation and its role in a CI/CD workflow.

AWS CloudFormation

AWS CloudFormation is a service that allows us to define our infrastructure in a file (JSON or YAML) and have CloudFormation handle the provisioning. The file is the template (something you define) and the infrastructure components are called stack (the infrastructure that gets created).

Let's check the following example, in this case AWS::S3::Bucket resource creates an Amazon S3 bucket:

{
  "Type" : "AWS::S3::Bucket",
  "Properties" : {
      "AbacStatus" : String,
      "AccelerateConfiguration" : AccelerateConfiguration,
      "AccessControl" : String,
      "AnalyticsConfigurations" : [ AnalyticsConfiguration, ... ],
      "BucketEncryption" : BucketEncryption,
      "BucketName" : String,
      "CorsConfiguration" : CorsConfiguration,
      "IntelligentTieringConfigurations" : [ IntelligentTieringConfiguration, ... ],
      "InventoryConfigurations" : [ InventoryConfiguration, ... ],
      "LifecycleConfiguration" : LifecycleConfiguration,
      "LoggingConfiguration" : LoggingConfiguration,
      "MetadataConfiguration" : MetadataConfiguration,
      "MetadataTableConfiguration" : MetadataTableConfiguration,
      "MetricsConfigurations" : [ MetricsConfiguration, ... ],
      "NotificationConfiguration" : NotificationConfiguration,
      "ObjectLockConfiguration" : ObjectLockConfiguration,
      "ObjectLockEnabled" : Boolean,
      "OwnershipControls" : OwnershipControls,
      "PublicAccessBlockConfiguration" : PublicAccessBlockConfiguration,
      "ReplicationConfiguration" : ReplicationConfiguration,
      "Tags" : [ Tag, ... ],
      "VersioningConfiguration" : VersioningConfiguration,
      "WebsiteConfiguration" : WebsiteConfiguration
    }
}

This code snippet is from the official AWS documentation. It list all possible properties.

Here's how it would look like in real life:

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "S3Bucket": {
            "Type": "AWS::S3::Bucket",
            "Properties": {
                "PublicAccessBlockConfiguration": {
                    "BlockPublicAcls": false,
                    "BlockPublicPolicy": false,
                    "IgnorePublicAcls": false,
                    "RestrictPublicBuckets": false
                },
                "WebsiteConfiguration": {
                    "IndexDocument": "index.html",
                    "ErrorDocument": "error.html"
                }
            },
            "DeletionPolicy": "Retain",
            "UpdateReplacePolicy": "Retain"
        },
        "BucketPolicy": {
            "Type": "AWS::S3::BucketPolicy",
            "Properties": {
                "PolicyDocument": {
                    "Id": "MyPolicy",
                    "Version": "2012-10-17",                 
                    "Statement": [
                        {
                            "Sid": "PublicReadForGetBucketObjects",
                            "Effect": "Allow",
                            "Principal": "*",
                            "Action": "s3:GetObject",
                            "Resource": {
                                "Fn::Join": [
                                    "",
                                    [
                                        "arn:aws:s3:::",
                                        {
                                            "Ref": "S3Bucket"
                                        },
                                        "/*"
                                    ]
                                ]
                            }
                        }
                    ]
                },
                "Bucket": {
                    "Ref": "S3Bucket"
                }
            }
        }
    },
    "Outputs": {
        "WebsiteURL": {
            "Value": {
                "Fn::GetAtt": [
                    "S3Bucket",
                    "WebsiteURL"
                ]
            },
            "Description": "URL for website hosted on S3"
        },
        "S3BucketSecureURL": {
            "Value": {
                "Fn::Join": [
                    "",
                    [
                        "https://",
                        {
                            "Fn::GetAtt": [
                                "S3Bucket",
                                "DomainName"
                            ]
                        }
                    ]
                ]
            },
            "Description": "Name of S3 bucket to hold website content"
        }
    }
}

Or YAML version:

AWSTemplateFormatVersion: 2010-09-09
Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      PublicAccessBlockConfiguration:
        BlockPublicAcls: false
        BlockPublicPolicy: false
        IgnorePublicAcls: false
        RestrictPublicBuckets: false
      WebsiteConfiguration:
        IndexDocument: index.html
        ErrorDocument: error.html
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
  BucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      PolicyDocument:
        Id: MyPolicy
        Version: 2012-10-17                  
        Statement:
          - Sid: PublicReadForGetBucketObjects
            Effect: Allow
            Principal: '*'
            Action: 's3:GetObject'
            Resource: !Join 
              - ''
              - - 'arn:aws:s3:::'
                - !Ref S3Bucket
                - /*
      Bucket: !Ref S3Bucket
Outputs:
  WebsiteURL:
    Value: !GetAtt 
      - S3Bucket
      - WebsiteURL
    Description: URL for website hosted on S3
  S3BucketSecureURL:
    Value: !Join 
      - ''
      - - 'https://'
        - !GetAtt 
          - S3Bucket
          - DomainName
    Description: Name of S3 bucket to hold website content

To update or add a new stack CloudFormation will review the file for changes and execute the update. Similarly, for deletions, it will identify differences and proceed accordingly. If you wish to keep certain resources from being deleted, you can use the DeletionPolicy property.

Variables are not support on CloudFormation but the functionality can be achieved using parameters, mappings (for configuration lookups) and dynamic references (securely retrieve values from AWS Secrets Manager or Systems Manager Parameter Store).

We can also use nested stacks to break down complex template into smaller and reusable stacks. The CloudFormation Modules are reusable and self-contained configurations that can be used across team and projects (just like libraries).

To prevent errors in CloudFormation we could use a powerful method that uses a CloudFormation featured called change sets, it can predict the results of an update stack operation so we can check if those are the changes we want before proceeding. You do create a change set operation like this:

aws cloudformation create-change-set --stack-name MyStack \
    --change-set-name SampleChangeSet --use-previous-template \
    --parameters \
      ParameterKey="InstanceType",UsePreviousValue=true ParameterKey="KeyPairName",UsePreviousValue=true ParameterKey="Purpose",ParameterValue="production"

This way, we have a chance to review changes more carefully.

AWS CDK

The AWS Cloud Development Kit (CDK) is an open-source software development framework that allows developers to define cloud infrastructure using familiar programming languages.

CDK provides pre-built components called constructs which are abstractions of AWS resources.

This is a collection of pre-written modular and reusable pieces of code, called constructs, that you can use, modify, and integrate to develop your infrastructure quickly.

There are different construct levels, you can refer to the official docs.

AWS CDK works out of the box with AWS CloudFormation to deploy and provision infrastructure on AWS.

Choosing between AWS CDK and CloudFormation depends on the specific scenario, team expertise, and project complexity.

Automate Infra Deployment With CDK in CI/CD Pipeline

To automate deployment with CDK in a CI/CD pipeline, add a Deploy stage to the previously built CodePipeline and release the change.

In the this case, the application will authenticate with AWS services DynamoDB and Bedrock using the IAM role and instance profile created by the CDK stack.

Monitoring Your Infrastructure

Monitor, Log, and Audit With CloudTrail

AWS CloudTrail is a service that enables you to track API actions within an AWS account. It allows you to view the activity of resources and users based on the API calls made in the account. For example, if someone creates an S3 bucket, CloudTrail will log that.

This service is essential for tracking activity, as it helps identify misconfigurations or unauthorized access. It's also valuable for forensic analysis after a security event, providing historical data on all users and activities, and supports centralized management across multiple accounts.

This service offers several benefits, including enhanced cross-account visibility, simplified compliance auditing, and easier troubleshooting through aggregated logs.

AWS CloudWatch

When issues arise with your application, you'll want to address them as soon as possible and even before your customers realize it. A fantastic monitoring and observability service is AWS CloudWatch.

AWS CloudWatch comes with some metrics out of the box already but the cool thing is that you can create custom metrics. You can also set up an alarm based on those metrics, allowing the team to receive notifications when it enters the alarm state. This service includes more features like dashboards, logs, events, network monitoring, and more.

For deployment and CI/CD, Amazon CloudWatch is invaluable because it can immediately collect metrics and logs each time a new version of your application is deployed.

CloudWatch Logs agent is a software component that allows you to collect logs from your services. It allows you to monitor your infrastructure and applications more thoroughly than the default basic monitoring.

Finally, I wanted to talk about another cool feature called CloudWatch anomaly detection, you can enable anomaly detection for a metric and will use machine learning to identify unusual patterns in your data automatically. Isn't that amazing?

A Powerful Mix: CloudWatch + CloudTrail

Did you know that you can create CloudWatch metrics and alarms from CloudTrail data? You can set up a new trail and perform some actions so this new trail logs the events. Simply create a new trail, follow on-screen steps and enable CloudWatch Logs and the select log events.

Review and create the trail. Generate data by navigating the console and exploring various services to ensure the new trail logs the new data, regardless if it's done through the management console or programmatically, CloudTrail will capture all activity.

Finally, we can view the CloudTrail logs from the Trails menu option, however, we'll notice that these trails are somewhat difficult to scan when you're searching for a specific pattern or detail. If you enabled CloudWatch, you will be able to see CloudWatch Logs, not as a compressed text file but as logs which makes easier to do searches and navigate the data. We can create filters, and with these filters, we can create alarms.

Here's more about this in the official documentation.

Monitoring with AWS X-Ray

AWS X-Ray is a service that gathers data on requests handled by your application and offers tools to view, filter, and analyze this data, helping you identify issues and opportunities for optimization. It can track requests across various AWS resources and microservices applications, allowing you to identify delays and errors.

To capture data from my applications, we need to use AWS Distro for OpenTelemetry (ADOT). We can use an OpenTelemetry SDK to instrument our application and an ADOT collector to receive and export traces to the AWS X-Ray service. OpenTelemetry SDKs are an industry standard for tracing instrumentation and support AWS X-Ray, has a large number of library instrumentations implementations for a lot of different languages and it's vendor-agnostic. Alternatively, you can use the AWS X-Ray SDK, an AWS's proprietary distributed tracing solution, which is integrated with the AWS ecosystem.

After installing OpenTelemetry to instrument the application and beginning to receive traces in the AWS X-Ray service, we can now view the application's activity. This activity can be accessed on the X-Ray console, where you can view the service map generated from the traces, trace requests through various components, identify errors, and examine a visual map that illustrates the flow of requests.

Operating with Confidence

Configuration Change Detection with AWS Config

AWS Config is a service that offers a comprehensive view of the resources linked to our AWS account. It details their configurations, interrelationships, and any changes in these configurations and relationships over time. AWS Config can create a dashboard displaying noncompliant resources, it helps us understand the state of our AWS resources and how they evolve over time.

Even though AWS Config provides AWS managed rules, you can also create custom rules to check things you want and report back to AWS Config.

While AWS CloudTrail acts as a record, providing evidence of activities within the infrastructure, AWS Config highlights the changes that occur. Each service has a distinct log format, so CloudTrail details every aspect of the API call, whereas Config shows the state of the resource before and after a change.

🙌 AWS Config highlights the changes on the resource side, while CloudTrail provides the evidence.

Some benefits..

👉 Integrates effectively with other AWS services

👉 It monitors configuration changes for supported AWS services, logs the details, and maintains a history for analysis.

👉 The service can automatically evaluate resource configurations against compliance rules and identify any deviations.

AWS Systems Manager

We can gain centralized operational insights with AWS Systems Manager. It's a managed service that we can use to view and control the infrastructure on AWS. It simplifies operations such as patch management, configuration updates, and instance monitoring through a single interface, instead of managing servers manually.

It's designed to assist in mitigating and recovering from incidents that impact our applications hosted on AWS.

Key features include executing scripts or predefined workflows to simplifying repetitive tasks, applying security updates across instances, securely storing and retrieving credentials, obtaining metadata about instances, and managing them without the need for SSH, enhancing security.

There's an interesting tool of AWS Systems Manager called Parameter Store. It provides secure storage for secrets and other data. This helps enforce security and can be referenced from scripts, code or inside CloudFormation resources.

Wrapping Up Part Two: The Journey Continues

If you made it this far, THANK YOU so much 🥹🙏, it really means a lot. I started writing this series simply to document what I've been learning, and if even one person finds it useful or feels a little more inspired to explore AWS and cloud, then it was all worth it.

I especially hope this reaches other women who are curious about cloud but maybe haven't made the jump yet, trust me, you belong here just as much as anyone else, and the community is bigger and more welcoming than you might think.

Part 3 is on its way, so stay tuned, there's still more to cover and more to share.

See you in the next one 🚀

Course 1 of 3: Upgrading Apps with Gen AI 🤖

Laura — Tue, 07 Apr 2026 22:45:55 +0000

Introduction
Upgrading a TravelGuide App with Generative AI
Some Basic Concepts Before We Proceed (Skip If You Want)
Amazon Bedrock: The Problems It Actually Solves
Custom Knowledge Bases And Model Customization in Amazon Bedrock
Hands On Lab: Creating a Knowledge Base
AI Safety Controls with Amazon Bedrock Guardrails
Integrating AI Models Through the Bedrock API
Engineering Better Conversations: Prompt Engineering
Next Steps

Introduction

I wanted to sharpen my AWS skills and understand where GenAI actually fits in the DevOps pipeline, not just the hype around it. I did some research and came across this blog post.

Two things were on my mind: deepen my AWS expertise and understand how to responsibly integrate GenAI into production systems.

This is the first blog post in a series of three, where I share my experience studying and earning the DevOps and AI on AWS Specialization from Coursera.

Upgrading A TravelGuide App with Generative AI

The first course is called "DevOps and AI on AWS: Upgrading Apps with Generative AI”, the title is pretty self explanatory but, to be completely honest, I’ve never used an AWS GenAI service like Amazon Bedrock before.

I had some experience integrating the Gemini API into a frontend app. If you've been following my previous blog posts, you probably know that I used to be a developer and because I wanted to learn how to integrate AI into a Next.js app, I built an app called SummarAI. This app lets you upload a PDF and instantly extracts key insights using AI. In that occation, I worked with the Gemini AI API, but I knew AWS offers an interesting set of tools when it comes to AI, the absolute star is Amazon Bedrock.

This first course focuses on creating a travel guide application that collects travel information for various destinations. It also helps create itineraries for travelers to follow and allows them to leave reviews of the cities they visit.

It’s a python app hosted on an EC2 instance, that currently reads items with Boto3 from DynamoDB tables and displays them.

Some Basic Concepts Before We Proceed (Skip If You Want)

What is Generative AI?

Generative artificial intelligence (generative AI) is a type of AI that can create new content and ideas, including conversations, stories, images, videos, and music. It can learn human language, programming languages, art, chemistry, biology, or any complex subject matter. It reuses what it knows to solve new problems.

What is LLM (Large Language Model)?

Large language models, also known as LLMs, are very large deep learning models that are pre-trained on vast amounts of data. The underlying transformer is a set of neural networks that consist of an encoder and a decoder with self-attention capabilities. The encoder and decoder extract meanings from a sequence of text and understand the relationships between words and phrases in it.

Amazon Bedrock: The Problems It Actually Solves

As I go through the course, I can tell this TravelGuide app comes with some limitations: For each city, the the content needs to be written and edited, there’s a manual step that requires researching and crafting the itineraries, this takes a lot of time. Can you imagine if we want to add more cities as the app scales? This process is very time consuming and limits how quickly we can escalate the app. Another limitation is that the itineraries can't be personalized for individual needs. This is static content, so an itinerary for someone interested in pubs would look very different from one created for someone more into museums who doesn't like nights out.

We could solve these issues and enhance the app by using a service called Amazon Bedrock to generate travel recommendations or itineraries. As its own web page says, Amazon Bedrock is “The platform for building generative AI applications and agents at production scale”. It’s a fully managed AWS service that enables building generative AI apps using foundation models.

We could use the foundation models provided by Bedrock through an API to create content and generate results in real-time with prompts. This would allow us to create travel recommendations and itineraries, while AWS takes care of the infrastructure needed to run and manage these models.

Amazon Bedrock provides several different foundation models (I'll refer to them as FMs from now on), and you might feel the same way I did when I started learning about this, it's hard to choose the right model for the use case. How do you pick the right FM for the task you need to complete? Fortunately, we can categorize FMs by the inputs and outputs they can handle.

👉 Inputs are generally text and image.

👉 Outputs can be text, chat, image, and embeddings.

You might see the term "embeddings" and wonder what it means. I wanted to share a great website that explains embeddings in a very creative way: LLM Embeddings Explained: A Visual and Intuitive Guide .

In a nutshell, embedding vectors are used to find related content when retrieving and enhancing information. Amazon Bedrock Knowledge Bases implement Retrieval-Augmented Generation (RAG) using embeddings.

With Amazon Bedrock Knowledge Bases, you can provide foundation models and agents with contextual information from your company’s private data sources to deliver more relevant, accurate, and customized responses.

Here’s a comparative table of the supported foundation models in Amazon Bedrock.

Custom Knowledge Bases And Model Customization in Amazon Bedrock

Let’s say we want to integrate our private company’s owns data with Bedrock, so the reviews are more relevant for the users. We are talking about private and proprietary data that is owned by a company, and by default, Amazon Bedrock doesn’t have access to this data.

You can integrate your private data by either customize the model or use Knowledge Bases.

Customize the model

Train the model on private data, this would lead to better performance for specific use-cases and create a better customer experience. Amazon Bedrock provides the following methods:

Distillation → Transfers knowledge from a larger, more intelligent model (teacher) to a smaller, faster, and cost-efficient model (student).

Reinforcement fine-tuning → Improves foundation model alignment with your specific use case through feedback-based learning. Unlike supervised learning, you don't provide labeled input-output pairs.

Supervised fine-tuning → Trains a model to improve performance on specific tasks by providing labeled data. The model learns from explicit examples of correct input-output associations.

Continued pre-training → Provides unlabeled data to pre-train a foundation model by familiarizing it with certain types of inputs. This improves the model's domain knowledge without requiring labeled examples.

Heads-up: There are some costs related to customization, refer to Amazon Bedrock endpoints and quotas.

Knowledge Bases

As its own website says, "you can give foundation models and agents contextual information from your company’s private data sources to deliver more relevant, accurate, and customized responses." In this use case, it allows us to connect to private data sources, enabling users to interact and ask questions without needing to fine-tune or retrain the model. The model has access to this data and can provide the answers users need.

So, it works by uploading your custom data sources to create a repository of information that is used to enhance your prompts. It uses something called Retrieval Augmented Generation (RAG) to achieve this.

RAG is a technique that retrieves data from company sources to augment the prompt, providing more relevant and accurate responses. Amazon Bedrock Knowledge Bases use a vector database to store data as embeddings (numerical representations of text). The knowledge base connects Bedrock with private company data by retrieving the most relevant information at query time. It searches the data using semantic similarity, retrieves the most useful chunks, and uses them as additional context so the model can generate natural language answers. Instead of matching exact keywords, the system understands the meaning and context of a user’s query to return relevant information.

Hands On Lab: Creating a Knowledge Base

In this course, there was a hands-on lab where I needed to create the Amazon Bedrock knowledge base and configure it for use by the app.

To create a knowledge base is pretty straight forward. On the console, head over to Amazon Bedrock and click on Create . Choose Knowledge Base with vector store and you will see this screen:

Knowledge bases sync with documents, in this case, the app uses Amazon S3. You can choose different data source options and you can have up to five different data source in a knowledge base.

Configure the S3 bucket as your data source and upload the necessary data. Make sure to add the correct data source name and select the appropriate S3 bucket.

Select the vector store, review and create.

By selecting the following option, Bedrock will create an Amazon OpenSearch Serverless cluster for us to store these embeddings.

Review details and Create Knowledge Base🎉

Once it's created, remember to sync the data sources to index the content for searching.

You can test the model by clicking the Test Knowledge Base button on the console. Choose the model, enter a prompt, and watch the magic happen.

You can use a Knowledge Base In Two Ways

Use the Retrieve API to query and get information from the Knowledge Base directly without an additional response.
Use the RetrieveAndGenerate API, which takes a prompt as input and generates a response based on the retrieved information.

AI Safety Controls with Amazon Bedrock Guardrails

Guardrails offer protection and control over LLM responses, going beyond what can be managed through prompt design alone. Bedrock provides configurable guardrails to ensure responsible AI behavior:

Some of the content filters:

Block harmful categories such as hate, insults, or violence.

Grounding and Relevance:

Grounding: Confidence threshold for factual accuracy.

Relevance: Checks if the model response is relevant to the user query

Integrating AI Models Through the Bedrock API

Here's an example from the AWS documentation on how to integrate a Python app with the Amazon Bedrock API using the Amazon Titan Text model.

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
"""
Shows how to create a list of action items from a meeting transcript
with the Amazon Titan Text model (on demand).
"""
import json
import logging
import boto3

from botocore.exceptions import ClientError


class ImageError(Exception):
    "Custom exception for errors returned by Amazon Titan Text models"

    def __init__(self, message):
        self.message = message


logger = logging.getLogger(__name__)
logging.basicConfig(level=logging.INFO)


def generate_text(model_id, body):
    """
    Generate text using Amazon Titan Text models on demand.
    Args:
        model_id (str): The model ID to use.
        body (str) : The request body to use.
    Returns:
        response (json): The response from the model.
    """

    logger.info(
        "Generating text with Amazon Titan Text model %s", model_id)

    bedrock = boto3.client(service_name='bedrock-runtime')

    accept = "application/json"
    content_type = "application/json"

    response = bedrock.invoke_model(
        body=body, modelId=model_id, accept=accept, contentType=content_type
    )
    response_body = json.loads(response.get("body").read())

    finish_reason = response_body.get("error")

    if finish_reason is not None:
        raise ImageError(f"Text generation error. Error is {finish_reason}")

    logger.info(
        "Successfully generated text with Amazon Titan Text model %s", model_id)

    return response_body


def main():
    """
    Entrypoint for Amazon Titan Text model example.
    """
    try:
        logging.basicConfig(level=logging.INFO,
                            format="%(levelname)s: %(message)s")

        # You can replace the model_id with any other Titan Text Models
        # Titan Text Model family model_id is as mentioned below:
        # amazon.titan-text-premier-v1:0, amazon.titan-text-express-v1, amazon.titan-text-lite-v1
        model_id = 'amazon.titan-text-premier-v1:0'

        prompt = """Meeting transcript: Miguel: Hi Brant, I want to discuss the workstream  
            for our new product launch Brant: Sure Miguel, is there anything in particular you want
            to discuss? Miguel: Yes, I want to talk about how users enter into the product.
            Brant: Ok, in that case let me add in Namita. Namita: Hey everyone 
            Brant: Hi Namita, Miguel wants to discuss how users enter into the product. """

        body = json.dumps({
            "inputText": prompt,
            "textGenerationConfig": {
                "maxTokenCount": 3072,
                "stopSequences": [],
                "temperature": 0.7,
                "topP": 0.9
            }
        })

        response_body = generate_text(model_id, body)
        print(f"Input token count: {response_body['inputTextTokenCount']}")

        for result in response_body['results']:
            print(f"Token count: {result['tokenCount']}")
            print(f"Output text: {result['outputText']}")
            print(f"Completion reason: {result['completionReason']}")

    except ClientError as err:
        message = err.response["Error"]["Message"]
        logger.error("A client error occurred: %s", message)
        print("A client error occured: " +
              format(message))
    except ImageError as err:
        logger.error(err.message)
        print(err.message)

    else:
        print(
            f"Finished generating text with the Amazon Titan Text Premier model {model_id}.")


if __name__ == "__main__":
    main()

Engineering Better Conversations: Prompt Engineering

Prompts in Large Language Models (LLMs) are the input texts, instructions, or questions users provide to guide the AI to generate specific, relevant, and accurate responses.

With Amazon Bedrock, the LLMs are already built and trained for us. The simplest way to get better results from these LLMs is to improve the prompts we provide to them.

To write good prompts, a good strategy and easy to remember is the CO-STAR technique (Context → Objective → Style → Tone → Audience → Response). Here’s an example of a strong Prompt:

Context: We're launching Wandr, a travel review app that focuses on authentic, local experiences rather than tourist traps. Unlike TripAdvisor, we verify that reviewers actually visited the location through GPS check-ins and require photo proof. Our community consists of adventure travelers and culture enthusiasts who want to discover hidden gems.

Objective: Write an engaging "About Us" section for our app store listing that will convince potential users to download the app. Target length: 200-250 words. Must include our key value propositions: verified reviews, local discovery focus, and spam-free community.

Style: Storytelling approach that paints a picture of the problem we solve. Use vivid, sensory language that evokes the feeling of travel. Structure: problem → solution → benefit. Include a specific example or scenario travelers can relate to.

Tone: Adventurous and inspiring, but trustworthy and grounded. Think "experienced travel buddy giving insider tips" rather than "corporate travel company." Avoid clichés like "wanderlust". Be warm and enthusiastic without being cheesy.

Audience: Millennials and Gen Z travelers who are tired of showing up to "hidden" restaurants only to find them packed with tourists from the same Google search. They value authenticity over luxury, experiences over amenities, and trust peer recommendations more than professional critics.

Response: Provide the app store description, followed by 3-5 bullet points summarizing our key features that could appear below the main description in the app store listing.

We can include instructions on the desired length or formatting of the results we want. Additionally, we can provide sample results in the prompt.

Next Steps

This wraps up the first part of my three-part series on AI and AWS Coursera Specialization. I have to admit, I'm really excited about the upcoming course “DevOps and AI on AWS: CI/CD for Generative AI Applications”. I can't wait to share what I learn with you🙌. Stay tuned!

Got my AWS Cloud Practitioner Certification - CLF-C02 ☁️

Laura — Tue, 07 Apr 2026 22:30:10 +0000

Introduction
Motivation and Background
Exam Preparation Steps

* Stephane Maarek's Ultimate AWS Certified Cloud Practitioner Course

* AWS Cloud Practitioner Essentials Course

* AWS Skill Builder Individual Plan

* Official Practice Exam + Neal Davis's Practice Exams

Study Strategy and Tools

* Note-taking and Organization

* Interactive Learning

Exam Experience

* Choosing a Testing Center

Highlights of AWS Cloud Practitioner Certification

* Innovative Solutions and Tools

* Security Domain

Conclusion

Introduction

I am thrilled to share my journey of achieving the AWS Certified Cloud Practitioner certification ☁️🙌. This was a significant milestone for me, especially since I started without any prior experience or exposure to AWS Cloud. The preparation and learning process was both challenging and incredibly rewarding.

Motivation and Background

The decision to pursue the AWS Certified Cloud Practitioner certification was driven by my desire to enhance my technical skills and understanding of cloud computing. Despite my initial lack of experience, I found the learning journey to be engaging and enlightening, particularly in the area of cloud security 🥷👩🏽‍💻👀, where for sure I am going to dive deeper.

Exam Preparation Steps

Stephane Maarek's Ultimate AWS Certified Cloud Practitioner Course

I began my preparation with the ✅ [NEW] Ultimate AWS Certified Cloud Practitioner CLF-C02 course by Stephane Maarek, he is a solutions architect, consultant and software developer. This comprehensive course provided a solid foundation and covered all the necessary topics in depth and I found it super useful and comprehensive.

AWS Cloud Practitioner Essentials Course and other resources

Next, I enrolled in the ✅ AWS Cloud Practitioner Essentials official course, available for free on the AWS Skill Builder platform. This course offered a structured and thorough overview of AWS Cloud concepts, helped me filling the gaps from the previous course I've done and also reinforce concepts, this was very useful too!

AWS Skill Builder Individual Plan

To further enhance my preparation, I signed up for the AWS Skill Builder Individual Plan. This plan includes several valuable resources, I found this ones particularly useful for my exam prep:

✅ AWS Escape Room: Exam Prep for AWS Certified Cloud Practitioner (CLF-C02): A 3D virtual escape room game that tested my knowledge interactively.
✅ Exam Prep Standard Course: AWS Certified Cloud Practitioner: Another comprehensive course that reinforced my understanding.

Additionally, there was an Exam Prep Enhanced Course: AWS Certified Cloud Practitioner available, but I chose not to take it since Maarek's course was already very comprehensive but I do recommend you go and check it out!

Official Practice Exam + Neal Davis's Practice Exams

Finally, I did the ✅ AWS Certified Cloud Practitioner Official Practice Exam and I purchased the ✅ AWS Certified Cloud Practitioner Practice Exams CLF-C02 set from Neal Davis. I took six practice tests a couple of times, meticulously reviewing and taking notes on any questions I got wrong. This practice was crucial in solidifying my knowledge and boosting my confidence.

Study Strategy and Tools

Note-taking and Organization

Throughout my preparation, I took detailed notes from each course. I organized these notes in a document on Notion, adding additional information as I progressed through the resources. This systematic approach helped me consolidate my learning effectively.

Interactive Learning

Engaging with interactive learning tools, like the AWS Escape Room game, made the study process more enjoyable and helped reinforce my understanding in a practical, hands-on way.

Exam Experience

Choosing a Testing Center

Although the AWS exam can be taken from the comfort of your home, I chose to take it at a Test and Training Center in Dubai. This was a personal preference, as I felt more comfortable in a formal testing environment. You can find a Test Center in your city when you book the exam.

Highlights of AWS Cloud Practitioner Certification

Innovative Solutions and Tools

One of the most fascinating aspects of AWS is how it provides solutions for virtually every problem, continuously coming up with innovative tools and services. This aspect of AWS kept me engaged and motivated throughout my study journey.

Security Domain

I found the security domain particularly interesting. AWS’s robust security measures and protocols are designed to protect data and applications, which is crucial in today’s digital landscape.

Conclusion

In conclusion, preparing for and achieving the AWS Certified Cloud Practitioner certification was a transformative experience. It took me a couple of months to prepare, balancing my study time with a significant holiday break. The journey was well worth it, and I am now excited to pursue my next certification. Thank you for reading about my experience, and I hope it inspires you on your learning path!

Frontend To DevOPs: 5 Months In

Laura — Tue, 07 Apr 2026 22:28:14 +0000

Introduction
Summing Up the Journey
Expectations vs. Reality
The Tech Stack: What I Had to Learn
Surprise! Some Frontend Skills Actually Helped
Advice for Frontend Developers Considering the Switch
What's Next for Me

Introduction

Some time ago I decided to switch from Frontend Development to DevOps engineering. I started sharing my experience through a series of blog posts so anyone else on the same journey doesn't feel alone, and anyone thinking about making the same move has the courage to do it.

Summing Up the Journey

A couple of years ago I was working for a startup. We were a small technical team and I started as a Frontend Developer, that was my main strength. But if you've worked for a startup, you know there's a point where you end up doing whatever it takes to ship fast, so I ended up learning a bit of backend, even Google Analytics (which I hated 😂), and working on the infrastructure with AWS. Luckily, I felt very interested in infrastructure and somehow felt this world was fascinating. I started attending some AWS Girls UG group meetups where I got the opportunity to meet cool people and attend talks about different topics, and started to have mentorship sessions with @Mariano González , a Senior DevOps engineer.

As I was getting more interested in the infrastructure side of things, I got AWS Cloud Practitioner Certified, and that gave me a broad understanding of AWS in general.

I did a couple of side projects related to DevOps (including a Terraform one), studied in a DevOps Bootcamp that Roxs launched, and I wrote a series of blog posts talking about that. And finally, I worked very hard on solving The Cloud Resume Challenge. My mentor, @Mariano González , found it and recommended I do it, so I did and I learned A LOT.

Finally, I applied for a Software Developer position at Streaver, an AI-driven solutions company based in Uruguay. They saw I'd done a couple of projects on infrastructure and invited me to do a DevOps challenge, which I did, and here I am, working as a DevOps engineer for 5 months already🎉. So I'm gonna share my experience.

Expectations vs. Reality

When I was preparing to transition into DevOps, I'll be honest, I didn’t have much experience in infrastructure, so it was hard to picture what a day as a DevOps engineer would actually look like. I watched a couple of "A day as a DevOps engineer" YouTube videos and asked my mentor @Mariano González , a Senior DevOps Engineer, questions about what the day-to-day looked like. While I got some kind of idea from all this research, it still wasn't much to go on. One thing I knew for sure though: I wouldn't get bored.

I had this mental image of what the role would be like. I thought I'd be spending most of my time writing infrastructure as code, automating deployments, and maybe dealing with the occasional production issue. It seemed like a natural progression from frontend development, just working on a different layer of the stack, right?

Well, not exactly.

What I Expected: I imagined DevOps would be mostly about building CI/CD pipelines and writing Terraform configurations. I thought once you set things up correctly, everything would just run smoothly. I also assumed that since I had some AWS experience from my startup days, I'd have a decent head start.

What Actually Happened: The scope turned out to be much broader than I anticipated. Yes, there's infrastructure as code and CI/CD pipelines, but there's also monitoring, security, cost optimization, incident response, documentation, and a lot of collaborative work with different teams.

The biggest surprise? How much time I spend on problem-solving and troubleshooting. Things break, often in unexpected ways, and you need to diagnose issues quickly, sometimes under pressure. Unlike frontend development where you can usually reproduce bugs locally, infrastructure issues can be elusive and involve multiple services interacting in complex ways.

Another reality check: the learning never stops. New tools, new best practices, new security vulnerabilities, the landscape evolves constantly.

But here's what actually surprised me: the impact of the work. As a DevOps you're helping the entire engineering team ship faster and with more confidence. That feeling is incredibly rewarding.

And was I right about not getting bored? Absolutely. Every day brings something different, and there's always a new challenge to tackle.

This new job involves a lot of thinking outside the box and finding creative solutions to complex problems. The impostor syndrome is real, especially when you're troubleshooting issues you've never encountered before, but pushing through those moments is part of the growth.

The Tech Stack: What I Had to Learn

Coming from a frontend background where I spent my days with JavaScript, React, and CSS, the DevOps tech stack felt like stepping into a completely different universe.

AWS CDK (Cloud Development Kit) was completely new territory for me. It’s a way to write infrastructure as code using actual programming languages. I had never worked with it before this job, and I must say, it's an amazing tool. Being able to define infrastructure using familiar programming concepts like classes, loops, and conditionals felt way more intuitive than I expected. It bridged the gap between my developer mindset and infrastructure work in a way that made the transition smoother.

Python My experience was mostly in JavaScript, so picking up Python was quite new to me. At first, the syntax differences threw me off, no curly braces, indentation actually matters. But honestly? Python and I became friends fast. It's clean, readable, and the ecosystem for DevOps tooling is incredible.

AWS (The Deep Dive) I had some AWS experience from my startup days, but this job took it to a whole different level. Cloud Practitioner certification gave me breadth, but actually working as a DevOps engineer is giving me real hands-on experience. I'm talking about IAM policies, ECS, RDS, CloudWatch, Security Groups, everything. Understanding how all these services interact has been a continuous learning process.

The learning curve is steep, but here's the thing: having a programming background actually helped more than I expected.

Surprise! Some Frontend Skills Actually Helped

When I made the switch to DevOps, I kind of assumed most of my frontend skills would become irrelevant. Turns out, I was wrong.

Troubleshooting and Problem-Solving: As a frontend developer, I spent countless hours debugging why a component wasn't rendering correctly, why an API call was failing, or why the layout broke on a specific browser. That investigative mindset, breaking down a problem, checking logs, isolating variables, testing, translates directly to infrastructure work.

When a deployment fails or a service goes down, the approach is similar: read the error messages carefully, check the logs, trace back through recent changes, and systematically eliminate possibilities until you find the root cause. The context is different, but the problem-solving process? Pretty much the same.

Working with Code Infrastructure as code is still code. Learning Python or writing CDK constructs felt less intimidating because I already understood functions, loops, conditionals, etc.

So while the tech stack was completely different, the core skills I'd developed as a developer, problem-solving, debugging, and thinking in code, turned out to be more transferable than I expected.

Advice for Frontend Developers Considering the Switch

If you're a frontend developer thinking about making the jump to DevOps, here's my advice:

Keep an Open Mind DevOps is going to challenge a lot of your assumptions about how software works. You'll encounter tools, concepts, and workflows that feel completely foreign at first. Stay curious and open to new ways of thinking. The solutions that work in infrastructure aren't always the same ones you'd use in frontend development, and that's okay.

Think Outside the Box Infrastructure problems rarely have a single "right" answer. You'll need to get comfortable with ambiguity and find creative solutions to complex challenges. Sometimes the best fix isn't the obvious one, and that's where the problem-solving gets interesting.

Embrace the "Always Learning" Mindset This field evolves constantly, there's always something to learn. Try to learn something new every day, even if it's small. The learning never stops, and that's actually part of what makes it exciting.

Don't Let Impostor Syndrome Take Over This is big. You're going to feel like you don't know what you're doing sometimes. You'll see senior engineers troubleshoot issues in minutes that would take you hours. You'll read documentation and feel lost. That's completely normal. Everyone starts somewhere, and feeling uncomfortable means you're growing. The impostor syndrome is real, but don't let it convince you that you don't belong.

Some Days Won't Be Good And That's Okay You'll have days where nothing clicks, where you spend hours on a problem and make zero progress, where you feel like you're moving backwards instead of forwards. That's part of the process of learning something new. Those frustrating days are teaching you something, even if it doesn't feel like it in the moment.

Get Comfortable Being Uncomfortable Here's the truth: you're going to be out of your comfort zone. A lot. And that's exactly where you need to be. Growth happens in discomfort. The goal isn't to eliminate that feeling but to get comfortable with it, to recognize that being challenged and uncertain means you're learning and evolving.

What's Next for Me

The journey doesn't stop here. If anything, these first 5 months have shown me just how much there is to learn and explore in this field.

As I get more comfortable with the context and knowledge, I'll continue doing what I've been doing: learning every day, staying curious, and pushing myself outside my comfort zone. There are so many areas I want to dive deeper into, container security, AWS architectures, and more.

I'll keep sharing my experiences through these blog posts because if my journey can help even one person feel less alone in their transition or give someone the push they need to make the switch, then it's worth it.

The adventure continues, and I'm excited to see where it takes me next.

Empowering Women in Cybersecurity: My Experience with ITU's Global Initiative and IT for Girls👩🏽‍💻🙌

Laura — Tue, 07 Apr 2026 22:25:51 +0000

Leveling Up as a Frontend Developer: My Cybersecurity Learning Journey
The ITU Her CyberTracks Fellowship: Empowering Women in Cybersecurity Through Global Initiative
My Experience So Far
Study Notes: Technical Knowledge Gained
The Power of Mentorship: Guidance from Industry Leaders
Looking Forward: Next Steps in My Cybersecurity Journey
Acknowledgments and Gratitude

1. Leveling Up as a Frontend Developer: My Cybersecurity Learning Journey

I am always looking for ways to grow and learn. I usually set aside a few hours each week to research opportunities, quality courses, and resources to keep improving myself. This also keeps my mind active and healthy, especially since I am currently job hunting‼️ (which is a job in itself 😬).

I've been a Frontend Developer for the past four years, and since last year, I've been learning about Cloud technologies, specifically AWS. I earned my AWS Cloud Practitioner certification and I really enjoyed it. It's fascinating to explore other parts of the development process, not just the frontend and the backend.

In my last project, "The Cloud Resume Challenge," I focused on the infrastructure side and explored ways to make my app more secure. I understand that security is very important, and we should always aim to build secure applications and systems. This project allowed me to do some research, which broadened my perspective on security. This is where security truly captured my interest. I discovered that I could go above and beyond by adding enhancements to the security aspect of the project. Here are some interesting and useful security improvements I could do:

I could enhanced my project's security by configuring DNSSEC to prevent "man-in-the-middle" attacks, applying the "least privilege" principle and make use of a service called IAM Access Analyzer, use AWS WAF to protect my public API, diagramming code flow to detect attackers, and setting up code scanning and vulnerability checks on my repositories.

I wrote a blog about it if you want to check it out 👀.

Thanks to Mujeres IT, a fantastic support group for women in technology in Uruguay, I discovered an opportunity. The German Embassy was inviting us to apply for a Cybersecurity Program aimed at bridging the gap in the cybersecurity field. I thought, why not? It seemed like a natural next step, so I decided to apply for the program.

2. The ITU Her CyberTracks Fellowship: Empowering Women in Cybersecurity Through Global Initiative

Okay, but first things first, what is ITU?

The International Telecommunication Union, or ITU, is a specialized agency of the United Nations that focuses on information and communication technologies. Established on 1865, as the International Telegraph Union, it is the oldest UN agency and was the first formal international organization. Initially, the ITU aimed to connect telegraph networks between countries. Today, it promotes the global use of the radio spectrum, facilitates international cooperation in assigning satellite orbits, helps develop and coordinate worldwide technical standards, and works to improve telecommunication infrastructure in developing countries. Based in Geneva, Switzerland, the ITU has a global membership that includes 194 countries and about 900 businesses, academic institutions, and international and regional organizations.

ITU Academy offers a large selection of online, face-to-face and blended courses. ITU Academy Training Centres are internationally recognized institutions offering high-quality training to professionals, with a focus on the needs of developing countries.

About this specific program:

Her CyberTracks is funded by the German Federal Foreign Office and co-implemented by Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH and International Telecommunication Union (ITU), in partnership with UNODC (UN Office on Drugs and Crime) and LAC4 (Latin America and Caribbean Cyber Competence Centre). The goal of Her CyberTracks is to support the equal and meaningful participation of women in cybersecurity. To achieve this, the training course provides women with the skills and mindset needed to succeed in cybersecurity through focused capacity building.

It is a 6-month training program offering a comprehensive curriculum focused on three main areas: TRAIN, which provides expert training to develop skills for a secure cyberspace; MENTOR, which creates a platform for senior professionals to guide and support women in their cybersecurity careers; and INSPIRE, which uses role models and events to encourage and empower women to lead in cybersecurity. The program includes online courses, regional training, and mentorship.

The curriculum includes the Her CyberTracks Latin America, Europe and Africa trainings, which consist of on-site activities featuring soft skills masterclasses, simulations, hands-on exercises, mentorship circles, study visits to cybersecurity organizations, and engaging networking opportunities.

Participants could choose from three available CyberTracks: Policy & Diplomacy CyberTrack, Incident Response CyberTrack, and Criminal Justice CyberTrack.

In my case, I applied for the Incident Response CyberTrack. This track is designed for women already in technical roles who want to enter the cybersecurity field and gain practical experience. Incident response is a structured process that organizations use to identify and handle cybersecurity incidents, like data breaches or cyberattacks. Sounds exciting, right? Cybersecurity incidents are inevitable, and having a strong incident response program is essential for managing them effectively.

About the selection process…

The program received over 1,000 applications from around the world, but only 159 were accepted. Out of those 159, 55 were chosen for the Incident Response CyberTrack, which was the most popular choice among applicants. I'm thrilled to be one of the participants selected for the program. It will take me to the Latin America and Caribbean Cyber Competence Centre (LAC4) in the Dominican Republic for hands-on training.

It's important to have such initiatives to provide women with the opportunity to build a career in the cybersecurity field, where only 20% of the workforce is female. Crazy, right?

3. My Experience So Far

My first impressions of the program are very positive. The course is well-organized into seven modules, plus a one-week hands-on experience at LAC4. This training happens at the facility in Santo Domingo, Dominican Republic. The platform provides clear information about the modules, topics, and deadlines for completing activities.

One thing I really like is the forums where you can interact with fellow students. It's amazing to hear from other women studying with me from the other side of the world. I love that multicultural aspect.

4. Study Notes: Technical Knowledge Gained

By now, I have completed the first 2 modules:

Module 1 - Cybersecurity Fundamentals, you can find my study notes here.

And Module 2 - Digital First Responder, you can also find my study notes here.

For someone new to cybersecurity, I found these two courses to be an excellent starting point.

Interestingly, Module Two reminded me of my first job, especially the "Treatment of IT Disruptions" section. Here's a little story: When I was 17, I got my first job at an English institute. I was an Administrative Assistant, but I also worked in the library and multimedia room. I remember whenever something wasn't working with the computers or video equipment (yes, back when VHS was how we watched movies 😂), I was always curious and tried to fix those problems myself. It was fun, and I always learned something new.

5. The Power of Mentorship: Guidance from Industry Leaders

As I mentioned earlier, the training includes mentorship. Based on my profile, I was assigned a mentor named Elvira. She is from Kenya and works as a Cybersecurity Analyst at NTT DATA Middle East and Africa. We've exchanged introductory emails and even had our first one-on-one meeting last week 😃.

For our first mentorship meeting, I prepared a "First Mentorship Agenda", which we used as a guide. I think this kept the conversation smooth and organized.

During the first mentorship session, I learned a lot from Elvira. She was very encouraging and eagerly shared her views and insights on various topics. I felt comfortable speaking with her. We agreed on the time, platform, and duration of the meeting.

TIP: I strongly suggest being prepared for meetings to make the most of the mentorship. It's also a way to show respect for the mentor, who is generously giving their valuable free time.

6. Looking Forward: Next Steps in My Cybersecurity Journey

One of the tasks is to define SMART Goals. One of my SMART Goals is to research career paths and roles within the cybersecurity field so I have a clear vision of where I want to go. During my conversation with Elvira, she advised me to explore defensive security and the various roles involved, and I think that was great advice!

Defensive cybersecurity aims to prevent cyber attacks by safeguarding everything from an organization’s systems and software to its full network infrastructure.

Apart from the Fellowship program:

I am studying in the Cisco Network Academy, following the Junior Cybersecurity Analyst career path to complement the training. This is a great platform to learn from high-quality content for free.

I am also participating in the initiative “IT For Girls - Ciberseguridad y OT” by WoMakersCode. This program offers mentorship and training in cybersecurity and OT technologies for Spanish-speaking women, providing 1,000 Udemy scholarships and over 900 Claroty certifications through partnerships with NTT DATA Europe & Latam, NTT DATA FOUNDATION, Claroty, and Udemy.

If you're a woman curious about cybersecurity and wondering if you belong there, you absolutely do.

7. Acknowledgments and Gratitude

I have already posted a thank-you message on my LinkedIn to the ITU organizers and the IT for Girls organizers and speakers. However, I want to express my gratitude again to everyone who makes these initiatives possible. These programs have a significant impact on the women who participate.

Mentors are incredibly important in technology. They can be positive role models for those starting in the field, where everything is new and uncertain. Special thanks to my mentor Elvira for volunteering her time and sharing her experience. I look forward to our upcoming one-on-one sessions.

Thank you to the other women in the cybersecurity field for being so welcoming, inspiring, and encouraging. This supportive network is one of the things I enjoy most about being in tech.

If you are on a similar path as me or enjoy what I share, feel free to reach out to my email at lauradiaz1586@gmail.com ✨

My AWS Cloud Resume Challenge ✨👩🏽‍💻

Laura — Tue, 07 Apr 2026 22:20:43 +0000

Introduction 🩵
My Architecture diagram 👩‍🎨
Step 1: Certification ☁️
Step 2: Convert my resume into HTML 👷🏽‍♀️
Step 3: Add minimal styles with CSS 🪄
Step 4: Deploy my static website to S3 🪣
Step 5: Add Security with HTTPS 🔐
Step 6: DNS 👈
Step 7: Javascript 🦹
Step 8: Database 💾
Step 9: API ✨
Step 10: Python 🐍
Step 11: Tests
Step 12: Infrastructure as Code (IaC) 👩🏽‍💻
Step 13: Source Control
Step 14: CI/CD (Back end)🏄
Step 15: CI/CD (Front end) 🏄‍♀️
🚨🚨Beyond the Requirements: My Extended Contribution 🚨🚨
Step 16: Blog post ✏️
A Heartfelt Thank You to My Mentor 🙏

Introduction 🩵

Some time ago, my mentor @Mariano González shared with me this amazing challenge, it’s called “The Cloud Resume Challenge” by Forrest Brazeal. This challenge isn’t a tutorial or a how-to guide, it tells you what the outcome of the project should be. It's a hands-on project designed to help you move from cloud certification to a cloud job. Includes many skills that real cloud and DevOps engineers use every day✨.

In my case I chose to do it with AWS. The challenge consisted on 16 steps and are free for anyone to try.

In this blog, I will share about my experience with this challenge.

The Architecture 👩‍🎨

This is the application's architecture diagram I created. I know it looks a bit small and is hard to read, but hopefully, the icons help. The purpose of sharing the entire architecture diagram is to provide an overview of the services I used to solve the challenge and the enhancements I added myself. I will also share detailed diagrams for each step so you can get more information about them.

Step 1: Certification ☁️

The first step was to have the AWS Cloud Practitioner certification on my resume. I already had this certification, and I wrote a blog about it.

Looking ahead, after completing this challenge, my next immediate step is to obtain the Developer Associate Certification.

Step 2: Convert My Resume into HTML 👷🏽‍♀️

The next step was to convert my resume into HTML (HyperText Markup Language) format. I had been a Frontend Developer for the past 4 years, so luckily I knew what HTML is but if you don’t have any coding experience, don’t get intimidated by this. It was pretty easy and straightforward to learn. Here’s a good resource to learn from Mozilla HTML Docs.

Since my main experience is as a Frontend Developer and I already had experience with React, I could choose to use React or work on the infrastructure of my own portfolio. However, for this challenge, as you will see in the following steps, the goal was to understand DNS and HTTP on my own and use S3 instead of using a pre-built static website service like AWS Amplify.

Step 3: Add Minimal Styles with CSS 🪄

After converting it to HTML, I needed to apply some basic styles using CSS. This made the resume look more polished and visually appealing. I chose to use very simple and minimal styles since the focus of this project is to continue learning Cloud skills.

Step 4: Deploy my static website to S3 🪣

The next step involved using a popular AWS service called Amazon S3, this is an object storage service that stores data for millions of customers worldwide. I used this service to deploy my project.

Step 5: Add Security with HTTPS 🔐

Ready up for step 5, this step involved a new service called Amazon CloudFront. Amazon CloudFront is a content delivery network (CDN) service that quickly and reliably distributes your static and dynamic content with low latency. Amazon S3 + CloudFront enables storing, securing, and delivering your static content at scale.

After completing the configurations, I was able to access the distribution. The distribution's URL looked something like this:

I had experience creating an S3 bucket before, but this was the first time I created a CloudFront distribution, and I really enjoyed it.

Step 6: DNS 👈

This next step was an exciting one!🫰

In this one, I had to point a custom DNS domain name to the CloudFront distribution I just created, so the resume could be accessed at something like lauradiazcloudengineer.com. For this step I could use any other DNS provider or Amazon Route 53 as my DNS provider.

After I bought my domain name and the status became successful, I checked the documentation to learn how to route traffic to an Amazon CloudFront using the domain name I just purchased, lauradiazcloudengineer.com instead of the domain name that CloudFront assigned by default. As you may noticed in the previous step, when you create a distribution, CloudFront assigns a domain name to the distribution, this would look something like foobar.cloudfront.net.

The first thing I needed to do was request a public certificate so that Amazon CloudFront could use HTTPS. For this, I used an AWS service called AWS Certificate Manager (ACM) to obtain a public certificate.

And finally, I needed to configure Amazon Route 53 to route traffic to a CloudFront.

Step 7: Javascript 🦹

I really enjoyed working on this step because I have been working with JavaScript for 4 years now. When I saw JavaScript included in the challenge, I was quite happy 😊. It included a visitor counter that displays how many people have accessed the site.

Step 8: Database 💾

Because the visitor counter needed to retrieve and update its count in a database somewhere, I worked with an AWS service called DynamoDB. It is a powerful, serverless, fast, and flexible NoSQL database that is fully managed.

Step 9: API ✨

I used AWS’s API Gateway and Lambda as my serverless backend. I followed the following architecture pattern:

✅ I created a serverless API to update the visitor counter from a DynamoDB table.

✅ I created a Lambda function as my backend.

✅ I created an HTTP API using the API Gateway.

From a DevOps perspective, it was important to get notified when my running services did something unexpected. For this, I set up CloudWatch (more details in the upcoming sections).

Step 10: Python 🐍

For step number 10, I used a service called Lambda, which is a service that ran my code in response to events and automatically manages the computing resources. I don't have much experience with Python but I decided to give it a try.

Step 11: Tests

Testing was the only step that was not added to the current iteration of this challenge. Although I understood this was a crucial step and very important one, this choice was made on purpose to allow more time to learn proper testing methods and apply them effectively in future updates.

Step 12: Infrastructure as Code (IaC) 👩🏽‍💻

I needed to write the infrastructure as code so I wouldn't have to create the services manually. The challenge suggested I could use AWS Serverless Application Model (SAM) template and deploy using AWS SAM CLI. However, since I had experience working with Terraform and wanted to tackle this EXTRA challenge, it was my preferred choice.

A SIDE NOTE 👀:

In case you are curious about my experience with Terraform, here’s my previous post: IaC: Deploying a Node Secrets Viewer with Terraform. This project demonstrates the deployment of my NodeJS application that retrieves and displays secrets from AWS Secrets Manager. The infrastructure is provisioned using Terraform, showcasing Infrastructure as Code (IaC) capabilities with AWS services.

This step involves another challenge: Terraform Your Cloud Resume Challenge.

Step 13: Source Control

I created two different repositories, one for the backend and other for the frontend. The purpose of this step was to update the site automatically whenever you made a change to the code.

You can view the repositories here:

Step 14: CI/CD (Back end) 🏄

In the backend repository, there is a Terraform directory that contains all my Infrastructure as Code. Each file contains the code for the specific AWS service, so it’s more organized and clear to understand.

The Python Lambda code is part of the workflow but was not committed, as requested by the challenge's creator.

Step 15: CI/CD (Front end) 🏄‍♀️

The frontend repository has a directory named resume that contains the HTML and CSS. The JavaScript code is part of the workflow but is not committed, as requested by the challenge's creator.

I set up a main.tf file with my Terraform IaC, so when the GitHub Actions CI/CD pipeline ran, the new website code is pushed to the S3 bucket and updated automatically.

🚨🚨 Beyond the Requirements: My Extended Contribution 🚨 🚨

Okay, but this was not the end!

I wanted to share other AWS services I used to make my infrastructure more robust to cover important DevOps topics like monitoring, logging and notifications.

Additional S3 relevant configurations:

✅ I enabled bucket versioning. About versioning here.
✅ Configured a lifecycle policy for an S3 bucket: Automatically cleaned up old versions of objects in your S3 bucket that were tagged with "TheCloudResumeChallenge" after 90 days.

Cost Allocation and Management and Resource Organization

✅ Added tags “TheCloudResumeChallenge” to my resources to easily track cost by project and filter resources if needed.

Cloudfront:

✅ Added Cloudfront Response Security Headers Policy.
✅ Added Cloudfront cache policy: This policy was designed to optimize cache efficiency by minimizing the values that CloudFront included in the cache key.

API Gateway:

✅ Added custom domain name to the api gateway url and the respective mappings.

Simple Notification Service (SNS):

✅ Created a topic and subscribed my email to get notifications when there’s an alarm.

CloudWatch:

✅ Added configuration settings for CloudWatch logs.
✅ Created API Gateway log groups.
✅ Created CloudWatch alarms for Lambda errors.
✅ Created CloudWatch alarms for API Gateway: errors and high request count.

Step 16: Blog post ✏️

Finally, writing a blog post was the last step of this amazing challenge 🤩.

I am so happy and proud of myself for finishing it. It was challenging and difficult at times, but definitely rewarding.

I had been blogging about different topics and you could subscribe to my newsletter on hashnode to get notified whenever I post a new blog post.

My experience taught me that the magic happens when people openly exchange ideas and expertise. This belief in democratizing knowledge drives me to contribute to the tech community while continuously learning from others 💖.

A Heartfelt Thank You to My Mentor 🙏

To Mariano,

Your guidance as a mentor has been invaluable to my journey as a cloud engineer, and I am very grateful for that ✨. Thank you for always being there to answer my questions and for guiding me to discover solutions on my own, which has helped me develop problem-solving skills that will benefit my career.

I am especially grateful for the time you've spent reviewing my work and providing detailed feedback, as your insights have pushed me to improve and revealed aspects I might have missed.

✨ IaC: Deploying a Node Secrets Viewer with Terraform ✨👩🏽‍💻

Laura — Tue, 07 Apr 2026 22:14:12 +0000

Introduction

Learn how I built a secure cloud application by integrating Node.js with AWS Secrets Manager and automating the infrastructure deployment using Terraform. This project demonstrates modern cloud development practices and security implementation.

Project Overview
The Challenge
Solution Architecture
The Node Application
Infrastructure as Code with Terraform
- Basic Setup
- Setup The Provider
- EC2 Instance Setup
- IAM Roles and Policies
- Security Groups Configuration
- AWS Secrets Manager Setup
- User Data Script Implementation
Deployment Process
- Prerequisites
- Step-by-Step Deployment Guide
- Deployment Verification
Cost Considerations
Cleanup Process
Future Improvements
Conclusion

Project Overview

This project showcases a practical implementation of cloud security and infrastructure automation with Terraform. At its core, it combines a Node application that interacts with AWS Secrets Manager🔐 and a complete infrastructure setup automated through Terraform.

The project consist of two layers:

The application layer: A Node application that interacts directly with AWS Secrets Manager using the AWS SDK.

Infrastructure layer: The infrastructure is fully automated using Terraform, which provisions and configure the following components:

- An EC2 instance to host the Node application
  - AWS Secrets Manager for secure secrets storage
  - IAM roles and policies following the principle of least privilege
  - Security groups with strictly controlled access
  - Instance profiles for secure EC2 AWS services communication

What makes this project particularly interesting is how it connects application development with infrastructure management 🫰🫰🫰.

The Challenge

Last week, I was deploying a Node application on an EC2 instance and wondered how to provide environment variables from the .env file to my project. Here's where AWS Secrets Manager becomes useful.

💡
AWS Secrets Manager helps you manage, retrieve, and rotate database credentials, application credentials, OAuth tokens, API keys, and other secrets. For more information, visit this link.

I was curious about securely sharing secrets in my applications using Secrets Manager 🤔👩🏽‍💻, and I also wanted to learn Terraform for Infrastructure as Code (IaC) 😃. This was my first experience with Terraform and I really enjoyed it!

Solution Architecture

The diagram below shows the solution architecture I designed for this project.

This is a Node application that retrieves secrets from AWS Secrets Manager. This Node application is hosted on an EC2 instance with appropriate IAM roles and policies attached to it.

The Node Application

You can find the application in my GitHub Repository. This is a lightweight Node application with a simple UI that serves only to display the secrets, demonstrating the ability to access them from the Secrets Manager. The app uses the AWS SDK to connect with AWS.

Infrastructure as Code with Terraform

For the infrastructure layer of the application, I created this GitHub repository where you can find all my code.

💡
Terraform is an infrastructure as code tool that lets you build, change, and version infrastructure safely and efficiently. This includes low-level components like compute instances, storage, and networking.

Basic Setup ✨

For the setup, I first visited the Terraform Docs to learn how to install it on my local machine. Since I am working with AWS, I read the AWS Provider documentation to understand how to interact with various resources.

If you are using a different provider, you can find the registry here 🙃: https://developer.hashicorp.com/terraform/language/providers#how-to-find-providers

Once you have this set up, make sure you are also logged in to the AWS CLI with the correct credentials.

About the code: For each Terraform configuration block, I created a file named after the block it references. Why? 🤔 Here are some of the reasons:

✅ This approach creates a modular and organized structure.
✅ Each file has a specific purpose.
✅ It makes it easier for team members to understand and navigate the codebase, as they can quickly find specific configurations.

.
├── data.tf
├── output.tf
├── provider.tf
├── resource.tf
├── userdata.sh
└── .gitignore

Setup The Provider ☁️

💡
Terraform relies on plugins called "providers" to interact with remote systems. Terraform configurations must declare which providers they require, so that Terraform can install and use them.

To set up the AWS provider, I created a file named provider.tf with the following content:

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

  required_version = ">= 1.2.0"
}

# Configure the AWS Provider
provider "aws" {
  region = "us-west-2"
}

EC2 Instance Setup 👩🏽‍💻

For the EC2 Instance, I have to tackle different configurations.

First, I created a resource.tf file with all the resources, one of the is the EC2 instance with the respective role to access the Secrets Manager and the Security groups.

This resource creates an EC2 instance with a Linux AMI, instance type t2.micro, an instance profile name, security groups for the instance, and user data to be injected during instance creation.

I also added a tag for billing tracking 😉.

resource "aws_instance" "app_server" {
  ami           = data.aws_ami.linux_ami.id
  instance_type = "t2.micro"
  iam_instance_profile = aws_iam_instance_profile.ec2_instance_profile.name
  key_name = "aws-terraform-challenge"
  security_groups = [ aws_security_group.aws_terraform_challenge_security_group.name ]
  user_data = file("userdata.sh")

  tags = {
    Name = "aws_terraform_challenge"
  }
}

Keep in mind that the following lines in the code use values from data blocks that retrieve this information.

I'll explain each part for better understanding:

The AMI ID is retrieved from the following data block, where I set the most recent argument to true to ensure it brings the latest one. The owner is amazon, and I filter by the Linux 2023 AMI.

data "aws_ami" "linux_ami" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*"]
  }
}

IAM Roles and Policies

The aws_iam_instance_profile provides an IAM instance profile.

resource "aws_iam_instance_profile" "ec2_instance_profile" {
  name = "terraform_challenge_instance_profile"
  role = aws_iam_role.ec2_secrets_role.name
}

The Role:

resource "aws_iam_role" "ec2_secrets_role" {
  name = "secretsrole"

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

  tags = {
    Name    = "EC2SecretsManagerRole"
    Purpose = "Allow EC2 to access Secrets Manager"
  }
}

✨ PRO TIP: Note that I added the tags argument for tracking billing purposes.

The policies:

resource "aws_iam_policy" "my_secrets_policy" {
  name   = "my_secrets_policy"
  path   = "/"
  policy = data.aws_iam_policy_document.my_secrets_policy.json
}

In the code above, the policy argument refers to a reference to a JSON-formatted IAM policy that is generated using a data block for an aws_iam_policy_document. This policy is created following the Least Privilege principle.

data "aws_iam_policy_document" "my_secrets_policy" {
 statement {

    actions = [
      "kms:DescribeKey",
      "kms:ListAliases",
      "kms:ListKeys"
    ]

    resources = [
      data.aws_kms_key.by_alias.arn,
    ]
  }

  statement {
    actions = [
      "secretsmanager:GetSecretValue",
      "secretsmanager:ListSecretVersionIds"
    ]

    resources = [
        join("", [aws_secretsmanager_secret.secret_terraform_challenge.id, "*"])

    ]
  }
}

The resources argument in the code above refers to a data.aws_kms_key piece of information. The AWS KMS Key data block is used to obtain detailed information about the specified KMS Key.

data "aws_kms_key" "by_alias" {
  key_id = "alias/aws/secretsmanager"
}

Then create the resource that attaches a managed IAM Policy to an IAM role:

resource "aws_iam_role_policy_attachment" "secrets_policy" {
  role       = aws_iam_role.ec2_secrets_role.name
  policy_arn = aws_iam_policy.my_secrets_policy.arn
}

Security Groups Configuration ✨

For the security groups, I need to do the following by creating a security group with the right rules:

✅ Create a security group.

✅ Associate the security group with a specific VPC. As you can see, the vpc_id:

✨Allow all outbound rule.
✨Set up inbound rules to:
- Allow HTTP from my IP.
- Allow SSH from my IP to connect to my EC2.
- Allow traffic from my IP on port 3000.

resource "aws_security_group" "aws_terraform_challenge_security_group" {
  name        = "aws_terraform_challenge_security_group"
  vpc_id      = data.aws_vpc.default_vpc.id

  tags = {
    Name = "aws_terraform_challenge_security_group"
  }
}

resource "aws_vpc_security_group_ingress_rule" "allow_http" {
  security_group_id = aws_security_group.aws_terraform_challenge_security_group.id
  cidr_ipv4         = "YOUR_IP_HERE"
  from_port         = 80
  ip_protocol       = "tcp"
  to_port           = 80
}

resource "aws_vpc_security_group_ingress_rule" "allow_ssh_from_my_ip" {
  security_group_id = aws_security_group.aws_terraform_challenge_security_group.id
  cidr_ipv4         = "YOUR_IP_HERE"
  from_port         = 22
  ip_protocol       = "tcp"
  to_port           = 22
}

resource "aws_vpc_security_group_ingress_rule" "allow_3000_traffic_from_my_ip" {
  security_group_id = aws_security_group.aws_terraform_challenge_security_group.id
  cidr_ipv4         = "YOUR_IP_HERE"
  from_port         = 3000
  ip_protocol       = "tcp"
  to_port           = 3000
}

resource "aws_vpc_security_group_egress_rule" "allow_all_egress_rule" {
  security_group_id = aws_security_group.aws_terraform_challenge_security_group.id
  cidr_ipv4   = "0.0.0.0/0"
  ip_protocol = -1
}

This security group is defined within aws_instance.

The vpc_id in the code above is obtained from the following data block, which gives details about a specific VPC, in this case, the default VPC.

data "aws_vpc" "default_vpc"{
  default = true
}

AWS Secrets Manager Setup👩🏽‍💻

For the Secrets Manager, I created an aws_secretsmanager_secret, which is a resource to manage AWS Secrets Manager secret metadata. I set the recovery window to 0 days. Why 0? Because setting it to 0 forces deletion without recovery (This is for the DEMO purposes only).

resource "aws_secretsmanager_secret" "secret_terraform_challenge" {
  name = "secret_terraform_challenge"
  recovery_window_in_days = 0
}

Then, set up the aws_secretsmanager_secret_version to manage the version of the AWS Secrets Manager secret, including its secret value, which in this case is secret.

resource "aws_secretsmanager_secret_version" "secret_terraform_challenge_version" {
  secret_id     = aws_secretsmanager_secret.secret_terraform_challenge.id
  secret_string = "secret"
}

User Data Script Implementation

To run the script when the EC2 instance is created, I created the following user-data bash script to run the application:

#!/bin/bash
yum update -y
curl -fsSL https://rpm.nodesource.com/setup_23.x | bash -
yum install -y nodejs git
mkdir -p /home/ec2-user/app && cd /home/ec2-user/app
git clone https://github.com/lalidiaz/terraform-aws-secrets-manager.git .
npm install
npm run start

🩵 There's something really cool about Terraform 🩵: it has blocks called output.

💡
Output values let you see information about your infrastructure on the command line.

In this case, they will display the AWS Instance AMI and the Instance Public IP in the console. The public IP will be useful when we deploy the application, as you'll see later.

output "aws_instance_ami" {
    value = aws_instance.app_server.ami 
}

output "aws_instance_public_ip" {
  value = aws_instance.app_server.public_ip
}

Deployment Process

Prerequisites

Make sure you have the following prerequisites before running the project:

An AWS Account
AWS CLI installed and configured with appropriate credentials
Terraform installed on your local machine
Your IPv4 address (to configure security group rules)

Step-by-Step Deployment Guide

To deploy the Node application, please clone my repository:

git clone https://github.com/lalidiaz/node-terraform-infrastructure/tree/main
cd node-terraform-infrastructure

Once you are inside the project's folder, let's deploy the app with Terraform and watch the magic happen ✨🙌!

Step 1

💡
The terraform init command initializes a working directory containing Terraform configuration files.

terraform init

Step 2

💡
The terraform plan command creates an execution plan, which lets you preview the changes that Terraform plans to make to your infrastructure.

By default, when Terraform creates a plan it:

Reads the current state of any already-existing remote objects to make sure that the Terraform state is up-to-date.
Compares the current configuration to the prior state and noting any differences.
Proposes a set of change actions that should, if applied, make the remote objects match the configuration.

terraform plan

Step 3

If everything looks correct, you can run the following command to apply the changes:

💡
The terraform apply command executes the actions proposed in a Terraform plan.

terraform apply

And that's it, the project is deployed successfully! ✨🙌🎉

Deployment Verification

To verify the application, you will see the output in the console displaying the AWS EC2 Public IP. Just copy the IP and head over to the browser, paste the ip <aws_instance_public_ip>:3000 you should see the following screen:

Cost Considerations

Please note that we are creating an EC2 instance within the free tier, but the AWS Secrets Manager does have associated costs. Check the documentation pricing page for more details.

Cleanup Process

Finally, remember to always clean up so you don’t incur any changes.

💡
The terraform destroy command is a convenient way to destroy all remote objects managed by a particular Terraform configuration.

terraform destroy

Future Improvements

After talking with my mentor @Mariano González ,he suggested the following improvements for the app, which will be included in the next iterations:

Create a Terraform Backend block
Create a Module
Add CI/CD with GitHub Actions
Refactor the solution to enhance security
Add a local executor to calculate my IP on the fly instead of hardcoding it

Conclusion

While this was my first experience with Terraform, I really enjoyed it and took this challenge very seriously. I spent a few hours working on this solution, and I'm quite happy with the results.Thanks to my mentor @Mariano González 🙏 for guiding me and taking the time to explain concepts to me.

I must admit I was excited when I started working on this project. Although I know I need to keep studying, I learned a lot from this hands-on experience, which gave me the confidence to tackle future challenges!

Thanks for reading! See you in the next post! 👋

🐳 My Docker Journey: From Zero to "It Works on My Machine" (For Real This Time 😂!)

Laura — Tue, 07 Apr 2026 22:13:18 +0000

The Starting Point
The First “Aha!” Moment
Real Challenges I Tacked
My Biggest Wins
Some Tips
Next Steps
To Anyone Starting Out

The Starting Point

Like many, I started my DevOps bootcamp thinking "What's the deal with containers?”

As I continue my journey to become a DevOps Engineer, this is the fourth article about the DevOps Bootcamp by Roxs I'm completing.

Docker is a tool that packages applications with all their dependencies, ensuring they run consistently anywhere. Imagine it as creating small, portable environments (containers) that keep everything an app needs in one place, eliminating the "it works on my machine" problems 😅!

I was excited to learn about Docker because it seemed like the key to solving environment issues. Running apps in isolated containers felt powerful. However, I was also intimidated because Docker has its own terminology and commands. The combination of new concepts and tools made it feel like a steep learning curve, but the benefits were too appealing to ignore.

The First "Aha!" Moment

While studying the Docker section in the bootcamp, I went through the architecture, learned how to create images, publish those images, run containers from those images, and use Docker Compose.

But the first "Aha!" Moment came when I started working on the exercises and challenges from the Bootcamp, gaining hands-on experience.

Alright, let me share what I've been up to in my Docker journey! 🐳

First up was getting my hands dirty with MySQL containers. Not gonna lie, managing databases used to give me anxiety, but Docker made it feel like putting together LEGO blocks.

The real game-changer? Running MySQL with PHPMyAdmin containers together. Seeing these two containers talk to each other was like magic ✨ (okay, maybe not magic, but definitely felt like it at first!).

Then came the fun part: deploying my first PHP web app in a container. Sure, I ran into some obstacles, but that feeling when your application finally spins up in a container? Priceless! 🤩

The PostgreSQL + pgAdmin setup with Docker Compose was next on my list. Let me tell you - Docker Compose is a lifesaver! Instead of typing multiple commands, it was just one docker compose up and boom! 💥 Both services running together.

Finally, I set up a complete PHP development environment 🙌.

I would like to share the container analogy that made sense in my head 🐳:

🚀🧑‍🚀The Spaceship Analogy, I started thinking about containers like tiny spaceships. Each one needs to be completely self-sufficient, its own environment, resources, and life support systems (dependencies). They can dock with the mothership (host system) but remain independent. Just like a spaceship needs to work the same whether it's docked at Earth or Mars, a Docker container runs the same whether it's on my laptop or in the cloud.

Real Challenges I Tackled

Let me tell you about the juicy part of my Docker journey, the actual problems I had to solve:

First up was getting MongoDB and Mongo Express containers to play nice together. Simple enough on paper, right? Well, I learned about container networking and environment variables. But when I finally saw Mongo Express pop up in my browser, connecting smoothly to MongoDB? Was great! 🙌

The "295topics" project involved getting Node.js, Nginx, and MySQL to work together. Each time a page refreshed, it needed to add a record to MySQL and display it back. It sounds simple, but it's a different story when you're actually doing it!

While the Docker basics like managing containers and images were not that hard to handle, the real test came when I had to take on the “Full Stack Challenge with Java, Go, and PostgreSQL” challenge. Tackling this felt like I was brewing up something crazy in the lab: managing Java, Go, and PostgreSQL all in one project.

At first, I was a little intimidated..I mean, Java and Go were completely new to me.

The goal was to automate the entire build, test, package, and deployment process using Docker and Docker Compose.

Now, the tricky part was getting these three components: the Java API (backend), the Go web app (frontend), and the PostgreSQL database, to play nice together. I had to make sure they could talk to each other seamlessly, without any problems.

Just when I thought I had it all figured out, I ran into an issue with the source code.

So I dug into the code, and started troubleshooting.

After a few cups of coffee and some intense debugging sessions, I finally managed to solve it!. But I wasn't done yet, I still had to incorporate semantic versioning and set up a bash script to automate the deployment process.

Writing that deployment script felt like putting together a puzzle 🧩. The script automates the process of building docker images, tag the with versions using a git describe, push them to Docker Hub and running docker-compose.yaml file. ✅

The best part? Documenting everything on my Github Repo. Not just "it works now," but the actual journey: the obstacles I faced, the solutions I found, and (most importantly) why they worked. Because let's be real, future me is going to thank past me for those notes! 📝

Looking back, these weren't just tasks to check off a list. Each challenge taught me something valuable about how containers work in the real world. And that feeling when all services are running smoothly, and your Docker Compose up command works? Worth every debugging session! 🚀

My Biggest Wins

Seeing my containers finally talk to each other through the custom network, and watching my API successfully store data in the MongoDB container, it was amazing 🤩.

Before Docker, setting up my development environment was like building a house of cards. One wrong version of Node and everything would collapse. Then came the bootcamp's Docker module. The first time I wrote a proper Dockerfile, created a .dockerignore, and saw my application running in an isolated container, it clicked🚀.

It happened during our micro-services project. I was staring at my docker-compose.yml file, with multiple services, volumes, and networks defined, when suddenly it all made sense. Containers weren't just isolated boxes anymore, they were building blocks. Each container had its purpose: the frontend, the backend API and the database.

The moment I realized I could bring down my entire development environment with docker compose down and rebuild it exactly the same way with docker compose up build was when I truly understood the power of containerization. The best part? I could confidently say "it will work on your machine too" and mean it.

Some Tips

Run docker system prune regularly to avoid filling your disk with unused images and containers.
Name your containers meaningfully with container_name in docker-compose.yaml, it makes logs much easier to follow.
docker logs -f container_name is your best friend for real-time debugging, ALWAY check the logs!
Use docker exec -it container_name sh to get inside a container and poke around.
Always check container health with docker ps, the 'Up' time can tell you if containers are crash-looping.
Use depends_on in docker-compose.yaml to handle service startup order.

And finally the resources that actually helped me was the Docker section in the DevOps Bootcamp by Roxs.

Next Steps

Getting comfortable with Docker has opened up a whole new world of possibilities. What I've learned about containers isn't just for development anymore, it's about building scalable, production-ready applications. The skills I've gained in Docker and container orchestration are setting the perfect foundation for my Kubernetes ⚙️ journey. I can already imagine deploying my applications, setting up automatic scaling, and managing everything through Kubernetes. It's like I've learned to ride a bike 🚲 with Docker, and now I'm ready to hop on a motorcycle 🏍️ with Kubernetes⚙️! I've already started experimenting with minikube on my local machine 🙌👩🏽‍💻.

To Anyone Starting Out

Here's the truth: everyone struggles at first. That moment when you're staring at terminal errors, wondering why your container won't start, or why your services can't seem to talk to each other, we've all been there. But here's the thing: that confusion is temporary, and the clarity that follows is absolutely worth it.

Practical First Steps:

Start small: Like, really small: Get a single container running first. I started with a simple hello world app.
Master the basic commands: docker build, docker run, docker ps
Don't jump into docker-compose until you understand single containers

As you progress, you might feel like you're hitting a wall or getting stuck with errors. This is when having a mentor can really help. I can't highlight enough how valuable it is to have someone experienced to guide you through these tough times. For me, that mentor has been @Mariano González. His support after I spent hours debugging was invaluable. Sometimes, all it takes is a fresh perspective or an explanation of concepts that you're struggling to understand.

Mentorship isn’t just about getting answers, it's about learning how to approach problems more effectively and building confidence. @Mariano González’s insights and patience helped me break through some of my toughest obstacles, and having someone who genuinely cares about helping others can turn an overwhelming learning process into an enjoyable experience.

So, if you can, find a mentor. They can help you avoid common pitfalls and offer advice. Don’t be afraid to ask questions or ask for help. It's all part of the learning process.

That's it for today! I'll see you in the next post, which will be all about Kubernetes ⚙️

Bash Scripting 👩🏽‍💻

Laura — Tue, 07 Apr 2026 22:10:18 +0000

Why did I started learning Bash Scripting?
My learning process
Challenges faced
Interesting discoveries
Examples from my experience
My humble advice and next steps

Why did I started learning Bash Scripting?

I started learning Bash Scripting because I am doing the RoxsRoss DevOps Bootcamp. This is the third post about my journey to become a DevOps Engineer.

You can also check out the first post and the second post.

The next logical step after learning Linux is learning Bash Scripting. But why?🤔

With Bash, you can easily automate repetitive tasks like deploying applications, managing backups, or monitoring systems. This not only saves time but also reduces the risk of errors that can occur with manual processes.

Bash allows you to monitor performance and optimize system usage. You can create scripts to make sure your resources are used efficiently ✅.

Bash is excellent for logging and monitoring. You can set up scripts to collect logs, track system performance, and even trigger alerts based on certain conditions, helping you maintain a reliable system.

Bash scripting empowers DevOps teams to automate workflows, manage environments, and integrate tools smoothly, leading to faster software delivery and better collaboration between development and operations.

My learning process

I must admit that I felt a bit intimidated at first, but I didn't let impostor syndrome take over. Instead, I was very excited about learning Bash👩🏽‍💻.

I found it very interesting, and there were resources provided to learn and practice, such as books (Introduction to Bash Scripting), theory, practical exercises, and challenges.

I started with an introduction to Bash scripting, followed by the fundamentals:

Basic Linux commands
Permissions and Properties
Redirection and Pipes
Variables and Basic Operations
Control Structures
Functions in Bash
Process Management in Bash
Text Manipulation in Bash
Advanced Interaction with the File System in Bash
Integration and Automation

I love how the DevOps Bootcamp by Roxs is structured. It felt like it set the foundational knowledge really well.

After finishing the fundamentals, I practiced with the practical cases and exercises provided in the Bootcamp. You can find them on the bootcamp website or my Github.

Regarding the challenges in the Bash section, 2 of the 3 challenges displayed there are already solved in the Linux Challenges section. You can find my solutions for those here 🙌.

Challenges faced

Since I am currently working as a Frontend Developer, I didn't find it hard to grasp some concepts like Functions in Bash or Control Structures (Loops). Although the syntax was a bit different, the concepts were still similar.

Here's an example of the syntax for a for loop:

#!/bin/bash

# Define a list of items
fruits=("apple" "banana" "cherry")

# Use a for loop to iterate over the list
for fruit in "${fruits[@]}"; do
  echo "I like $fruit"
done

# I like apple
# I like banana
# I like cherry
# I like date

What was a bit tricky for me was Permissions and Properties. Since I hadn't learned about it before (only when I studied it in the Linux section just before this one), it was a new topic, and I don't use it daily.I believe this is more relevant to Sys Admins or DevOps roles than to Developers, at least in my experience. However, I must say I really enjoyed it.

What I found very interesting was that there are two ways to change permissions:

Symbolic

# Grant read, write, and execute permissions to the user (owner)
# and read and execute permissions to group and others.
chmod u+rwx,g+rx,o+rx file.txt

* `u+rwx`: Adds read, write, and execute permissions to the user (owner).

* `g+rx`: Adds read and execute permissions to the group.

* `o+rx`: Adds read and execute permissions to others.

Numeric

In numeric notation, each permission is represented by a number:

* `4` = read (`r`)

* `2` = write (`w`)

* `1` = execute (`x`)


You add these values together to get the desired permissions for each level (user, group, others):

* `7` = read + write + execute (4 + 2 + 1)

* `6` = read + write (4 + 2)

* `5` = read + execute (4 + 1)

* `4` = read only

```bash
# Set permissions to 755:
# - User (owner) has read, write, and execute permissions (7)
# - Group has read and execute permissions (5)
# - Others have read and execute permissions (5)
chmod 755 myfile.txt
```

Both methods can achieve the same result.

Fortunately, each topic includes an exercise section for practice. You can find my solutions in my Bash Exercises GitHub repository.

Interesting discoveries

I found Bash scripting fascinating because it allows you to schedule tasks to run automatically at specific intervals.

* * * * * command_to_execute

Each * represents a different time field:

Minute (0-59)
Hour (0-23)
Day of the month (1-31)
Month (1-12)
Day of the week (0-7, where both 0 and 7 represent Sunday)

For example, here are a couple of cron jobs that run a backup script:

This runs a script at 10:00 AM every Monday.
```
0 10 * * 1 /path/to/script.sh
```
This runs a script every Sunday at 5 PM.
```
0 17 * * 0 /path/to/script.sh
```
This runs a script at midnight on the first day of each month.
```
0 0 1 * * /path/to/script.sh
```

Another thing I found fascinating was the text manipulation capabilities. My favorite command is grep, a powerful tool for searching and manipulating text patterns within files.

Here are some example use cases:

Search for a specific word in a file. For example, let’s say you want to find the word "error" in logfile.txt.
```
grep "error" logfile.txt
```
This will output all lines in logfile.txt that contain the word "error".
Use the -i option to ignore case sensitivity. For example, if you want to find "error" regardless of case:
```
grep -i "error" logfile.txt
```
This will match "Error", "ERROR", "error", etc.
To search for a pattern in all files within a directory and its subdirectories, use the -r option:
```
grep -r "error" /path/to/directory
```
This will look for "error" in all files within /path/to/directory.

Examples from my experience

I would like to share my solution to challenge_01. This challenge was based on a real-world scenario: “Design an Automated Bash Script for Building a Python Application Using the Flask Framework”.

To solve this, I created a bash script called automation.sh that does the following:

Creates a temporary folder named tempdir.
Copies the specified folders and contents into tempdir as outlined in the challenge.
Creates a Dockerfile inside the tempdir using “cat << EOF > Dockerfile.” I chose this method because it allows for multi-line text, which was necessary for the Dockerfile.
Builds the image using the Dockerfile.
Runs the image!

Final solution

#!/bin/bash

# Create a temporary folder named tempdir and its subdirectories tempdir/templates and tempdir/static.
mkdir -p tempdir/templates tempdir/static

# Confirm the directory structure has been created
echo "Temporary directories created: tempdir, tempdir/templates, tempdir/static"

# Inside the tempdir folder, copy the static/ folder, templates/ folder, and the application desafio2_app.py.
cp -r static tempdir
cp -r templates tempdir
cp desafio2_app.py tempdir

# Construct a Dockerfile, which will be located inside the temporary folder tempdir.
cat << EOF > tempdir/Dockerfile
    FROM python
    RUN pip install flask
    COPY ./static /home/myapp/static/
    COPY ./templates /home/myapp/templates/
    COPY desafio2_app.py /home/myapp/
    EXPOSE 5050
    CMD ["python3", "/home/myapp/desafio2_app.py"]
EOF

# Build the image
docker build -t desafio2_app ./tempdir

# Run the app
docker run -t -d -p 5050:5050 --name nombreapprunning desafio2_app

You can also find this and other solutions on my 👉👉👉👉 Github Repository 👈👈👈👈.

My humble advice and next steps

My advice is to practice regularly. If you are following the DevOps Bootcamp by Roxs, I strongly recommend completing all the exercises and challenges. These are excellent examples of real-world issues to tackle, and I love that ❤️!

Be patient with yourself and always remember that perseverance leads to success 💪.

Make the most of blogs like Stack Overflow and Medium to see how others solve tasks similar to what you need to do. Learn from those with more experience.

And last but not least, there's a command called man. This is a powerful tool that displays the manual pages for different commands. So, whenever you're unsure about a command, you can check the man page:

For example, viewing the Manual for grep command:

man grep

The output looks like this:

GREP(1)                     General Commands Manual                    GREP(1)

NAME
     grep, egrep, fgrep, rgrep, bzgrep, bzegrep, bzfgrep, zgrep, zegrep,
     zfgrep – file pattern searcher

SYNOPSIS
     grep [-abcdDEFGHhIiJLlMmnOopqRSsUVvwXxZz] [-A num] [-B num] [-C num]
          [-e pattern] [-f file] [--binary-files=value] [--color[=when]]
          [--colour[=when]] [--context=num] [--label] [--line-buffered]
          [--null] [pattern] [file ...]

DESCRIPTION
     The grep utility searches any given input files, selecting lines that
     match one or more patterns.  By default, a pattern matches an input line
     if the regular expression (RE) in the pattern matches the input line
     without its trailing newline.  An empty expression matches every line.
     Each input line that matches at least one of the patterns is written to
     the standard output.
     ....

And that's all about Bash Scripting!

While Bash helped us automate our workflow, Docker is about to transform how we think about development environments entirely. Think of it as taking our Bash superpowers and wrapping them in a portable, shareable container that works exactly the same way everywhere. No more "but it works on my machine" drama!

Next steps... Docker 🐳

See you in the next post, where we'll start our container journey together! 🚀

Mastering Linux

Laura — Tue, 07 Apr 2026 22:04:47 +0000

Setting the Stage for Linux ⚙️
Learning process 📚
Challenges faced 🥷
Interesting Discoveries ✨
Examples from my experience 👩🏽‍💻
The impact Linux had on me 🔎
Advice 🎁

Setting the Stage for Linux ⚙️

I've always been amazed by open-source projects. These projects help people solve various problems and allow communities to contribute and come together for a great cause.

I was motivated to learn Linux because I understand its benefits. Most cloud infrastructure, servers, and containers run on Linux. It supports powerful shell scripting languages like Bash, which are essential for automating routine tasks such as system monitoring, deployment pipelines, and server management.

For DevOps, managing permissions, user roles, and secure environments is essential, and Linux makes this much easier with its permission and user management system.

As I shared in my previous post (check out the 🚨🚨🚨UPDATE:🚨🚨🚨 section), I had already downloaded virtualization software and installed Ubuntu on it, so I was ready to start.

Why did I choose Ubuntu?

Because it’s user-friendly, has a large community support, offers regular Long-Term Support (LTS) versions, many applications are available and easy to install and is known for its stability and efficiency in handling high loads.

Learning process 📚

I began learning Linux in Sep’ 2023 by completing the Introduction to Linux course, earning a certification from The Linux Foundation.

But my journey did not end there. As part of the DevOps Bootcamp By Roxs, I continue to learn and practice Linux.

After learning about the different distributions and deciding which one to use, I began refreshing my memory on basic commands, the curl command, and bash scripting.

The Bootcamp includes a series of examples and challenges to solve.

You can find the solutions to the examples and my solutions to the challenges here:

Even though I am following the course structure and find the content amazing, if you want to explore further, I highly recommend the Introduction to Linux course from The Linux Foundation.

Challenges Faced 🥷

At first, I found it a bit challenging to remember all the commands. To overcome this, I practiced and solved every example and challenge in the Bootcamp section. I also found it very helpful to use this Linux Cheat Sheet that Roxs put together.

I also asked for feedback from senior DevOps engineers, read opinions from others on the same journey as me on forums, Reddit, Quora, and blog posts.

Interesting Discoveries ✨

Among all the things about Linux, what I liked most was learning how to manage and monitor processes. I enjoyed seeing real-time information about resource usage and using the Crontab command. Being able to schedule tasks with cron is an amazing benefit.

Examples from my experience 👩🏽‍💻

I wanted to talk about some real-world examples, I managed to solve the 3 challenges from the Bootcamp in the Linux section.

The first challenge involved deploying a Flask application called "Book Library" using Nginx as a reverse proxy and Gunicorn as the WSGI server.

Nginx as a reverse proxy means that Nginx is acting as an intermediary server that forwards client requests to one or more backend servers and Gunicorn (Green Unicorn) as the WSGI (Web Server Gateway Interface) server means that Gunicorn acts as a bridge between my Flask web app and the web server (Nginx).

I was able to solve this challenge by practicing with the examples before tackling the actual challenges, which definitely helped me gain the necessary skills.

In the repository, I added a DEBUGGING section to describe a problem I encountered during the challenge and how I debugged it to successfully solve the issue.

For the second challenge I had to deploy both the frontend and several backend services using PM2 to manage the processes. PM2 is a daemon process manager that will help manage and keep my application online 24/7.

After researching and reviewing the documentation, I realized I needed to create a configuration file to manage multiple applications with PM2. In this section of the repository, I explain how I generated the configuration file to accomplish this.

And finally, the third challenge was more like exercises related to Linux commands. I really enjoyed this one!

It's important to mention that whenever I faced challenges or something didn't work as expected, I documented it in the repository.

The impact Linux had on me 🔎

I feel very optimistic and enthusiastic about learning Linux. I see it as an important milestone that will help me build a foundation for more knowledge and everything that comes next.

Advice 🎁

I strongly recommend the DevOps Bootcamp By Roxs. The bootcamp is well-structured and very comprehensive.

The section begins with an introduction to Linux, covering topics like "What is Linux?", its architecture, history, and distributions. After that, there is a thorough analysis of different Linux distributions and reviews for each. Finally, it focuses on the Linux command line interface (CLI).

I also encourage you to watch the lesson about Linux.

And finally, as a personal note: DON'T let impostor syndrome take over. Learning new things isn't easy, so being patient with yourself is crucial. Every day is a win if you learn something new.

Next Steps: Bash Scripting… 👩🏽‍💻🥷

DevOps Bootcamp by Roxs 2024 ✨

Laura — Tue, 07 Apr 2026 22:01:24 +0000

Why did I decided to start a DevOps Bootcamp?
About the DevOps Bootcamp by Roxs
My Goal
Introduction to Lesson 1: Mastering Linux
First challenges faced
Next Steps
Conclusion 🙌

Why did I decided to start a DevOps Bootcamp?

After completing my AWS Cloud Practitioner Certification, I was studying for the AWS Developer Associate Certification as part of my path to becoming a Cloud DevOps Engineer (found here). However, I realized that I wanted to gain hands-on experience while learning, so I began researching courses and bootcamps to learn more about DevOps in general. I think this is the right move, as it will give me theoretical lessons and the chance to practice what I’ve learned.

Luckily, I came across the 5th edition of this DevOps Bootcamp by Roxs 👀😀✨☁️

About the Bootcamp By Roxs

I was super happy when I found out about this Bootcamp. It’s created by RoxRoss (Rossana Suarez), a Software Engineer, DevOps expert, GitLab HERO, AWS HERO, and Docker Captain 🐳, so she has a lot of knowledge to share!

The bootcamp takes place on her YouTube channel, with live lessons that you can re-watch later if you didn’t have the chance to join online at that time. This is perfect for me because I live on the other side of the world and can follow along asynchronously.

She also put together this AMAZING website for the bootcamp, which includes exercises, challenges, and information about each topic. It’s easy to navigate and very clear.

The first video was an introduction to DevOps in general, and Lesson 1 is all about Linux.

What I also love about this bootcamp is that she created a Discord space for the community to share their successes and help each other. This is amazing because it promotes a sense of community, something I find SUPER cool in tech.

This bootcamp dives into different topics like Linux, Bash Scripting, Docker, and DevOps tools, among others. It also includes some books! 📚

I am super excited and can’t wait to continue watching the lessons!

My Goal 💪

As I shared in my previous blog posts, my goal is to become a DevOps Engineer. This step marks an important milestone for me, as it will not only equip me with the tools but also give me more insights into what it would be like to work as a DevOps Engineer in the future.

I love learning new things and am curious, so this bootcamp got me very excited and happy.

Introduction to Lesson 1: Mastering Linux

Even though I’ve done a Linux Introduction Course with the Linux Foundation a couple of months ago, I didn’t remember much, so I decided to start from the basics.

I took detailed notes in my Notion about Linux commands and practiced in the playground suggested by Roxs.

Moving forward, I’ve set up this GitHub repo to track my progress and to have something to look at whenever I need a boost in my mood (this was advice from my mentor @Mariano González —thank you, Mariano!). Sometimes it’s hard to keep up when learning something new; it’s challenging and requires a lot of patience, so I thought I’d spread the word on this—it might help someone else in the same situation/path as mine.

So, I set up the repo. What’s next? Well, I started working on the Examples section under the Linux topic. At first, I was practicing with the Killercoda Playground, but Rox mentioned that "If you want to go further and challenge yourself, you can install Linux on your computer," so that’s what I chose to do.

First challenges faced

I wanted to install Linux on my computer, but I had to do some research on how to do that because I have a Mac M2, and it was not as simple as just downloading it.

I heard about VirtualBox in the lesson, and after asking some questions to my mentor @Mariano González , I knew I had to download VirtualBox.

In the bootcamp, there’s a section about Linux Distros: characteristics, the level of friendliness in terms of beginners (like me 😀) and other features. I decided to go with Linux Mint 🌱 because it’s beginner-friendly.

So, I installed VirtualBox and downloaded Linux Mint. I couldn’t just simply download VirtualBox; I had to download it from the old builds and find the one that allowed the download for M2, which is VirtualBox 7.0.8 (released April 18, 2023), more specifically the **Developer preview for macOS / Arm64 (M1/M2) hosts.

Okay, so VirtualBox is downloaded ✅, next step: download Linux Mint. I headed over to the official website and hit download!

🚨🚨🚨**UPDATE:**🚨🚨🚨

However, I discovered that VirtualBox doesn’t work with Linux Mint. After researching the issue, reading numerous Stack Overflow posts and Linux blogs, I accidentally came across this post and tutorial, which provided the solution. Although the post and video are in Spanish, both are very illustrative and easy to understand. If you have any issues, please let me know, I'm happy to help! 🙂

After downloading the virtualization software, I encountered one last issue but successfully solved it after further research, so everything is good to go🥷🎉!

Next steps

So, next steps: Practice, practice, practice!

Once I have the Linux environment set up, I’ll start with the Examples section followed by the Challenges section. I’m super excited and curious about what’s next!

Conclusion

In this first part, I faced some challenges and focused on practicing Linux and installing the necessary programs.

I am super happy and excited about this DevOps Bootcamp by RoxRoss. I really love the fact that senior engineers are sharing their knowledge and bringing equal opportunities to everyone. For those who can’t afford a university degree, this is an extraordinary opportunity. I hope one day I can be a mentor to someone else and help them succeed.

That’s it! See you in the next post 🚀

Forem: Laura

Course 3 of 3: AIOps ☁️💪

Table of Contents

Introduction

You Can't Fix What You Can't See

Monitoring

Observability

Monitoring vs Obersavility

Observability + AIOps = Smarter IT Operations

AWS AIOps Tools

AWS CloudWatch Anomaly Detection

AWS X-Ray Insights

AWS DevOps Guru

Better Dev Experience

Amazon Q Developer Security Scanning

Closing Thoughts

Course 2 of 3: CI/CD for Generative AI Applications ⚒️

Table of Contents

Introduction

Intro To DevOps

Infrastructure As Code (IaC) in DevOps

The Hidden Cost of Manual Processes

IaC Benefits

AWS IaC Tools Overview

Code, Build And Test Phases

Code Phase

Build Phase

Test Phase

AI Capabilities in DevOps Workflows

Testing GenAI Apps

Tests in the CI Flow

Continuous Integration (CI)

Hands-on Labs: Set Up a CI/CD Pipeline

Create the CodePipeline

Create the CodeDeploy project

Adding CodeDeploy to CodePipeline

Serverless Deployment Strategies

AWS CodeDeploy in Your Pipeline

CI/CD for Infrastructure

Automate Infra Deployment With CDK in CI/CD Pipeline

Monitoring Your Infrastructure

Monitor, Log, and Audit With CloudTrail

AWS CloudWatch

A Powerful Mix: CloudWatch + CloudTrail

Monitoring with AWS X-Ray

Operating with Confidence

Configuration Change Detection with AWS Config

AWS Systems Manager

Wrapping Up Part Two: The Journey Continues

Course 1 of 3: Upgrading Apps with Gen AI 🤖

Table of Contents

Introduction

Upgrading A TravelGuide App with Generative AI

Some Basic Concepts Before We Proceed (Skip If You Want)

Amazon Bedrock: The Problems It Actually Solves

Custom Knowledge Bases And Model Customization in Amazon Bedrock

Customize the model

Knowledge Bases

Hands On Lab: Creating a Knowledge Base

You can use a Knowledge Base In Two Ways

AI Safety Controls with Amazon Bedrock Guardrails

Integrating AI Models Through the Bedrock API

Engineering Better Conversations: Prompt Engineering

Next Steps

Got my AWS Cloud Practitioner Certification - CLF-C02 ☁️

Table of Contents

Introduction

Motivation and Background

Exam Preparation Steps

Stephane Maarek's Ultimate AWS Certified Cloud Practitioner Course

AWS Cloud Practitioner Essentials Course and other resources

AWS Skill Builder Individual Plan

Official Practice Exam + Neal Davis's Practice Exams

Study Strategy and Tools

Note-taking and Organization

Interactive Learning

Exam Experience

Choosing a Testing Center

Highlights of AWS Cloud Practitioner Certification

Innovative Solutions and Tools