DEV Community: Rahimah Sulayman

Azure Container Apps Guided Project (AZ-2026), Part 5: Traffic Splitting and Revision Management

Rahimah Sulayman — Sat, 03 Oct 2026 17:41:46 +0000

Introduction

Employers value engineers who can release changes safely, without putting every user at risk.

The scenario: At Fabrikam Inc., the container app is deployed and the pipeline works. Now the team wants to ship a new version without sending all traffic to it at once. They need a v2 revision that receives 25 percent of requests while the existing version keeps the other 75 percent, with clear labels so each version can be tested directly.

In this final Part 5, I switch the container app to multiple revision mode, create the v2 revision, label the revisions "current" and "updated", and split traffic 75/25. I then verify the setup on the Revisions and replicas page.

Note: Here, I left the current version as Label-1, I didn't rename it.

The following Azure resources must be available in your Resource group named RG1:

A Container registry instance that contains one image.
A Virtual network with subnets.
A Service Bus Namespace
A Managed Identity
A Private endpoint
A Container App
A Container Apps Environment

You've been asked to configure traffic splitting for your Container Apps to meet the following requirements:

You need to create a new revision of the container app that uses a suffix of v2.
You must ensure that 25 percent of requests to your app are directed to the v2 revision.
You must label the revisions "current" and "updated" and ensure that requests to the "updated" revision are directed to the v2 revision.

You complete the following tasks during this exercise:

1.Set revision management to multiple.

2.Create a new revision with a v2 suffix.

3.Configure labels on the revisions.

4.Configure a traffic percentage on the revisions.

5.Verify the configuration.

Note: I used port 4050 in place of 5000 because my port 5000 was occupied.

Set revision management to multiple

1.In the Azure portal, open your container app resource.

2.On the left side menu, under Application, select Revisions and replicas.

3.At the top of the Revisions and replicas page, select Deployment mode.

4.To switch from single to multi-revision mode, select Apply.

5.On the Ingress page, specify the following information:

Ingress traffic: select Accepting traffic from anywhere.
Ingress type: select HTTP.
Client certificate mode: ensure that Ignore is selected.
Transport: ensure that Auto is selected.
Insecure connections: ensure that Allowed is NOT checked.
Target port: enter 5000
IP Security Restrictions Mode: ensure that Allow all traffic is selected.

6.At the bottom of the Ingress page, select Save, and then wait for the update to complete.

The Deployment Mode will be set to Multiple after the update.

7.On the left-side menu, under Revisions, select Revisions and replicas.
Select create new revision

Configure a traffic percentage and labels on the revisions

1.Ensure that you have the Revisions and replicas page open.

2.For the v2 revision, under Traffic, enter 25 as the percentage.

3.For the other revision, under Traffic, enter 75 as the percentage.

6.For the v2 revision, under Label, enter updated

7.For the other revision, enter current or leave as-is.

8.At the top of the page, select Save.

Check your work

1.Ensure that you have your Container App open in the Azure portal.

2.On the left-side menu, under Application, select Revisions and replicas.

3.Verify that your revisions are configured as follows:

Summary

Cloud and DevOps practitioner who completed a five-part, hands-on series on deploying containerized applications with Azure Container Apps.

Part 5 covers safe release management with revisions and traffic splitting:

Switched the container app from single to multiple revision mode
Created a new v2 revision of the container app
Configured HTTP ingress, accepting traffic from anywhere on target port 5000
Labeled the revisions "current" and "updated", with "updated" mapped to v2
Split traffic 75% to the existing revision and 25% to v2, and verified the configuration on the Revisions and replicas page

Skills practiced:

Azure Container Apps, revision management, traffic splitting, ingress configuration, progressive delivery

Across the full series: Azure resource setup, Azure Container Registry security with managed identity and private endpoints, container app deployment with Service Bus connectivity and HTTP autoscaling, CI/CD with Azure Pipelines and a self-hosted agent, and revision-based releases.

Azure Container Apps Guided Project (AZ-2026), Part 4: CI/CD with Azure Pipelines and a Self-Hosted Agent

Rahimah Sulayman — Sat, 03 Oct 2026 17:18:14 +0000

Introduction

Employers want engineers who can automate deployments, not just run them by hand, and fix the pipeline when it breaks.

The scenario: At Fabrikam Inc., the container app is running, but every release is still manual. The DevOps team wants an Azure Pipeline that deploys the image from Azure Container Registry to Azure Container Apps on a self-hosted agent, and the deployment has to succeed at least once to prove it works.

In Part 4, I configure Pipeline1 to use the self-hosted agent pool and add the Azure Container Apps deployment task. The first run failed, so I troubleshoot the errors and rerun the pipeline until the deployment succeeds. I then verify it in the pipeline's run history and the container app's activity log.

The following Azure resources must be available in your Resource group named RG1:

A Container registry instance that contains one image.
A Virtual network with subnets.
A Service Bus Namespace
A Managed Identity
A Private endpoint
A Container App
A Container Apps Environment

You've been asked to configure a continuous integration environment for Container Apps that meets the following requirements:

You need an Azure Container Apps deployment task in your Azure DevOps environment.
Pipeline1 must deploy a container image from your container registry to your container app using a self-hosted agent pool.
You must ensure that the pipeline successfully deploys the image at least once.

You complete the following tasks during this exercise:

1.Configure Pipeline1 to use the self-hosted agent pool.

2.Configure Pipeline1 with an Azure Container Apps deployment task.

3.Run the Pipeline1 deployment task.

4.Verify the configuration.

Configure `Pipeline1` to use the self-hosted agent pool

1.Open a browser window, navigate to https://dev.azure.com, and then open your Azure DevOps organization.

2.On your Azure DevOps page, to open your DevOps project, select Project1.

3.In the left-side menu, select Pipelines.

4.Select Pipeline1, and then select Edit.

5.To use the self-hosted agent pool, update the azure-pipelines.yml file as shown in the following example:

trigger:
- main

pool:
  name: default

steps:

Recall that the pool section specifies the agent pool to use for the pipeline. The name property specifies the name of the agent pool. In this case, the name is default, which is the pool you configured as a self-hosted agent pool.

6.Under Validate and save, select Save without validating.

7.Enter a commit message, and then select Save.

Configure Pipeline1 with an Azure Container Apps deployment task

1.Ensure that you have Pipeline1 open for editing.

2.On the right side under Tasks, in the Search tasks field, enter azure container

3.In the filtered list of tasks, select Azure Container Apps Deploy

4.Under Azure Resource Manager connection, select the Subscription you're using, and then select Authorize.

5.In the Azure portal tab, open your Container App resource, and then open the Containers page.

6.Use the information on the Containers page to configure the following Pipeline1 Task information:

Docker Image to Deploy: <Registry>/<Image>:<Image tag>
Azure Container App name: <Name>

7.Configure the following Pipeline1 Task information:

Azure Resource group name: RG1

Note

If you need to verify the resource group name, you can find it on the Overview page of your Container App resource.

8.On the Azure Container Apps Deploy page, select Add.

The Yaml file for your pipeline should now include the AzureContainerApps tasks as follows:

trigger:
  - main
pool:
  name: default
steps:
  - task: AzureContainerApps@1
    inputs:
      azureSubscription: '<Subscription>(<Subscription ID>)'
      imageToDeploy: '<Registry>/<Image>:<Image tag>' from Container App resource
      containerAppName: '<Name>' from Container App resource 
      resourceGroup: '<resource group name>'

Here's an example that shows a YAML configuration snippet:

trigger:
  - main
pool:
  name: default
steps:
  - task: AzureContainerApps@1
    inputs:
      azureSubscription: 'Visual Studio Enterprise(1111aaaa-22bb-33cc-44dd-555555eeeeee)'
      imageToDeploy: 'acraz2003cah12oct.azurecr.io/aspnetcorecontainer:latest'
      containerAppName: 'aca-az2003'
      resourceGroup: 'RG1'

9.Select Validate and save, and then select Save again to commit directly to the main branch.

The contents of the YAML file must be formatted correctly, including indentation. If you encounter an error, review the YAML file and correct any indentation issues.

10.Navigate back to the main page of your pipeline.

Run the Pipeline1 deployment task

1.Ensure that you have Pipeline1 open in Azure DevOps.

2.On the Runs tab of the Pipeline1 page, select Run pipeline.

A Run pipeline page opens to display the associated job.

3.Select Run.

The Jobs section displays job status, which progresses from Queued to Waiting.

It can take a couple minutes for the status to transition from Queued to Waiting.

4.If a 'Permission needed' message is displayed ("This pipeline needs permission to access 2 resources before this run can continue"), select View and then provide the required permissions.

5.Monitor the status of the run operation and verify that the run is successful.

It wasn't successful, so I updated the yaml file to include the subscription.

The Azure connection now works. The log shows the login succeeded and containerapp show found aca-az2026. The error "spawnSync az ENOENT" means the task tried to run az to log in to your registry, and Windows couldn't find it. The task runs az in a way that doesn't work with the Windows az.cmd file.

The solution is to give the task your registry username and password, so it logs in with those and skips az for that step. I'll get the Registry credential from the Azure portal.

Go to Settings → Access keys.
Then Switch Admin user on.
Copy the Username (usually the same as the registry name) and one of the Passwords.

Then store the password as a secret:

In Pipeline1, click Edit, then Variables → New variable.

Name: acrPassword
Value: paste the password.

Tick Keep this value secret, then click OK and Save.

Docker permissions issue:

Open Computer Management → Local Users and Groups → Groups → docker-users.
Click Add, add your Windows user, and click OK.
Sign out of Windows and sign back in.
Start Docker Desktop, then start the agent again from PowerShell as administrator (cd C:\agents, then .\run.cmd).
Then click Run pipeline.

This Screenshot of Azure Pipelines is showing a successful run of Pipeline1.

Check your work

In this task, you examine your pipeline and container app to verify successful pipeline runs.

1.Ensure that you have Project1 open in Azure DevOps.

2.On the left side menu, select Pipelines, and then select Pipeline1.

3.The Runs tab displays individual runs that can be selected to review details.

4.Open your Azure portal, and then open your Container App.

5.On the left side menu, select Activity Log.

6.Verify that a Create or Update Container App operation succeeded as a result of running your pipeline.

Summary

Cloud and DevOps practitioner building hands-on Azure skills through a five-part series on Azure Container Apps.

Part 4 covers continuous integration with Azure Pipelines:

Configured an Azure Pipeline to run on a self-hosted Windows agent pool
Added the Azure Container Apps deployment task to deploy an image from Azure Container Registry to the container app
Troubleshot a failed run, including the "spawnSync az ENOENT" error and Docker permission issues on the agent, until the deployment succeeded
Verified the result in the pipeline run history and the container app's activity log.

Skills practiced:

Azure DevOps, Azure Pipelines, YAML pipelines, CI/CD, self-hosted agents, Azure Container Apps, Docker, troubleshooting

Part 3: Deploying a Container App with Managed Identity, Service Bus, and HTTP Scaling

Rahimah Sulayman — Sat, 03 Oct 2026 16:20:17 +0000

Introduction

Employers want engineers who can take an app from a registry to a running, secure, scalable service.

The scenario: At Fabrikam Inc., the registry is secured and the DevOps team is ready to deploy. The container app must run inside the virtual network, pull its image from Azure Container Registry, connect to Service Bus without a stored password, and scale to a maximum of two replicas to control costs.

In Part 3, I deploy the container app to VNET1/ACASubnet, attach a user-assigned managed identity, connect it to Service Bus, and configure an HTTP scale rule. I then verify everything with the Azure CLI.

In this exercise, you will deploy a container app from an image in the Azure Container Registry to the Azure Container Apps platform.

The following Azure resources must be available in your Resource group named RG1:

A Container registry instance that contains one image.
A Virtual network with subnets.
A Service Bus Namespace
A Managed Identity
A Private endpoint

You've been asked to configure a container app that meets the following requirements:

Is deployed to VNET1/ACASubnet.
Pulls an image from a container registry.
Authenticates using a user-assigned managed identity (uai-az2003).
Uses Container App to connect to a Service Bus instance using the .NET client type.
The app can run up to two replicas that are added whenever there are 10,000 HTTP concurrent requests.

You complete the following tasks during this exercise:

1.Create a container app that uses an ACR image

2.Configure the container app to authenticate using the user assigned identity

3.Configure a connection between the container app and Service Bus

4.Configure HTTP scale rules

5.Verify the configuration

Create a container app that uses an ACR image

Complete the following steps to create a container app that uses an ACR image.

1.Open your Azure portal.

2.On the top search bar, in the Search textbox, enter container app

3.In the search results under Services, select Container Apps.

4.Select Create.

5.On the Basics tab, specify the following:

Subscription: Specify the Azure subscription that you're using for this guided project.
Resource group: RG1
Container app name: aca-az2003
Region: Select the Region specified for VNET1 (Central US).

The container app needs to be in the same region/location as the virtual network so you can choose VNET1 for the managed environment. For this guided project, keep all of your resources in the region/location specified for your resource group.

Container Apps Environment: Select Create new.

6.On the Create Container Apps Environment page, select the Networking tab, and then specify the following:

Use your own virtual network: Select Yes.
Virtual network: Select VNET1.
Infrastructure subnet: ACASubnet.

Note

If the ACASubnet subnet is not listed, open your virtual network resource, adjust the subnet address range to 10.0.2.0/23 and retry the steps to create the Container App.

7.On the Create Container Apps Environment page, select Create.

8.On the Create Container App page, select the Container tab, and then specify the following:

Use quickstart image: Ensure that this setting is not selected. If it is selected, uncheck this setting.
Name: Enter aca-az2003
Image source: Ensure that Azure Container Registry is selected.
Registry: Select your container registry. For example: acraz2003cah.azurecr.io
Image: Select aspnetcorecontainer
Image tag: Select latest

9.Select Review + create.

10.Once verification has Passed, select Create.

11.Wait for the deployment to complete.

Note

This deployment normally takes 3-5 minutes to complete, but may take up to 10 minutes.

Configure the container app to authenticate using the user assigned identity

Complete the following steps to configure the container app to authenticate using the user assigned identity.

1.On the Azure portal, open the Container App that you created.

2.Under Security, select Identity.

3.Select the tab for User assigned.

4.Select Add user assigned managed identity.

5.On the Add user assigned managed identity page, select uai-az2003, and then select Add.

Note

Support for Service Connector (preview) on Azure Container Apps ended on March 30, 2026, and after that date new service connections aren't available.

Configure a connection between the container app and Service Bus

Complete the following steps to configure a connection between the container app and Service Bus.

1.On the Azure portal, ensure that you have your Container App open.

2.Under Settings, select Service Connector (Preview).

3.Select Connect to your Services.

4.On the Create connection page, specify the following:

Service type: Select Services Bus.
Client type: Select .NET.

5.Select Next: Authentication.

6.On the Authentication tab, select User assigned managed identity.

7.Ensure that the correct subscription and user assigned managed identity are selected.

Subscription: The Azure subscription that you're using for this guided project. User assigned managed identity: uai-az2003

8.To change tabs, select Review + Create.

9.Once the Validation passed message appears, select Create.

10.Wait for the connection to be created.

It can take a minute before the Service Connector page updates with the new connection.

Configure HTTP scale rules

1.Ensure that your Container App is open in the portal.

2.On the left-side menu under Application, select Revisions and replicas.

3.Notice the Name assigned to your active revision.

4.On the left-side menu under Application, select Containers.

5.To the right of Based on revision, ensure that your active revision is selected.

6.On the left-side menu under Application, select Scale.

7.Configure the Min / max replicas as follows:

Set Min replicas: 0
Set Max replicas: 2

8.Under Scale rule, select + Add.

9.On the Add scale rule page, specify the following:

Rule name: Enter scalerule-http
Type: Select HTTP scaling.
Concurrent requests: Set the value to 10,000.

10.On the Add scale rule page, select Add scale rule.

11.On the Create and deploy new revision page, select Create.

12.Ensure that your new scale rule is displayed.

Check your work

In this task, you verify that your configuration meets the specified requirements.

1.In the Azure portal, ensure that your Container App resource is open.

2.On the left-side menu, under Settings, select Deployment.

3.At the top of the page, ensure that the Continuous deployment tab is selected.

4.Verify that the expected Registry settings are reported:

Repository source: Azure Container Registry
Registry: the name of your Container Registry (for example: acraz2003cah)
Image: aca-az2003

5.Close the Container App page.

6.Open your Container Apps Environment resource.

7.Verify that your Container App uses the proper subnet as follows:

On the Overview page, verify that Virtual Network is set to VNET1.
On the Overview page, verify that Infrastructure subnet is set to ACASubnet.

8.In the Azure portal, open the Cloud Shell and the switch to PowerShell.

Run the following command:

az containerapp connection show --connection servicebus_b2a10 --name aca-az2026 --resource-group RG1

I ran this instead because there's no container app connection yet. I used az containerapp connection create servicebus with these parameters:

Parameter	Value
`--connection`	`sb_az2026_rah`
`--resource-group`	`RG1`
`--name`	`aca-az2026`
`--target-resource-group`	`RG1`
`--namespace`	`sb-az2026-rah`
`--user-identity`	`client-id=<your-client-id> subs-id=<your-subscription-id>`
`--container`	`aca-az2026`
`--client-type`	`dotnet`

The connection was created. The output shows "provisioningState": "Succeeded", and the connection is named sb_az2026_rah on aca-az2026.

Note:

The connection added two environment variables to your container:
AZURE_SERVICEBUS_FULLYQUALIFIEDNAMESPACE = sb-az2026-rah.servicebus.windows.net
AZURE_SERVICEBUS_CLIENTID = your identity's client ID (a55ff84a-...)

This means the app can use these to reach Service Bus with the managed identity, with no connection string or password.

10.Verify that the targetService properties match the specified configuration.

To confirm it's healthy, run:

az containerapp connection validate --connection sb_az2026_rah --name aca-az2026 --resource-group RG1

The results should show success for each check.

To confirm the identity has permission on the Service Bus. The connection normally grants this automatically, but the output shows "roles": null, so it's worth a quick look:You should see a Service Bus role, such as Azure Service Bus Data Owner, on sb-az2026-rah. If there's none, your app will get authorization errors when it tries to send or receive messages.

Run:

az role assignment list --assignee a55ff84a-54e6-4b57-8db0-c20de0e3effb --all -o table

Permissions are in place. The identity has both roles it needs on sb-az2026-rah:

Azure Service Bus Data Sender lets your app send messages.
Azure Service Bus Data Receiver lets your app receive messages.

The AcrPull role is a separate permission that lets the app pull its image from your container registry, so it's fine to have too.

Your setup is complete: the identity is attached to aca-az2026, the connection sb_az2026_rah succeeded, and the roles are assigned.

To verify your HTTP scale rule, you would need to run testing software that's able to simulate 10,000 concurrent HTTP requests and ensure that container replicas are created.

Summary

Cloud and DevOps practitioner building hands-on Azure skills through a five-part series on Azure Container Apps.

Part 3 covers deploying and connecting the container app:

Deployed a container app from an Azure Container Registry image into VNET1/ACASubnet
Attached a user-assigned managed identity for passwordless authentication
Connected the app to Service Bus using the .NET client type, with no connection string
Configured an HTTP scale rule (0 to 2 replicas, 10,000 concurrent requests)
Verified the connection and role assignments (Service Bus Data Sender and Receiver) with the Azure CLI

Skills practiced:

Azure Container Apps, Managed Identity, Service Bus, Service Connector, Azure CLI, Autoscaling, Azure RBAC

Part 2: Securing Azure Container Registry with Managed Identity and Private Endpoints

Rahimah Sulayman — Sat, 03 Oct 2026 15:13:17 +0000

Introduction

Employers expect cloud engineers to build security in from the start, not add it later.

The scenario: At Fabrikam Inc., the DevOps team is moving from AKS to Azure Container Apps. Before deploying anything, the security team requires that the container registry use a managed identity instead of stored credentials, grant only pull permissions (least privilege), and be reachable only through a private endpoint.

In Part 2, I meet those requirements by creating a user-assigned managed identity, assigning it the AcrPull role, and configuring a private endpoint with private DNS on VNET1/PESubnet. I then verify the setup.

Here, I configure a container registry instance for a secure connection from a container app.

The following Azure resources must be available in your Resource group named RG1:

A Container Registry instance that contains one image.
A Virtual Network with subnets.
Service Bus Namespace

Important

The previous unit (Prepare your app deployment tools and resources) includes a Setup section that describes how to configure the recourses for this guided project module. If necessary, go back and follow the Setup instructions.

You've been asked to configure your Azure resources to meet the following requirements:

Your resource group must include a user-assigned managed identity.
Your container registry must be able to use the managed identity to pull artifacts.
Access for the managed identity must be limited using the principle of least privilege.
Your container registry must be accessible from a private endpoint on VNET1/PESubnet.

You complete the following tasks during this exercise:

1.Configure a user-assigned managed identity.

2.Configure your container registry with AcrPull permissions for the managed identity.

3.Configure your container registry with a private endpoint connection.

4.Verify the configuration.

Note

Before continuing, ensure that you've completed the Setup section of the Prepare your app deployment tools and resources unit.
Configure a user-assigned managed identity

Complete the following steps to configure a user-assigned managed identity.

1.Open your Azure portal.

2.On the Search bar, enter managed identity

3.In the filtered list of resources, select User Assigned Managed Identity.

4.On the User Assigned Managed Identity page, select Create.

5.On the Create User Assigned Managed Identity page, specify the following information:

Subscription: Specify the Azure subscription that you're using for this guided project.
Resource group: RG1
Region: Central US
Name: uai-az2003

6.Select Review + create.

7.Select Create.

Configure Container Registry with AcrPull permissions for the managed identity

Complete the following steps to configure Container Registry with AcrPull permissions for the managed identity.

1.In the Azure portal, open your Container Registry resource.

2.On the left-side menu, select Access Control (IAM).

3.On the Access Control (IAM) page, select Add role assignment.

4.Search for the AcrPull role, and then select AcrPull.

5.Select Next.

6.On the Members tab, to the right of Assign access to, select Managed identity.

7.Select + Select members.

8.On the Select managed identities page, under Managed identity, select User-assigned managed identity, and then select the user-assigned managed identity created for this project.

For example: uai-az2003.

9.On the Select managed identities page, select Select.

10.On the Members tab of the Add role assignment page, select Review + assign.

11.On the Review + assign tab, select Review + assign.

12.Wait for the role assignment to be added.

Configure Container Registry with a private endpoint connection

1.Ensure that your Container Registry resource is open in the portal.

2.Under Settings, select Networking.

3.On the Private access tab, select + Create a private endpoint connection.

4.On the Basics tab, under Project details, specify the following information:

Subscription: Specify the Azure subscription that you're using for this guided project.
Resource group: RG1
Name: pe-acr-az2003
Region: Ensure that Central US is selected.

5.Select Next: Resource.

6.On the Resource tab, ensure the following information is displayed:

Subscription: Ensure that the Azure subscription that you're using for this guided project is selected.
Resource type: Ensure that Microsoft.ContainerRegistry/registries is selected.
Resource: Ensure that the name of your registry is selected.
Target sub-resource: Ensure that registry is selected.

7.Select Next: Virtual Network.
8.On the Virtual Network tab, under Networking, ensure the following information is displayed:

Virtual network: Ensure that VNET1 is selected
Subnet: Ensure that PESubnet is selected.

9.Select Next: DNS.

10.On the DNS tab, under Private DNS Integration, ensure the following information is displayed:

Integrate with private DNS zone: Ensure that Yes is selected.
Private DNS Zone: Notice that (new) privatelink.azurecr.io is specified.

11.Select Next: Tags.

12.Select Next: Review + create.

13.On the Review + create tab, when you see the Validation passed message, select Create.

14.Wait for the deployment to complete.

Check your work

In this task, you verify that your configuration meets the specified requirements.

1.In the Azure portal, open your Container Registry resource.

2.On the Access Control (IAM) page, select Role assignments.

3.Verify that the role assignments list shows the AcrPull role assigned to the User-assigned Managed Identity resource.

4.On the left-side menu, under Settings, select Networking.

5.On the Networking page, select the Private access tab.

6.Under Private endpoint, select the private endpoint that you created.

For example, select per-acr-az2003

7.On the Private endpoint page, under Settings, select DNS configuration.

8.Verify the following DNS setting:

Private DNS zone: set to privatelink.azurecr.io.

9.On the left-side menu, select Overview.

10.Verify the following setting:

Virtual network/subnet: set to VNET1/PESubnet.

Summary

Cloud and DevOps practitioner building hands-on Azure security skills through a five-part series on Azure Container Apps.

Part 2 focuses on securing Azure Container Registry for a container app, following the principle of least privilege:

Created a user-assigned managed identity to replace stored credentials
Assigned the AcrPull role so the identity can pull images and nothing more
Configured a private endpoint on VNET1/PESubnet with private DNS integration (privatelink.azurecr.io)
Verified the role assignment, DNS configuration, and network placement against the requirements

Skills practiced: Azure Container Registry, Managed Identity, Azure RBAC, Private Endpoints, Private DNS, Least Privilege, Cloud Networking.

Getting Started with Azure Container Apps. Part 1: Setting Up Your Deployment Tools and Resources

Rahimah Sulayman — Sat, 03 Oct 2026 14:51:06 +0000

Introduction

Many teams adopt Kubernetes early, only to find they use a fraction of its capabilities. Azure Container Apps offers a simpler, serverless way to run containerized applications at scale.

The scenario: You're on the DevOps team at Fabrikam Inc., which runs its containers on Azure Kubernetes Service (AKS). The team isn't using advanced features like custom service meshes, so they're paying for complexity they don't need. Your task is to build a proof of concept showing that Azure Container Apps can simplify their DevOps workflow, scale efficiently, and save resources through scale-to-zero.

This first article lays the groundwork: installing the tools, provisioning the Azure resources, publishing a Web API to GitHub, pushing a Docker image to Azure Container Registry, and configuring Azure DevOps with a self-hosted agent.

Prepare your app deployment tools and resources

In this guided project, you configure Azure resources and other tools to demonstrate the suitability of Azure Container Apps as a deployment option.

Important

An Azure subscription and GitHub account are required for this guided project. For your Azure subscription, we recommend that you have the Owner, Azure account administrator, or Azure co-administrator role. The Contributor role does not provide the permissions required to complete all tasks in this guided project module.

Project overview

You work on a devops team for a technology company named Fabrikam Inc. The team is looking into using Azure Container Apps to run containerized cloud-native apps. Fabrikam has been using Azure Kubernetes Service (AKS) to run containers. Although the team is obtaining the benefits of running apps as containers and from using Kubernetes as a host, they've discovered that they're not using advanced AKS features. For example, they're not using the custom service mesh or autoscaling features. The team believes they can both simplify and improve efficiency of their devops implementation by switching to Azure Container Apps. The team believes that switching to Azure Container Apps will:

Improve their ability to publish and run containerized apps at scale.
Reduce the complexity of their current devops implementation.
Save resources by using scale-to-zero and built-in autoscaling capabilities.

You have been tasked with developing a proof-of-concept solution. The solution must demonstrate the team's ability to:

Configure a secure connection between Azure Container Registry and Azure Container Apps.
Create and configure a container app in Azure Container Apps.
Configure continuous integration by using Azure Pipelines.
Scale a deployed app in Azure Container Apps.
Manage revisions in Azure Container Apps.

Your goal for this module is to implement a solution that demonstrates the deployment of cloud-native apps using Azure Container Apps. To achieve this goal, you complete the following activities:

Set up the host environment and deployment resources.
Configure Azure Container Registry for a secure connection with Azure Container Apps.
Create and configure a container app in Azure Container Apps.
Configure continuous integration using an Azure pipeline.
Configure traffic-splitting and revision management.

Setup

To set up the host environment and deployment resources, you complete the following tasks:

Configure host environment tools.

Install Docker Desktop.
Install Visual Studio Code with Docker and Azure App Service extensions.
Install Azure CLI with containerapp extension.
Install Windows PowerShell.

2.Configure Azure resources that support the container apps solution.

Configure a Resource Group.
Configure a Virtual Network and subnets.
Configure Service Bus.
Configure Azure Container Registry.

3.Configure app and deployment resources that support the container apps solution.

Create a WebAPI app and publish to a GitHub repository.
Create Docker image and push to Azure Container Registry.
Configure an Azure DevOps project and starter pipeline.
Deploy a self-hosted Windows agent.

Install Docker Desktop

Complete the following steps to install Docker Desktop.

Open a browser window, and then navigate to the Docker Desktop install page: https://docs.docker.com/desktop/install/windows-install/

Links to instructions for Mac and Linux installs are available on this page.

2.Ensure that you're working on a computer that meets system requirements.

3.Follow the online instructions to install Docker Desktop.

Install the .NET Software Development Kit

Complete the following steps to install the .NET Software Development Kit (SDK).

Open a browser window, and then navigate to the .NET download page: https://dotnet.microsoft.com/download

2.On the Download .NET page, select the latest Long Term Support (LTS) version of the .NET SDK.

3.Wait for the installer file to finish downloading, and then run the .NET SDK installer file.

On a Windows PC, you can find your Downloads folder using File Explorer. Double-click the installation file to begin the installation process.

4.On the .NET SDK Installer window, select Install.

Install Visual Studio Code with Docker and Azure App Service extensions

Complete the following steps to install Visual Studio Code with Docker and Azure App Service extensions.

Open a browser window, and then navigate to: https://code.visualstudio.com.

2.In the browser window, select Download for Windows.

Note

The Download page for Visual Studio Code automatically detects your operating system. It displays the version to download for your operating system, such as Linux, macOS, or Windows.

3.Wait for the installer file to finish downloading, and then use a file explorer application to navigate to your computer’s downloads folder.

4.In your file explorer application, select and run the Visual Studio Code installer file.

Note

You can install Visual Studio Code using either the User Installer or System Installer. The User Installer installs Visual Studio Code just for the current user, while the System Installer installs Visual Studio Code for all users. The User Installer is the recommended option for most users.

5.Select I accept the license agreement, and then continue following the online instructions to complete the installation.

Accept the default options during the remainder of the installation.

6.Ensure that you have Visual Studio Code open.

7.On the Activity bar, select Extensions.

8.In the Search Extensions in Marketplace textbox, enter C#

Entering "C#" filters the list of extensions to show only the extensions that have something to do with C# coding.

9.In the filtered list of available extensions, select the extension labeled "C# Dev Kit - Official C# extension from Microsoft" that's published by Microsoft.

10.To install the extension, select Install.

11.Wait for the installation to complete.

12.On the EXTENSIONS view, replace C# with docker.

13.In the filtered list of available extensions, select the extension labeled Docker that's published by Microsoft.

14.To install the extension, select Install.

15.Wait for the installation to complete.

16.On the EXTENSIONS view, replace docker with azure app service.

17.In the filtered list of available extensions, select the extension labeled Azure App Service that's published by Microsoft.

18.To install the extension, select Install.

19.Wait for the installation to complete.

20.Close Visual Studio Code.

Install Azure CLI and the `containerapp` extension

Complete the following steps install Azure CLI and the containerapp extension.

Open a browser window, and then navigate to: /cli/azure/install-azure-cli.

You can use any browser, such as the Microsoft Edge browser or the Chrome browser.

2.In the browser window, follow the instructions for installing/updating Azure CLI for your computer's operating system.

The current version of the Azure CLI is 2.65.0. For information about the latest release, see the release notes. To find your installed version and see if you need to update, run az version. You can run az upgrade to install the latest version.

3.Open a command line or terminal application, such as Windows Command Prompt.

4.Sign in to Azure using the az login command.

5.Follow the prompts to complete the authentication process.

6.Install the Azure Container Apps extension using the az extension add --name containerapp --upgrade command.

Install Microsoft PowerShell

Complete the following steps to install Microsoft PowerShell.

Open a browser window, and then navigate to: /powershell/scripting/install/installing-powershell.

2.In the browser window, follow the instructions for installing/updating PowerShell for your computer's operating system.

Configure a Resource Group for your Azure resources

Complete the following steps to configure a resource group for your Azure resources.

NOTE: I used North Europe in place of Central US in this article and 2026 in place of 2003.

Open a browser window, and then navigate to the Azure portal: https://portal.azure.com/

2.Ensure that your Azure account has permission to create resources and assign RBAC permissions. Check the RBAC role(s) assigned to your account before you continue.

The Contributor role isn't able to assign Azure RBAC permissions. We recommend using an account that has been assigned the Owner, Azure account administrator, or Azure co-administrator role for your Azure subscription. Other role combinations could provide sufficient access to complete this guided project module but have not been tested.

3.On the top search bar of the Azure portal, in the Search textbox, enter resource group

4.In the search results, select Resource groups, and then select + Create.

5.On the Basics tab, configure the resource group as follows:

Subscription: Specify the Azure subscription that you're using to complete the guided project.
Resource group: Enter RG1
Region: Select Central US.

You can choose any region that offers the azure services required.

6.Select Review + create.

7.Once validation has passed, select Create.

8.Verify

Configure a Virtual Network and subnets

Complete the following steps to configure a Virtual Network and subnets.

Ensure that you have your Azure portal open in a browser window.

2.On the top search bar of the Azure portal, in the Search textbox, enter virtual network

3.In the search results, select Virtual networks.

4.Select Create virtual network.

5.On the Basics tab, configure your virtual network as follows:

Subscription: Ensure that the Azure subscription that you're using for this guided project is selected.
Resource group name: Select RG1
Virtual network name: Enter VNET1
Region: Ensure that Central US is selected.

6.Select the Address space tab.

7.On the Address space tab, under Subnets, select default.

8.On the Edit subnet page, configure the subnet as follows:

Name: Enter **PESubnet**
Starting address: Ensure that 10.0.0.0 is specified.
Subnet size: Ensure that /24 (256 addresses) is specified.

9.Select Save.

10.On the Address space tab, select + Add a subnet.

11.On the Add a subnet page, configure the subnet as follows:

Name: Enter **ACASubnet**
Starting address: Ensure that 10.0.4.0 is specified.
Subnet size: Ensure that /23 (512 addresses) is specified.

12.Select Add.

13.Select Review + create.

14.Once validation has passed, select Create.

15.Wait for the deployment to complete.

Configure Service Bus

Complete the following steps to configure a Service Bus instance.

Ensure that you have your Azure portal open in a browser window.

2.On the top search bar of the Azure portal, in the Search textbox, enter service bus

3.In the search results, select Service Bus.

4.Select Create service bus namespace.

5.On the Basics tab, configure your Service bus namespace as follows:

Subscription: Ensure that the Azure subscription that you're using for this guided project is selected.
Resource group name: Select RG1
Namespace name: Enter sb-az2003- followed by your name or initials. For example: sb-az2003-cah.
Location: Ensure that Central US is selected.
Pricing tier: Select Basic.

6.Select Review + create.

7.Once the Validation succeeded message appears, select Create.

8.Wait for the deployment to complete.

Configure Azure Container Registry

Complete the following steps to configure a Container Registry instance.

Ensure that you have your Azure portal open in a browser window.

2.On the top search bar of the Azure portal, in the Search textbox, enter container registry

3.In the search results, select Container registries.

4.On the Container registries page, select Create container registry or + Create.

5.On the Basics tab of the Create container registry page, specify the following information:

Note

The name of your Registry must be unique. Also, the Premium tier is required for private link with private endpoints.

Subscription: Ensure that the Azure subscription that you're using for this guided project is selected.
Resource group: Select RG1.
Registry name: Enter acraz2003 followed by your initials and date. For example: acraz2003cah25oct
Location: Ensure that Central US is selected.
SKU: Select Premium.

Important

There is a daily fee associated with the Premium tier. You are responsible for the cost of the Azure resources that you use during this guided project. For more information, see the Azure Container Registry pricing page: https://azure.microsoft.com/pricing/details/container-registry/

6.Select Review + create.

7.Select Create.

8.After the deployment has completed, open the deployed resource.

9.On the left-side menu, under Settings, select Networking.
10.On the Networking page, on the Public access tab, ensure that All networks is selected.

11.On the left-side menu, under Settings, select Properties.

12.On the Properties page, select Admin user, and then select Save.

Create a WebAPI app and publish to a GitHub repository

Complete the following steps to create a WebAPI app and publish to a GitHub repository.

Open Visual Studio Code.

2.On the File menu, select Open Folder.

3.Create a new folder named AZ2003 in a location that is easy to find.

For example, create a folder named AZ2003 on the Windows Desktop.

4.On the Terminal menu, select New Terminal.

5.At the terminal command prompt, to create a new ASP.NET Web API project, enter the following command:

.NET CLI
`dotnet new webapi --no-https`

6.At the terminal command prompt, run the following dotnet CLI
command:

.NET CLI
`dotnet build`

7.On the View menu, select Command Palette, and then run the following command: .NET: Generate Assets for Build and Debug.

If the command generates an error message, select OK, and then run the command again.

8.In the root project folder, create a .gitignore file that contains the following information:

gitignore
[Bb]in/
[Oo]bj/

9.On the File menu, select Save All or Ctrl + s.

10.Open the Source Control view.

11.Select Publish to GitHub.

12.If prompted, to enable the GitHub extension to sign in using GitHub, select Allow, and then provide authorization in GitHub.

13.In Visual Studio Code, select Publish to GitHub public repository.

14.Ensure that the bin and obj folders are not included in the repository.

Create Docker image and push to Azure Container Registry

Complete the following steps to create a Docker image and push the image to your Azure Container Registry.

1.Ensure that you have your AZ2003 code project open in Visual Studio Code.

2.To create a Dockerfile, run the following command in the Command Palette: Docker: Add Docker Files to Workspace.

3.When prompted, specify the following information:

Application Platform: .NET ASP.NET Core.
Operating System: Linux.
Ports: 5000.
Docker Compose files: No.

4.At a terminal command prompt, run the following docker CLI command:

Azure CLI
`docker build --tag aspnetcorecontainer:latest .`

The syntax for the build command is: docker build --tag <image name>:<image tag> .

This command builds a container image that is hosted by Docker and accessible using the Docker extension for VS Code.

5.Wait for the Docker Build command to complete.

6.Open the Visual Studio Code Command Palette, and then run the following command: Docker Images: Push.

7.When the command runs, enter the following information:

Select the docker image name that you created: aspnetcorecontainer
Select the image tag that you created: latest

8.If you see a message stating that no registry is connected, select Connect Registry, and then enter the following information:

Registry provider: Select Azure. Follow the online instructions to verify your Azure account if needed.
Azure subscription: Select the Azure Subscription that you're using for this guided project.
Select your Azure Container Registry resource. For example: acraz2003cah25oct

An image tag is generated. For example: acraz2003cah12oct.azurecr.io/aspnetcorecontainer:latest

To push the image to your Container Registry, press Enter.

The following Docker command is executed:

Azure CLI
docker image push acraz2003cah12oct.azurecr.io/aspnetcorecontainer:latest

9.Wait for the image to be pushed to your Azure Container Registry.

You can verify via Docker Desktop.

10.Open the Source Control view, and then Commit and Sync your file updates.

Configure Azure DevOps and a starter Pipeline

Complete the following steps to configure Azure DevOps and a starter Pipeline:

Open the Azure portal.

2.On the top search bar, in the Search textbox, enter devops

3.In the search results, select Azure DevOps organizations.

4.Select My Azure DevOps Organizations.

5.If you haven’t created an organization, select Free or Create new organization.

6.On the home page of your organization, in the lower-left corner of the page, select Organization settings.

7.On the left side menu under Security, select Policies.

8.Ensure that the Allow public projects policy is set to On.

9.Return to the home page of your organization.

10.To create a new project, select New project.

If you created a new organization, you may see the Create a project to get started page.

11.On the Create new project page, specify the following information:

Project name: Project1
Description: AZ-2003 project
Visibility: Public

12.On the Create new project page, select New project.

13.On the left-side menu, select Repos.

14.Under Import a repository, select Import.

15.On the Import a Git repository page, enter the URL for the GitHub repository you created for your code project, and then select Import.

Your repository URL should be similar to the following example:

https://github.com/<your account>/AZ2003

16.On the left-side menu, select Pipelines.

17.Select Create Pipeline.

18.Select Azure Repos Git.

19.On the Select a repository page, select Project1.

20.Select Starter pipeline.

21.Under Save and Run, select Save, and then select Save.

22.To rename the pipeline to Pipeline1, complete the following steps:

a.On the left-side menu, select Pipelines.

b.To the right of the Project1 pipeline, select More options, and then select Rename/move.

c.In the Rename/move pipeline dialog, under Name, enter Pipeline1 and then select Save.

Note

Don't run the pipeline now. You will configure this pipeline during the project exercises.

Deploy a self-hosted Windows agent

For an Azure Pipeline to build and deploy Windows, Azure, and other Visual Studio solutions you need at least one Windows agent in the host environment.

Complete the following steps to deploy a self-hosted Windows agent:

1.Ensure that you're signed-in to Azure DevOps with the user account you're using for your Azure DevOps organization.

For example: https://dev.azure.com/{your organization}

2.From the home page of your organization, open your user settings, and then select Personal access tokens.

3.To create a personal access token, select + New Token.

4.Under Name, enter AZ2003.

5.At the bottom of the Create a new personal access token window, to see the complete list of scopes, select Show all scopes.

6.For the custom designed scope, select Agent Pools (Read & manage) and Deployment Groups (Read & manage).

Ensure that all the other boxes are cleared.

7.Select Create.

8.On the Success page, to copy the token, select Copy to clipboard.

You use this token when you configure the agent.

9.Ensure that you're signed into Azure DevOps as the Azure DevOps organization owner.

10.Select your DevOps organization, and then select Organization settings.

11.On the left side menu under Pipelines, select Agent pools.

12.If the Get the agent dialog box opens, skip to the next step.

If a list of Agent pools is displayed, complete the following steps:

a. To select the default pool, select Default.

If the Default pool doesn't exist, select Add pool, and then enter the following information:

i.Under Pool type, select Self-hosted.

ii.Under Name, enter default

iii.Select Create.

iv.To open the pool that you just created, select default.

b.Select Agents, and then select New agent.

13.On the Get the agent dialog box, complete the following steps:

a.Select the Windows tab.

b.On the left pane, select the processor architecture of the installed Windows OS version on your machine.

The x64 agent version is intended for 64-bit Windows, whereas the x86 version is intended for 32-bit Windows.

c.On the right pane, select Download.

d.Follow the instructions to download the agent.

14.Use File Explorer to create the following folder location for the agent:

dos
`C:\agents`

15.Unpack the agent zip file into the directory you created.

16.Open PowerShell as an Administrator.

17.Navigate to the "C:\agents" directory, and then enter the following PowerShell command:

.\config`

18.Respond to the configuration prompts as follows:

Enter server URL >: enter the URL for your DevOps organization. Such as: https://dev.azure.com/<your organization>
Enter authentication type (press enter for PAT) >: press Enter.
Enter personal access token >: Paste-in the personal access token that you copied to the clipboard earlier.
Enter agent pool (press enter for default) >: press Enter.
Enter agent name (press enter for YOUR-PC-NAME) > enter az2003-agent
Enter work folder (press enter for _work) >: press Enter.
Enter run agent as service? (Y/N) (press enter for N) >: enter Y
Enter enable SERVICE_SID_TYPE_UNRESTRICTED for agent service (Y/N) (press enter for N) >: enter Y
Enter User account to use for the service (press enter for NT AUTHORITY\NETWORK SERVICE) >: press Enter.
Enter whether to prevent service starting immediately after configuration is finished? (Y/N) (press enter for N) >: press Enter.

A message informing you that the agent started successfully is displayed.

Summary

Cloud and DevOps practitioner building hands-on Azure skills through a five-part project on Azure Container Apps.

This series follows a proof-of-concept scenario: a team running containers on AKS evaluates Azure Container Apps to reduce complexity and cost. Part 1 covers the foundation:

Provisioned Azure resources, including a Resource Group, a Virtual Network with segmented subnets, Service Bus, and Azure Container Registry
Created an ASP.NET Core Web API, containerized it with Docker, and pushed the image to Azure Container Registry
Published the code to GitHub and imported it into Azure Repos
Set up an Azure DevOps project with a starter pipeline and a self-hosted Windows build agent

Coming next in the series: secure ACR-to-Container Apps connection, container app deployment, CI with Azure Pipelines, scaling, and revision management.

Skills practiced so far:

Azure, Azure Container Registry, Azure DevOps, Docker, Azure CLI, PowerShell, .NET, GitHub, cloud networking

You're now ready to begin the Guided project exercises. Good luck!

Promoting a Member Server to Domain Controller, Transferring FSMO Roles, and Configuring Active Directory Sites

Rahimah Sulayman — Tue, 15 Sep 2026 13:05:32 +0000

Introduction

Active Directory is essential in organizations where users, servers, and network resources must be centrally managed and securely controlled.
As businesses expand, multiple domain controllers provide greater availability and support reliable authentication across the environment.
FSMO roles ensure that specific Active Directory operations are managed by designated domain controllers.
Active Directory sites and subnets also help organizations align directory services with their physical and network locations.
In this hands-on exercise, I promoted TAILWIND-MBR1 to an additional domain controller in the existing domain.
I then transferred the RID Master FSMO role to the new domain controller.
I also created a Sydney Active Directory site and associated the 172.16.1.0/24 subnet with it.
These tasks provide practical experience with domain controller deployment, FSMO administration, and Active Directory site configuration in an enterprise environment.
In this exercise, you promote a server to domain controller, transfer a FSMO role to the new domain controller, create a site, and add a subnet to the site.

Install Active Directory Domain Services (AD DS) and promote to Domain Controller

In this task, you promote member server TAILWIND-MBR1 to become a domain controller in the TAILWINDTRADERS domain. To complete this task, perform the following steps:

1.Sign in to TAILWIND-MBR1 as TAILWINDTRADERS\Administrator with the password: Pa55w.rdPa55w.rd.
2.In Server Manager, select the Manage menu and then select Add Roles and Features.

3.On the Before you begin page of the Add Roles and Features wizard, click Next.

4.On the Select installation type page, select Role-based or feature-based installation and click Next.

5.On the Select destination server page, choose Select a server from the server pool, ensure TAILWIND-MBR1 is selected and click Next.

6.On the Select server roles page, select the Active Directory Domain Services checkbox.

This opens the Add features page. Select Add Features. Click Next.

7.On the Select features page, click Next.

8.On the Active Directory Domain Services page, click Next.

9.On the Confirm installation selections page, click Install. Depending on the speed of the computer, installation may take several minutes. When the installation completes, click Close.

10.On the Server manager menu, select the notification icon next to the flag in the top right corner (as shown in the screenshot).

11.On the menu that opens when you select the notification icon, select Promote this server to a domain controller. This will start the Active Directory Domain Services Configuration Wizard.

12.On the Deployment Configuration page, select Add a domain controller to an existing domain and ensure that the domain name is set to tailwindtraders.internal.

13.You must re-authenticate the administrator account. Select Change. Enter Administrator for the user name and Pa55w.rdPa55w.rd for the password. Click OK. Click Next.

14.On the Domain Controller options page, accept the default settings and provide the Directory Services Restore Mode (DSRM) password. To do this, enter the following password twice: Pa55w.rdPa55w.rd. Click Next.

15.On the DNS Options page, click Next.

16.On the Additional Options page, click Next.

17.On the Paths page, click Next.

18.On the Review Options page, click Next.

19.On the Prerequisites Check page, click Install. The installation will take several minutes depending on the speed of the virtual machine. The virtual machine will restart.

20.When the virtual machine restarts, sign in as tailwindtraders\administrator with the password you configured for the default administrator account (Pa55w.rdPa55w.rd)

Transfer Flexible Single Master Operations Roles

In this task, you transfer the RID Master role from TAILWIND-DC1 to TAILWIND-MBR1. To complete this task, perform the following steps:

1.On TAILWIND-MBR1, under Tools open Active Directory Users and Computers.

2.In the navigation pane, right-click Active Directory Users and Computers, point to All Tasks, and then select Operations Masters.

3.On the RID tab, select Change, select Yes, and then click OK.

4.Click Close to close the Operations Masters dialog box.

Create an Active Directory site and configure a subnet for that site

In this task, you create an Active Directory site and configure a subnet associated with that site. To complete this task, perform the following steps:

1.On TAILWIND-DC1, sign in as tailwindtraders\administrator with the password you configured for the default administrator account (Pa55w.rdPa55w.rd).
2.Open Active Directory Sites and Services from the Tools menu.

3.Right-click Sites, select New site, and type Sydney as the site name.

4.For the Link Name, select DEFAULTIPSITELINK and click OK twice.

5.Expand the Sites folder.
6.Right-click Subnets and select New Subnet.

7.As the Prefix, type 172.16.1.0/24, select Sydney as site name and click OK.

8.Close Active Directory Sites and Services.

Summary

This exercise focused on expanding the Active Directory environment by promoting a member server to a domain controller.
The RID Master FSMO role was transferred to the new domain controller to demonstrate role management.
An Active Directory site named Sydney was also created to represent a network location.
The 172.16.1.0/24 subnet was then associated with the Sydney site.
Overall, the exercise provided practical experience with domain controller deployment, FSMO role administration, and Active Directory site configuration.

Strengthening Active Directory Security with NTLM Restrictions, Auditing, and Logon Controls

Rahimah Sulayman — Tue, 15 Sep 2026 11:00:45 +0000

Introduction

In a modern organization, employees rely on centralized systems every day to access computers, applications, files, and other business resources. Behind these routine activities, Active Directory helps determine who can authenticate, what they can access, and how security events are controlled and recorded.

In this hands-on exercise, I strengthened an Active Directory environment by applying targeted security controls through Group Policy. I restricted NTLM authentication, enabled auditing for user account management within the Sydney organizational unit, and configured logon restrictions for members of a security group.

These configurations demonstrate how organizations can reduce legacy authentication risks, improve visibility into account-related changes, and enforce tighter access controls. The exercise provided practical experience translating security requirements into Windows Server and Active Directory policies that support a more secure and auditable enterprise environment.

Overview

In this exercise, you configure settings related to security including disabling NTLM authentication for domain accounts, auditing account management activity, and denying log on as a service for members of a security group.

This exercise should take approximately 10 minutes to complete.

Restrict NTLM Authentication

In this task, you restrict NTLM authentication. To complete this task, perform the following steps in TAILWIND-DC1:

1.From the Tools menu of the Server Manager console, open the Group Policy Management console.

2.In the Group Policy Management console, expand the tailwindtraders.internal forest, the Domains folder, and the tailwindtraders.internal domain. Then expand Group Policy Objects.

3.Right-click Default Domain Controller Policy and click Edit.

4.Navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.

5.Select and double-click Network security: Restrict NTLM: NTLM authentication in this domain.

6.Click the Define this policy setting check box.
7.Select the value Deny all and click OK.

8.Click Yes in the Confirm Setting Change dialog box.

9.Close the Group Policy Management Editor.

Audit User Account Management in Sydney

In this task, you enable auditing of User Account Management in the Sydney OU. To complete this task, perform the following steps in TAILWIND-DC1:

1.From the Tools menu of the Server Manager console, choose Group Policy Management Console.
2.In the Group Policy Management Console, expand the Tailwindtraders.internal domain.
3.Navigate to the Sydney OU, right-click and select Create a GPO in this domain, and link it here….

4.Name the new GPO SydneyOUPolicy.
5.Click OK

6.Right-click SydneyOUPolicy and select Edit.

7.Browse to Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Account Management.
8.Select and double-click Audit User account management.

9.Click the Configure the following audit events check box.
10.Select the Success and Failure values and click OK.

11.Close the Group Policy Management Editor

Deny Log On As a Service

In this task, you configure the Deny Log On As A Service security option. To complete this task, perform the following steps in TAILWIND-DC1:

1.From the Tools menu of the Server Manager console, open the Group Policy Management console.
2.Expand Tailwindtraders.internal domain.
3.Browse to the Sydney OU and right-click SydneyOUPolicy. Select Edit.

4.Browse to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment.
5.Select and double-click the Deny Log on as a service policy.

6.Select the Define this policy setting.

7.Click Add User or Group.
8.Click Browse, click Advanced, and then click Find now.

9.Select Sydney Administrators group.

10.Click OK until dialogue boxes are closed (it may require four or five acknowledgements).

Conclusion

This exercise demonstrated how Group Policy can be used to implement practical security controls across an Active Directory environment. By restricting NTLM authentication, I strengthened authentication security and reduced reliance on legacy protocols. Enabling successful and failed user account management auditing improved visibility into account-related activity within the Sydney OU. Finally, configuring Deny log on as a service for the Sydney Administrators group reinforced least-privilege access and reduced unnecessary service logon exposure.

Overall, the exercise provided valuable hands-on experience in Active Directory security hardening, auditing, authentication control, and Group Policy administration, these are key skills for managing secure Windows Server environments.

Securing Active Directory with Password Policies and Recycle Bin

Rahimah Sulayman — Mon, 14 Sep 2026 16:35:49 +0000

Introduction

Strong Active Directory environments require more than creating users,they require deliberate security controls.
In this hands-on project, I strengthened domain security through practical Group Policy and Active Directory administration.
I configured a 14-character minimum password policy across the domain.
I then implemented a stricter 16-character fine-grained password policy specifically for Domain Admins.
This demonstrates how security requirements can be tailored according to administrative privilege levels.
I also enabled the Active Directory Recycle Bin to provide recovery capability for deleted directory objects.
These configurations reflect practical measures used to improve identity security, access control, and administrative resilience.
Together, the exercise demonstrates my ability to translate security requirements into practical Windows Server and Active Directory controls.

Overview

In this exercise, you configure group policy items related to password policies. This includes configuring the domain password policy, creating a stricter password policy for the Domain Admins group, and enabling the Active Directory Recycle Bin.

This exercise should take approximately 10 minutes to complete.

Configure Domain Password Policy

In this task, you configure the domain password policy. To complete this task, perform the following steps:

1.In TAILWIND-DC1, from the Tools menu of the Server Manager console, open the Group Policy Management console.

2.In the Group Policy Management console, expand the tailwindtraders.internal forest, the Domains folder, and the tailwindtraders.internal domain.

3.Right-click Default Domain Policy and click Edit.

4.In the Group Policy Management Editor, navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy.

5.Double click the Minimum password length policy item.

6.Change the minimum number of characters to 14.
7.Click Ok, and then close the Group Policy Management Editor window.

8.Close the Group Policy Management console.

Configure Fine-Grained Password Policy

In this task, you configure a fine-grained password policy and apply it to the Domain Admins group. To complete this task, perform the following steps in TAILWIND-DC1:

1.From the Tools menu of the Server Manager console, open Active Directory Administrative Center.

2.Under Overview, Click Tailwindtraders (local).
3.In the tailwindtraders (local) pane, open the System container.

4.In the System container, open the Password Settings Container.

5.Click the Password Settings Container, click New, and then click Password Settings.

6.In the Name field, type Domain Admin Password Policy.
7.Set the Precedence field to 1.
8.Set minimum password length to 16.
9.Click OK.

10.Open the new policy Domain Admins Password Policy.

11.In the Directly Applies to section, click Add, then type Domain Admins. Click Check Names and click OK.

12.Click OK.

Enable Active Directory Recycle Bin

In this task, you enable the Active Directory Recycle Bin. To complete this task, perform the following steps in TAILWIND-DC1:

1.From the Tools menu of the Server Manager console, open Active Directory Administrative Center.
2.Click Tailwindtraders (local) in the left pane.
3.In the right pane, select Enable Recycle Bin.

4.Click OK to dismiss the warning.

5.Click OK to dismiss the warning about replication latency.

Project Summary

The exercise resulted in three key Active Directory security configurations.
The domain-wide password requirement was updated to 14 characters through the Default Domain Policy.
A separate Fine-Grained Password Policy named Domain Admin Password Policy was created with a precedence of 1.
The Domain Admins group was assigned the stricter policy with a 16-character minimum password length.
The configuration demonstrated the ability to apply different password requirements to specific security groups.
The Active Directory Recycle Bin was also enabled from Active Directory Administrative Center.
These changes produced a more structured approach to password enforcement and directory-object recovery.
The completed configuration provides a practical record of Active Directory security policy administration.

Administering Active Directory Users, Groups, and Organizational Units

Rahimah Sulayman — Mon, 14 Sep 2026 15:12:55 +0000

Introduction

Active Directory is at the heart of centralized identity and access management in many Windows Server environments.
In this hands-on project, I moved beyond theory to perform practical Active Directory administration tasks.
I created and structured Organizational Units (OUs) for Sydney, Melbourne, and Brisbane to organize users effectively.
I created and managed user accounts while configuring important account properties such as expiration dates.
I implemented security groups and assigned users to appropriate groups to support controlled administration.
I configured a user as a member of Protected Users and explored practical account-security controls.
I also practiced delegating password-reset permissions, managing user attributes, disabling accounts, and resetting passwords.
Together, these exercises demonstrate practical skills relevant to enterprise identity management, system administration, and secure Windows Server environments.

Overview

In this exercise, you perform user management operations.

This exercise should take approximately 25 minutes to complete.

Create Organizational Units

In this task, you create three OUs: Sydney, Melbourne, and Brisbane. To complete this task, perform the following steps:

1.In TAILWIND-DC1, open Active Directory Users and Computers from the Tools menu of the Server Manager console.

2.Right-click on the tailwindtraders.internal domain.

3.Select New, then Organizational Unit.

4.In the New Object - Organizational Unit dialog box, set the name to Sydney and click OK.

5.Repeat this process to create the Melbourne OU and the Brisbane OU.

Create users

In this task, you create a user and configure account properties such as Account Expiration Date. To complete this task, perform the following steps:

1.In TAILWIND-DC1, open Active Directory Users and Computers (or Administrative Center).
2.Right-click on the Sydney OU.
3.Select New, then User.

4.Type SydneyContractor in the Full name and User Logon name fields and click Next.

5.Specify a password, such as Pa55w.rdPa55w.rd, and then confirm the password.
6.Click Next and Finish.

7.Select the Sydney OU. In the Sydney OU, double-click the SydneyContractor user account.

8.In the Account tab, in the Account expires section, select End of: and set the date to Jan 1, 2030. Click OK.

9.Right-click the SydneyContractor user and select Copy.

10.Type MelbourneContractor in the Full name and User Logon name fields. Click Next.

11.Specify a password, such as Pa55w.rdPa55w.rd and then confirm the password.
12.Click Next and Finish.

13.Right-click the SydneyContractor user and select Copy.

14.Type BrisbaneContractor in the Full name and User Logon name fields. Click Next.

15.Specify a password such as Pa55w.rdPa55w.rd and then confirm the password.

16.Click Next and Finish.
17.Drag the MelbourneContractor user to the Melbourne OU.

18.If a warning about mooving objects appears, click Yes.
19.Drag the BrisbaneContractor user to the Brisbane OU.

20.If a warning about mooving objects appears, click Yes.

Create the Sydney Admins group

In this task, you create a new security group named Sydney Administrators. To complete this task, perform the following steps:

1.In TAILWIND-DC1, open Active Directory Users and Computers.
2.Right click the Sydney OU, and select New, then Group.

3.Type Sydney Administrators in Group name and select Universal in group scope. Click OK.

4.In the Sydney OU, double-click the SydneyContractor User account.

5.In the Member Of tab, click Add.

6.Type Sydney Administrators.
7.Click Check Names.

8.Click OK, then click OK.

Configure a user as a Protected User

In this task, you configure the SydneyContractor user account as a protected user. To complete this task, perform the following steps:

1.In TAILWIND-DC1, open Active Directory Users and Computers (or Administrative Center).
2.Navigate to the Sydney OU and double-click the SydneyContractor User account.
3.In the Member Of tab, click Add.
4.Type Protected Users.
5.Click Check Names.

6.Click OK, then click OK.
Then you can verify.

Delegate Security Permissions to an OU to a security group

In this task, you delegate the ability to reset passwords and force password change to the Sydney Administrators group over accounts in the Sydney OU. To complete this task, perform the following steps:

1.In TAILWIND-DC1, open Active Directory Users and Computers.
2.Right-click the Sydney OU and click Delegate Control.

3.On the Welcome page of the Delegation of Control Wizard, click Next.

4.Click Add and type Sydney Administrators.

5.Click Check Names.

6.Click OK and click Next.
7.On the Tasks to Delegate page, select the Reset user passwords and force password change at next logon option. Click Next.

8.Click Finish.

Configure City Attribute for a User

In this task, you configure a city attribute for a user account and then use the Find attribute to verify that the user is present. To complete this task, perform the following steps:

1.In TAILWIND-DC1, open Active Directory Users and Computers.
2.Select the Sydney OU, right-click the SydneyContractor user account, and click Properties.

3.In the Address tab of the Sydney Contractor properties, set the City field to Sydney and click OK.

4.In Active Directory Users and Computers, right-click Tailwindtrader.internal and click Find.

5.In the Advanced tab of the Find Users, Contacts, and Groups dialog box, select Field, then User, then City.

Set Condition to Is (exactly). Set Value to Sydney. Click Find Now.

6.Click Yes on the Find in the Directory pop-up.

7.Verify that user SydneyContractor is listed in the Search results.

8.Close the Find Users, Contacts, and Groups dialog box.

Disable the Melbourne Contractor User

In this task, you disable the Melbourne Contractor user. To complete this task, perform the following steps:

1.In TAILWIND-DC1, open Active Directory Users and Computers, and then open the Melbourne OU.
2.In the Melbourne OU, right-click MelbourneContractor and click Disable Account.

3.Click OK.

Reset the password of the Brisbane Contractor User

In this task, you reset the password of the BrisbaneContractor user. To complete this task, perform the following steps:

1.In TAILWIND-DC1, open Active Directory Users and Computers, and then open the Brisbane OU.
2.Right-click the BrisbaneContractor user and select Reset Password.

3.On the Reset Password dialog box, type the password Pa66w.rdPa66w.rd twice and select OK.

Click OK again in the dialog that notifies you that the password has been changed.

Project Summary

This project provides hands-on experience administering Active Directory Domain Services in a Windows Server environment.
It covers creating and organizing Organizational Units, managing user accounts, and configuring account properties.
Security groups were created to support structured access and administration.
The project also demonstrates Protected Users, delegated password-reset permissions, and user attribute management.
Additional tasks included disabling user accounts and resetting passwords.
Overall, the project demonstrates practical identity management, security, and Windows Server administration skills relevant to enterprise IT environments.

Administer-Active-Directory-Domain-Services

Rahimah Sulayman — Mon, 14 Sep 2026 13:00:48 +0000

Project Introduction

A company deploying a new branch office can use this setup to establish centralized authentication and manage employee computers through Active Directory.
Infrastructure teams can use Hyper-V to build isolated server environments for testing domain controllers, networking, and server configurations before production deployment.
Systems administrators can then join application, file, or other member servers to the domain for centralized identity and administration.

This project demonstrates how to build a practical Windows Server infrastructure lab using Hyper-V.
It uses Windows 11 to host two Windows Server 2022 virtual machines.
A dedicated Hyper-V NAT network is configured for private server communication and internet access.
The first server, TAILWIND-DC1, is deployed as an Active Directory Domain Controller.
The tailwindtraders.internal domain is created to provide centralized identity and authentication.
The second server, TAILWIND-MBR1, is configured as a domain member server.

Project overview

In this guided project, you go through the major steps of creating, configuring, and maintaining a domain controller. You also have the opportunity to promote a domain controller.

This exercise should take approximately 45 minutes to complete.

Setup

To reduce resource access requirements (such as access to Windows Server or a Microsoft Azure subscription), this guided project uses a Windows 10 or Windows 11 machine to run a virtualized environment. You configure a Windows 10 or Windows 11 computer’s Hyper-V subsystem to support the two Windows Server 2022 Evaluation Edition virtual machines that you use in this project. You require the Professional or Enterprise edition of Windows 10 or Windows 11 to perform these tasks.

The computer that functions as the Hyper-V virtualization host should have at least 16 GB of RAM. You can also use an evaluation version of Windows Server with the Hyper-V role installed as the host for these virtual machines, or to configure a third-party virtualization platform to host both virtual machines. The exercises and tasks in this lab use Windows 11 when describing the Hyper-V host. The options presented here make it easy to locate large virtual machine files if you want to remove the configuration after you finish with the project.

The Setup section consists of three main tasks:

Install Hyper-V
Create Windows Server Domain Controller Virtual Machine
Create Windows Server Domain Member Server

Install Hyper-V

In this task, you install Hyper-V and configure a NAT switch. You configure Hyper-V to use a different set of default directories to store virtual machine files and hard disks. You can use the options presented in these instructions or choose your own location.

1.Sign in to the Windows 11 computer with an account that has local Administrator privileges.
2.On the Windows 11 Computer click Start, select Settings and on the Settings page select System.
3.On the System page of Settings, scroll down until you locate Optional Features. Select Optional Features.
4.On the Optional Features page, scroll down until you locate More Windows Features under Related Settings.

5.On the Windows Feature page, select the checkbox next to Hyper-V and click OK as shown in the exhibit.

6.When the installation completes, on the Windows Features page, click Restart Now.
7.After the computer restarts, sign in again using the same account that has local Administrative privileges.
8.Click Start and search for Hyper-V Manger. Pin Hyper-V Manager to the Taskbar.
9.Open Hyper-V Manager, right click on the local computer, and select Hyper-V Settings.
10.On the Hyper-V settings dialog box, under Server, select Virtual Machines. Set the location of the Virtual Machines folder to C:\VirtualMachines.

11.Under the Hyper-V settings dialog box, under Server, select Virtual Machine Hard Disks. Set the location of the Virtual Machine Hard Disks to C:\VirtualMachines\VHDs.
12.Click OK to close the Hyper-V Settings dialog box.

13.Open PowerShell with administrator access and run the following commands to create a NAT network.
New-VMSwitch -SwitchName “NATSwitch” -SwitchType Internal
New-NetIPAddress -IPAddress 10.10.10.1 -PrefixLength 24 -InterfaceAlias “vEthernet (NATSwitch)”
New-NetNat -Name “NATNetwork” –InternalIPInterfaceAddressPrefix “10.10.10.0/24”
14.Close PowerShell.

Create Windows Server Domain Controller Virtual Machine

In this task, you deploy and configure a Windows Server 2022 Domain Controller for the lab in which you perform tasks related to the Applied Skill Credential. To perform this task, ensure that you downloaded the Windows Server 2022 Evaluation Edition ISO file from https://www.microsoft.com/en-us/evalcenter/download-windows-server-2022. Place this file in the folder c:\ISOs. This evaluation ISO allows you to run a full version of Windows Server 2022 for up to 180 days.

1.In Hyper-V Manager on the Actions menu select New and then select Virtual Machine.
2.On the Before you Begin page of the New Virtual Machine Wizard, click Next.
3.On the Specify Name and Location page of the New Virtual Machine Wizard, type the name TAILWIND-DC1 and click Next.

4.On the Specify Generation page, select Generation 2 and click Next.

5.On the Assign Memory page, set the startup memory to 4096 MB and leave the Use Dynamic Memory for this virtual machine option selected. Click Next.

6.On the Configure Networking page, set the Connection in the drop-down menu to NATSwitch and click Next.
7.On the Connect Virtual Hard Disk page, accept the defaults and click Next.

8.On the Installation Options page, select the Install an operating system from a bootable image file option and then click Browse to select the Windows Server 2022 Evaluation Edition iso file (named SERVER_EVAL_x64FRE_en-us.iso). You already downloaded this file to the C:\ISOs folder. Click Next.
9.On the Summary page, click Finish.

10.In Hyper-V Manager, right-click TAILWIND-DC1 and select Settings.

11.On the TAILWIND-DC1 Settings page, under Management select Checkpoints and ensure that the Use automatic checkpoints option isn’t selected as is shown in the screenshot. Click OK.

12.Double-click TAILWIND-DC1. This opens the Virtual Machine Connection window. Select Start. When the Press any key to boot from CD or DVD message displays, use the mouse to select inside the virtual machine window and press the Space bar. This sets the virtual machine to boot from the attached ISO file.

13.On the Microsoft Server Operating System Setup page, accept the defaults and click Next.
14.On the Install now page, select Install now.

15.On the Microsoft Server Operating System Setup page, select Windows Server 2022 Standard Evaluation (Desktop Experience) as shown in the screenshot and click Next.

16.On the Applicable notices and license terms page, review the license and then select the I Accept checkbox. Click Next.
17.On the Which type of installation do you want? page, select Custom.

18.On the Where do you want to install the operating system? page, select Drive 0 and click Next.

The operating system will install. This takes several minutes depending on the speed of the computer you’re using. The virtual machine will restart.

19.On the Customize settings page, you are asked to provide a password for the built-in Administrator account. Enter the password: Pa55w.rdPa55w.rd twice. The password is a demonstration password and shouldn’t be used on production systems. You can also choose your own password here. After you have entered the Administrator password twice, click Finish. You won’t be connected to the running virtual machine.
20.On the virtual machine’s lock screen, enter the Administrator password Pa55w.rdPa55w.rd to sign in.
21.After you sign in, right-click the network icon, represented by a globe on the task bar, and select Open Network & Internet Settings.
22.On the Network Status page, select Change adapter options.

23.On the Network Connections page, right-click Ethernet and select Properties.

24.On the Ethernet Properties page, select the Internet Protocol Version 4 (TCP/IPv4) item and click Properties.

25.On the General tab of the Internet Protocol Version 4 (TCP/IPv4) Properties page, set the IP address configuration as follows and click OK:

a.Use the following IP address
i.IP address: 10.10.10.1
ii.Subnet Mask: 255.255.255.0
iii.Default Gateway: 10.10.10.1

b.Use the following DNS server addresses:
i.Preferred DNS server: 1.1.1.1
ii.Alternate DNS server: 8.8.8.8

26.Click OK. When queried about whether you want to allow the computer to be discoverable, select Yes.

27.From the Start menu, open Server Manager, select Local Server and then select the Computer Name. This opens the System Properties dialog box. On the Computer Name page of the System Properties dialog box, select Change.
28.On the Computer Name/Domain Changes dialog box, set the computer name to TAILWIND-DC1 and then click OK.

29.In the dialog informing you that you need to restart your computer click OK.
30.On the System Properties dialog box, select Close.
31.In the You must restart your computer to apply these changes dialog box, click Restart Now. The computer will restart.

32.When the computer has restarted, sign in as Administrator with the password you configured during installation.
33.In Server Manager, select the Manage menu and then select Add Roles and Features.

34.On the Before you begin page of the Add Roles and Features wizard, select Next.
35.On the Select installation type page, select Role-based or feature-based installation and click Next.
36.On the Select destination server page, click Select a server from the server pool, ensure TAILWIND-DC1 is selected and click Next.

37.On the Select server roles page, select the Active Directory Domain Services checkbox. This opens the Add features page. Select Add Features. On the Select server roles page, click Next.

38.On the Select features page, click Next.
39.On the Active Directory Domain Services page, click Next.

40.On the Confirm installation selections page, select Install. Depending on the speed of the computer, installation may take several minutes. When the installation completes, click Close.

41.On the Server manager menu, select the notification icon next to the flag in the top right corner shown in the screenshot.
42.On the menu that opens when you select the notification icon, select Promote this server to a domain controller. This starts the Active Directory Domain Services Configuration Wizard.

43.On the Deployment Configuration page, select Add a new forest and set the root domain name to tailwindtraders.internal. Click Next.

44.On the Domain Controller options page, accept the default settings and provide the Directory Services Restore Mode (DSRM) password. To do this, enter the following password twice: Pa55w.rdPa55w.rd. Click Next.

45.On the DNS Options page, click Next.
46.On the Additional Options page, click Next.
47.On the Paths page, click Next.
48.On the Review Options page, click Next.
49.On the Prerequisites Check page, click Install. The installation takes several minutes depending on the speed of the virtual machine. The virtual machine will restart.

50.When the virtual machine restarts, sign in as tailwindtraders\administrator with the password you configured for the default administrator account (Pa55w.rdPa55w.rd)

Create Windows Server Domain Member Server

In this task, you deploy and configure a Windows Server 2022 Domain member server for the lab in which you perform tasks related to the Applied Skill Credential. This task also uses the evaluation edition iso file.
NOTE: The screenshots here are fewer because the steps are very similar.
1.In Hyper-V Manager on the Actions menu, select New and then select Virtual Machine.
2.On the Before you Begin page of the New Virtual Machine Wizard, click Next.
3.On the Specify Name and Location page of the New Virtual Machine Wizard, enter the name TAILWIND-MBR1 and click Next.

4.On the Specify Generation page, select Generation 2 and click Next.
5.On the Assign Memory page, set the startup memory to 4096 MB and leave the Use Dynamic Memory for this virtual machine option selected. Click Next.
6.On the Configure Networking page, set the Connection in the drop-down menu to NATSwitch and click Next.
7.On the Connect Virtual Hard Disk page, accept the defaults and click Next.
8.On the Installation Options page, select the Install an operating system from a bootable image file option and then click Browse to select the Windows Server 2022 Evaluation Edition iso file (named SERVER_EVAL_x64FRE_en-us.iso) that you have downloaded to the C:\ISOs folder. Click Next.
9.On the Summary page, click Finish.
10.In Hyper-V Manager, right-click TAILWIND-MBR1 and select Settings.
11.On the TAILWIND-MBR1 Settings page, under Management, select Checkpoints, ensure that the Use automatic checkpoints option isn’t selected, and click OK.
12.Double click TAILWIND-MBR1. This brings up the Virtual Machine Connection window. Click Start. When the Press any key to boot from CD or DVD message appears, use the mouse to select inside the virtual machine window and press the Space bar. This sets the virtual machine to boot from the attached ISO file.
13.On the Microsoft Server Operating System Setup page, accept the defaults and click Next.
14.On the Install now page, click Install now.
15.On the Microsoft Server Operating System Setup page, select Windows Server 2022 Standard Evaluation (Desktop Experience) and click Next.
16.On the Applicable notices and license terms page, review the license and then select the I Accept checkbox. Click Next.
17.On the Which type of installation do you want? page, select Custom.
18.On the Where do you want to install the operating system? page, select Drive 0 and click Next. The operating system will install. This takes several minutes depending on the speed of the computer you’re using. The virtual machine will restart.
19.On the Customize settings page, you are asked to provide a password for the built-in Administrator account. Enter the password: Pa55w.rdPa55w.rd twice. The password is a demonstration password and shouldn’t be used on production systems. You can also choose your own password here. After you have entered the Administrator password twice, select Finish. You won’t be connected to the running virtual machine.
20.On the virtual machine’s lock screen, enter the Administrator password Pa55w.rdPa55w.rd to sign in.
21.After you have signed in, right-click the network icon, represented by a globe on the task bar, and select Open Network & Internet Settings.
22.On the Network Status page, select Change adapter options.
23.On the Network Connections page, right-click Ethernet and select Properties.
24.On the Ethernet Properties page, select the Internet Protocol Version 4 (TCP/IPv4) item and click Properties.

25.On the General tab of the Internet Protocol Version 4 (TCP/IPv4) Properties page, set the IP address configuration as follows and click OK:

a.Use the following IP address:

i.IP address: 10.10.10.20
ii. Subnet Mask: 255.255.255.0
iii.Default Gateway: 10.10.10.1

b.Use the following DNS server addresses:
i.Preferred DNS server: 10.10.10.10
ii.Alternate DNS server: 8.8.8.8
26.Click Close. When queried about whether you want to allow the computer to be discoverable, select Yes.
27.From the Start menu, open Server Manager, select Local Server and then select the Computer Name. This opens the System Properties dialog box. On the Computer Name page of the System Properties dialog box, select Change.
28.On the Computer Name/Domain Changes dialog box, set the computer name to TAILWIND-MBR1 and then click OK.
29.On the dialog informing you that you need to restart your computer, click OK.
30.On the System Properties dialog box, click Close.
31.On the You must restart your computer to apply these changes dialog box, click Restart Now. The computer will restart.
32.When the computer has restarted, sign in as Administrator with the password you configured during installation.
33.In the Server Manager console, select the Local Server section. In the Local Server section, select TAILWIND-MBR1 next to Computer Name. this opens the System Properties dialog box.
34.On the System Properties dialog box, click Change.
35.On the Computer Name/Domain Changes dialog box, select Domain under Member of, enter the domain name TAILWINDTRADERS, and click OK.

36.On the Computer Name/Domain Changes dialog box, enter the following username and password and click OK:

a.Username: TAILWINDTRADERS\Administrator
b.Password: Pa55w.rdPa55w.rd

37.Momentarily, the Welcome to the Tailwintraders domain dialog will appear. Click OK.

38.On the System Properties dialog box, click Close.
39.On the dialog asking you to restart the computer, click Restart Now.

Conclusion

This project provides practical experience building and administering a Windows Server infrastructure environment.
Hyper-V was used to create an isolated virtual environment for deploying Windows Server 2022.
A dedicated NAT network was configured to enable communication between the virtual machines and external networks.
TAILWIND-DC1 was successfully configured as an Active Directory Domain Controller.
The tailwindtraders.internal domain demonstrated centralized identity and authentication management.
TAILWIND-MBR1 was configured as a domain member server and joined to the organizational domain.
Overall, the lab strengthens practical skills in Hyper-V, networking, Active Directory, DNS, and Windows Server administration.

YAML Learning Lab

Rahimah Sulayman — Tue, 04 Aug 2026 15:45:17 +0000

Introduction

YAML is one of the most widely used configuration and data serialization formats across modern cloud engineering, DevOps, automation, and CI/CD environments.

From GitHub Actions workflows to Kubernetes manifests and infrastructure configuration, YAML provides a human-readable way to represent structured data while remaining easy for machines to process.

The YAML Learning Lab is a practical technical repository focused on YAML syntax, structured data representation, configuration patterns, validation, and its application within modern DevOps workflows.

🔗 GitHub Repository: YAML Learning Lab

A Brief History of YAML

YAML was created in 2001 by Clark Evans, Ingy döt Net, and Oren Ben-Kiki as a human-friendly data serialization language.

The name YAML originally stood for "Yet Another Markup Language." It was later reinterpreted as "YAML Ain't Markup Language", emphasizing that YAML is a data serialization language, rather than a markup language.

This distinction is important.

Markup languages such as HTML are primarily concerned with describing the structure and presentation of documents, while YAML focuses on representing structured information and configuration in a format that is readable by both humans and machines.

Today, YAML is widely used in:

Cloud configuration
CI/CD pipelines
Kubernetes
Infrastructure as Code
Application configuration
Automation
DevOps tooling

Project Overview

The repository brings together practical YAML examples covering:

Key-value pairs
Mappings
Nested structures
Sequences
Lists of objects
Data types
Comments
Quoted strings
Multiline strings
Anchors and aliases
Merge keys
Multi-document YAML
GitHub Actions workflows
YAML validation with Python and PyYAML

The project demonstrates how YAML syntax translates into structured configuration used by modern engineering tools.

Project Setup

The project was organized as a Git repository with individual YAML files representing different concepts.

The repository structure keeps each concept isolated while also providing a final configuration challenge that combines multiple YAML features.

YAML Fundamentals

The first examples introduce YAML's basic key-value structure.

name: Raphael
role: Cloud Engineer
country: Nigeria

A YAML mapping associates each key with a value:

Key	Value
`name`	`Raphael`
`role`	`Cloud Engineer`
`country`	`Nigeria`

This simple structure is the foundation for more complex YAML configurations.

Mappings and Nested Structures

YAML uses indentation to represent relationships between data elements.

For example:

person:
  name: Raphael
  role: Cloud Engineer

Here, name and role are properties nested under person.

Nested structures allow configuration to represent relationships between related pieces of information without requiring complex syntax.

Nested mappings extend this idea by allowing multiple levels of configuration:

person:
  name: Raphael
  age: 30
  country: Nigeria

One important YAML rule becomes obvious here:

Indentation defines structure.

YAML configuration should use spaces for indentation rather than tabs.

Sequences

YAML sequences represent ordered collections.

They are identified using a hyphen (-):

skills:
  - Azure
  - Docker
  - Kubernetes
  - Git

This creates a list of four values under the skills key.

Sequences are common in configuration files for representing:

Packages
Ports
Hosts
Skills
Resources
Configuration options

Lists of Objects

YAML sequences can contain mappings, making it possible to represent collections of structured objects.

employees:
  - name: Raphael
    role: Cloud Engineer

  - name: Sarah
    role: DevOps Engineer

  - name: David
    role: Solution Architect

Each list item contains multiple properties.

This pattern is particularly useful when configuration describes multiple resources that share a common structure.

YAML Data Types

YAML supports several common data types.

person:
  name: Raphael
  age: 30
  salary: 4500.50
  active: true
  verified: false
  phone: null

These values represent different data types:

Value	Type
`Raphael`	String
`30`	Integer
`4500.50`	Floating-point number
`true`	Boolean
`false`	Boolean
`null`	Null

Understanding how YAML interprets values is important when configuration is consumed by automation tools or programming languages.

Comments and Quoted Strings

Comments begin with # and are ignored by YAML parsers.

# Employee Information Configuration
city: Lagos

Comments are useful for documenting configuration and explaining why a particular value or section exists.

YAML also supports quoted strings:

message: "Welcome: Cloud Engineers!"

Quoting can make the intended value explicit, particularly when a value contains characters that could otherwise be interpreted specially.

Multiline Strings

YAML provides block scalar syntax for storing multiline text.

There are two important styles:

| — literal block
> — folded block

Literal Block

The | character preserves line breaks.

bio_literal: |
  I enjoy learning Azure.
  I build cloud solutions.
  I teach DevOps.

Folded Block

The > character folds consecutive lines into a paragraph-like value.

bio_folded: >
  I enjoy learning Azure.
  I build cloud solutions.
  I teach DevOps.

The difference matters when YAML is being used to store scripts, documentation, certificates, configuration blocks, or other multiline content.

Anchors, Aliases, and Merge Keys

YAML provides anchors and aliases for reusing configuration without repeatedly defining the same values.

An anchor is created using &:

defaults: &default
  country: Nigeria
  role: Student

The configuration can then be reused using an alias:

student1:
  <<: *default
  name: Raphael

The << merge key incorporates the values from the anchored mapping.

Another object can reuse the same configuration:

student2:
  <<: *default
  name: Sarah

This approach reduces duplication and makes shared configuration easier to maintain.

Multi-Document YAML

A YAML file can contain multiple independent documents.

The document separator is:

---

For example:

student1:
  name: Raphael

---
name: Third Document Stream

The separator marks the beginning of another YAML document.

This becomes important during validation because a file containing multiple documents must be parsed accordingly.

The repository demonstrates this concept in anchors.yaml.

YAML in GitHub Actions

YAML is heavily used in CI/CD systems.

The repository includes a GitHub Actions workflow:

name: Build Project

on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Building project..."

The workflow demonstrates several important GitHub Actions concepts.

Workflow Name

name: Build Project

Defines the workflow's name.

Trigger

on:
  push:

Specifies that the workflow runs when changes are pushed to the repository.

Job

jobs:
  build:

Defines a job named build.

Runner

runs-on: ubuntu-latest

Specifies the GitHub-hosted runner that executes the job.

Steps

steps:
  - uses: actions/checkout@v4
  - run: echo "Building project..."

The first step checks out the repository contents.

The second executes a shell command.

Final Configuration Challenge

The student-profile.yaml configuration combines several YAML concepts into one structured document.

It includes:

Mappings
Nested mappings
Sequences
Strings
Integers
Floating-point numbers
Booleans
Multiline strings
Folded strings
Anchors
Aliases
Merge keys

The shared configuration begins with an anchor:

default_profile: &default
  role: Student
  country: Nigeria
  active: true
  score: 95.5

The configuration is then reused:

user1:
  <<: *default
  name: Sarah

user2:
  <<: *default
  name: David

The file also contains sequences:

skills:
  - Azure
  - Docker
  - Kubernetes

hobbies:
  - Coding
  - Reading

Nested mappings:

address:
  street: 12 Cloud Way
  city: Abuja
  country: Nigeria

And both multiline string styles:

bio_literal: |
  I enjoy learning Azure.
  I build cloud solutions.
  I teach DevOps.

bio_folded: >
  I enjoy learning Azure.
  I build cloud solutions.
  I teach DevOps.

This configuration demonstrates how multiple YAML structures can be combined to represent realistic configuration data.

YAML Validation

Configuration should be validated before being used by automation systems.

This repository uses Python, PyYAML, and Linux command-line tools to validate the YAML files.

Validate All YAML Documents

python3 -c 'import yaml, glob; [list(yaml.safe_load_all(open(f))) for f in glob.glob("*.yaml")]; print("All YAML files valid!")'

This command:

Starts Python 3 using python3.
Uses -c to execute Python code directly from the command line.
Imports the PyYAML library with import yaml.
Imports Python's glob module with import glob.
Uses glob.glob("*.yaml") to find every .yaml file in the current directory.
Uses open(f) to open each YAML file.
Uses yaml.safe_load_all() to parse all YAML documents within each file.
Uses list() to force all documents to be parsed.
Uses a list comprehension to apply the validation to every YAML file.
Uses print() to display a success message after all files are parsed successfully.

The use of safe_load_all() is important because anchors.yaml contains multiple YAML documents separated by ---.

Check for Illegal Tab Characters

YAML indentation should use spaces rather than tabs.

The repository also checks for tab characters:

grep -n $'\t' *.yaml || echo 'No illegal tab characters found!'

Breaking down the command:

Part	Meaning
`grep`	Searches files for a specified pattern.
`-n`	Displays the line number where a match is found.
`$'\t'`	Represents a tab character in Bash.
`*.yaml`	Targets all `.yaml` files in the current directory.
`
{% raw %}`echo`	Prints text to the terminal.

If no tabs are detected, the command prints:

No illegal tab characters found!

These checks provide basic validation for both YAML syntax and indentation consistency.

Git and Repository Management

The project was maintained using Git and published to GitHub.

Git was used to track changes, create commits, maintain the main branch, and synchronize the repository with GitHub.

The final repository includes:

yaml-learning-lab/
├── docs/
│   └── lessons.md
├── screenshots/
├── README.md
├── anchors.yaml
├── lesson1.yaml
├── lesson2.yaml
├── lesson3.yaml
├── lesson4.yaml
├── lesson5.yaml
├── lesson6.yaml
├── lesson7.yaml
├── multiline.yaml
├── student-profile.yaml
└── workflow.yaml

The complete implementation, documentation, YAML files, and supporting evidence are available in the repository:

View the YAML Learning Lab on GitHub

Why YAML Matters in Cloud and DevOps

YAML is more than a configuration format. It is an important component of modern engineering workflows.

The concepts demonstrated in this repository appear in technologies such as:

GitHub Actions
Kubernetes
Docker Compose
Ansible
Azure DevOps
Infrastructure as Code tools
Application configuration systems
Cloud automation platforms

The same fundamental ideas—mappings, sequences, nesting, data types, multiline values, and reusable configuration—appear repeatedly across these technologies.

Understanding YAML therefore makes it easier to read, write, troubleshoot, and maintain configuration-driven systems.

Key Takeaways

The YAML Learning Lab demonstrates how YAML progresses from simple key-value pairs to structured configuration used in real-world DevOps environments.

The repository covers:

YAML syntax and structure
Mappings and nested mappings
Sequences and lists of objects
Data types
Comments and quoted strings
Literal and folded multiline strings
Anchors, aliases, and merge keys
Multi-document YAML streams
GitHub Actions workflow configuration
YAML validation using Python and PyYAML
Git-based project management

The project also demonstrates an important engineering principle:

Configuration should be readable, structured, reusable, and validated before it becomes part of an automation workflow.

Summary

The YAML Learning Lab provides a practical technical reference for YAML and its role in cloud engineering and DevOps.

From basic mappings and sequences to anchors, multiline strings, GitHub Actions, and automated validation, the repository brings together core YAML patterns required for working with configuration-driven tooling.

More importantly, the project demonstrates YAML in context—not simply as a file format, but as a foundational component of modern cloud, DevOps, automation, and CI/CD workflows.

For the complete implementation, configuration files, technical documentation, and supporting evidence:

🔗 YAML Learning Lab — GitHub Repository

Author

Rahimah Sulayman

Cloud & DevOps Engineer | Data Analyst

Dockerfiles: Building and Running a Node.js Application in a Container

Rahimah Sulayman — Wed, 29 Jul 2026 12:02:53 +0000

Introduction

Containers provide a consistent way to package applications together with the dependencies and configuration required to run them.

A Dockerfile defines how that container image is built.

In this project, a Node.js application was containerized using a custom Dockerfile, with the image built, tested, inspected, modified, and rebuilt throughout the implementation.

The project demonstrates how Dockerfile instructions influence the resulting image and, ultimately, the behavior of the running container.

What Is a Dockerfile?

A Dockerfile is a text file containing a sequence of instructions Docker uses to build an image.

A simplified workflow looks like this:

Application Source Code
        │
        ▼
    Dockerfile
        │
        │ docker build
        ▼
   Docker Image
        │
        │ docker run
        ▼
 Docker Container
        │
        ▼
 Running Application

The Dockerfile describes the environment and instructions required to turn application source code into a runnable container image.

Dockerfile vs Docker Image vs Container

These three concepts are closely related but serve different purposes.

Dockerfile

The Dockerfile is the build blueprint.

It defines instructions such as:

FROM
WORKDIR
COPY
RUN
EXPOSE
CMD

Docker Image

The image is the built artifact produced from the Dockerfile.

It contains the application, dependencies, filesystem layers, and configuration required to create a container.

Docker Container

The container is a running instance of an image.

In simple terms:

Dockerfile
    │
    │ docker build
    ▼
Docker Image
    │
    │ docker run
    ▼
Docker Container

Project Overview

The application used for this project is a simple Node.js web application.

The containerized application consists of:

A Node.js application
A server.js entry point
A package.json file
Installed Node.js dependencies
A Dockerfile defining the image build process

The Dockerfile is responsible for packaging these components into a reproducible container image.

Project Structure

Dockerfiles-lab/
├── screenshots/
├── .gitignore
├── Dockerfile
├── package.json
├── package-lock.json
├── README.md
└── server.js

The repository also contains implementation screenshots documenting the different stages of the Dockerfile and container lifecycle.

The complete implementation is available in the GitHub repository linked at the end of this article.

The Node.js Application

Before building the container, there needs to be an application for Docker to package.

The application entry point is:

server.js

A simplified Node.js server can look like:

const http = require("http");

const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("Hello from Docker!");
});

server.listen(3000, () => {
  console.log("Server running on port 3000");
});

The application listens on port 3000.

This gives Docker something concrete to package and run inside the container.

Why `package.json` Matters

The project also contains:

package.json

For Node.js applications, package.json provides project metadata and dependency information.

It can also define scripts used to start or manage the application.

For example:

{
  "scripts": {
    "start": "node server.js"
  }
}

The associated lock file:

package-lock.json

records the resolved dependency versions.

Together, these files make the Node.js application's dependencies and runtime configuration reproducible.

Building the First Docker Image

The first stage of the implementation involved building a Docker image from the Dockerfile.

The basic command is:

docker build -t docker-node-app:1.0 .

The components of the command are:

docker build
     │
     ├── -t docker-node-app:1.0
     │       └── image name and tag
     │
     └── .
         └── current directory as build context

The . tells Docker to use the current directory as the build context.

This makes files in the project directory available to Docker during the build, subject to .dockerignore rules where applicable.

Understanding the Dockerfile

A Dockerfile is processed from top to bottom.

A typical Node.js Dockerfile can contain instructions such as:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

Each instruction has a specific purpose.

`FROM`: Choosing the Base Image

FROM node:20-alpine

FROM specifies the base image from which the new image is built.

For a Node.js application, using a Node.js base image provides the Node.js runtime and supporting environment required to execute the application.

The alpine variant is based on Alpine Linux and is commonly used when a smaller image footprint is desirable.

The base image is therefore the starting point for the container environment.

`WORKDIR`: Setting the Working Directory

WORKDIR /app

WORKDIR establishes the working directory for subsequent Dockerfile instructions.

Instead of placing application files throughout the container filesystem, the application can be organized under:

/app

It also determines the default working directory when the container starts unless another directory is explicitly configured.

`COPY`: Adding Application Files

The application files need to be transferred from the build context into the image.

For example:

COPY package*.json ./

This copies the Node.js package definition files into the working directory.

Later:

COPY . .

copies the remaining application files into the image.

This separation is useful because dependency installation and application source code can be handled as separate build layers.

`RUN`: Installing Dependencies

RUN npm install

RUN executes a command while the image is being built.

Here, npm installs the dependencies defined by the Node.js project.

The resulting files become part of the image layer produced by this instruction.

This is different from CMD.

RUN happens during image build time.

`EXPOSE`: Documenting the Application Port

EXPOSE 3000

The Node.js application listens on port 3000, so the Dockerfile declares:

EXPOSE 3000

It is important to understand that EXPOSE does not publish the port to the host by itself.

It documents the port the application expects to use inside the container.

Host-to-container port publishing is configured when the container is started.

For example:

docker run -d -p 3000:3000 --name docker-node-container docker-node-app:1.0

The mapping is:

Host                  Container
 3000       ───────►    3000

`CMD`: Defining the Default Container Command

One of the most important Dockerfile instructions in this project was:

CMD ["node", "server.js"]

CMD defines the default command executed when a container is started from the image.

In this case, Docker starts:

node server.js

inside the container.

This is what launches the Node.js application.

Why `CMD` Matters

During the implementation, the application command was changed between:

CMD ["node", "server.js"]

and:

CMD ["node", "app.js"]

This demonstrated an important container behavior.

If the file referenced by CMD does not exist in the image, the container cannot successfully start the application.

This can result in a container that starts and immediately exits.

For example, if the Dockerfile contains:

CMD ["node", "app.js"]

but the image does not contain:

/app/app.js

Node.js cannot execute the requested entry point.

This is why examining container logs is an important troubleshooting step.

Building After a Dockerfile Change

A Docker image is a built artifact.

Changing the Dockerfile does not automatically modify an existing image.

After making changes, the image must be rebuilt:

docker build -t docker-node-app:2.0 .

This creates a new image version containing the updated Dockerfile instructions.

The general workflow is:

Modify Dockerfile
       │
       ▼
docker build
       │
       ▼
New Image
       │
       ▼
docker run
       │
       ▼
Test Application

This build-test cycle was repeated during the project to validate changes to the container configuration.

Inspecting Docker Images

After building an image, available images can be inspected with:

docker images

This provides information such as:

Repository
Tag
Image ID
Creation time
Image size

For example:

REPOSITORY       TAG       IMAGE ID       CREATED        SIZE
docker-node-app  1.0       abc123...      ...            ...

Tags such as:

1.0
2.0
final

can be used to distinguish different image versions during development and testing.

Running the Container

Once the image has been built, it can be started with:

docker run -d -p 3000:3000 \
  --name docker-node-container \
  docker-node-app:final

The important options are:

Option	Purpose
`-d`	Runs the container in detached mode
`-p 3000:3000`	Maps host port 3000 to container port 3000
`--name`	Assigns a name to the container
`docker-node-app:final`	Specifies the image to run

The application can then be accessed from the host through:

http://localhost:3000

Verifying a Running Container

After starting the container, its status can be checked with:

docker ps

This displays currently running containers.

Typical information includes:

Container ID
Image
Command
Creation time
Status
Port mappings
Container name

The port mapping should show that host port 3000 is forwarded to port 3000 inside the container.

Testing the Application

Once the container is running, the application can be accessed through a browser:

http://localhost:3000

At this point, the request flow is:

Browser
   │
   │ localhost:3000
   ▼
Host Port 3000
   │
   │ Docker port mapping
   ▼
Container Port 3000
   │
   ▼
Node.js
   │
   ▼
server.js
   │
   ▼
HTTP Response

This demonstrates the relationship between the host, container networking, and the application process.

Troubleshooting a Failed Container

Not every container starts successfully on the first attempt.

During the implementation, an invalid application entry point was used to demonstrate container troubleshooting.

A failed run can be identified using:

docker ps -a

Unlike docker ps, the -a option also displays stopped containers.

This is particularly useful when a container starts and then exits immediately.

Using Docker Logs for Troubleshooting

When a container fails, logs are often the fastest way to determine why.

The logs can be viewed with:

docker logs docker-node-container

For example, if the Dockerfile attempts to execute a file that does not exist:

CMD ["node", "app.js"]

Node.js may report that it cannot find the specified module.

The important troubleshooting pattern is:

Container exits
      │
      ▼
docker ps -a
      │
      ▼
Identify exited container
      │
      ▼
docker logs <container>
      │
      ▼
Identify application/configuration error
      │
      ▼
Fix Dockerfile or application
      │
      ▼
Rebuild image
      │
      ▼
Run container again

This workflow is useful well beyond simple Docker labs.

Stopping and Removing a Container

Once a container is no longer needed, it can be stopped and removed with:

docker stop docker-node-container && docker rm docker-node-container

The first command:

docker stop docker-node-container

stops the running container.

The second:

docker rm docker-node-container

removes the stopped container.

The && operator ensures the second command runs only if the first command succeeds.

Rebuilding and Retesting

After correcting the Dockerfile, the image was rebuilt and the container started again.

A typical sequence is:

docker build -t docker-node-app:final .

followed by:

docker run -d -p 3000:3000 \
  --name docker-node-container \
  docker-node-app:final

Then:

docker ps

and finally:

http://localhost:3000

can be used to verify the result.

This build → run → inspect → troubleshoot → rebuild cycle is fundamental to working effectively with Dockerfiles.

Changing Application Output

The application response was also modified during testing.

For example:

res.end("Welcome to my Docker Node.js application!");

After changing application source code, the image must be rebuilt if the source code is copied into the image during the build:

docker build -t docker-node-app:final .

The updated image then needs to be used when starting a new container.

This demonstrates an important principle:

A running container does not automatically become a new image when the source code or Dockerfile changes.

The image must be rebuilt when the application contents packaged into it need to change.

Docker Build Cache

Docker builds are made up of layers.

For example:

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

Each instruction can contribute to the image's layer structure.

Docker can reuse unchanged layers during subsequent builds, which can significantly improve build performance.

This is one reason Dockerfiles are commonly structured to copy dependency definition files before copying the rest of the application source:

COPY package*.json ./
RUN npm install

COPY . .

If only application source code changes, Docker may be able to reuse the dependency installation layer.

Dockerfile Best Practices

A production-oriented Dockerfile should be designed with efficiency, security, and reproducibility in mind.

1. Use an appropriate base image

Choose a maintained base image that provides only what the application needs.

For example:

FROM node:20-alpine

A smaller base image can reduce the image footprint and attack surface, although compatibility should always be considered.

2. Keep the image focused

Only copy files required by the application.

A .dockerignore file can prevent unnecessary files from being included in the build context.

Example:

node_modules
.git
.env
npm-debug.log

3. Take advantage of layer caching

Copy dependency files before application source code:

COPY package*.json ./
RUN npm install

COPY . .

This can prevent unnecessary dependency reinstallation when only source files change.

4. Avoid embedding secrets

Do not place passwords, API keys, tokens, or other sensitive values directly into a Dockerfile.

Use appropriate runtime configuration and secrets-management mechanisms instead.

5. Run as a non-root user

Where appropriate, configure the container to run the application as a non-root user.

This reduces the impact of a potential application compromise.

6. Use explicit image tags

Rather than relying blindly on:

FROM node:latest

consider using an explicit version:

FROM node:20-alpine

This makes builds more predictable and reproducible.

Dockerfile Instructions at a Glance

Instruction	Purpose
`FROM`	Defines the base image
`WORKDIR`	Sets the working directory
`COPY`	Copies files into the image
`RUN`	Executes commands during image build
`EXPOSE`	Documents a container port
`CMD`	Defines the default runtime command

A useful distinction is:

RUN
└── Build time

CMD
└── Container runtime

Understanding this difference is essential when diagnosing why a container behaves differently from the image build process.

Dockerfile Workflow

The complete workflow demonstrated in this project can be summarized as:

Application Source
       │
       ▼
   Dockerfile
       │
       │ docker build
       ▼
   Docker Image
       │
       │ docker images
       ▼
   Image Inspection
       │
       │ docker run
       ▼
 Docker Container
       │
       ├── docker ps
       │
       ├── Browser Test
       │
       └── docker logs
               │
               ▼
          Troubleshooting
               │
               ▼
        Modify Application
               │
               ▼
          Rebuild Image
               │
               ▼
        Run & Test Again

This workflow provides a repeatable approach to packaging and validating containerized applications.

Dockerfile vs Docker Compose

Dockerfiles and Docker Compose solve different problems, but they complement each other.

Dockerfile	Docker Compose
Defines how an image is built	Defines how multiple services run together
Creates a custom image	Orchestrates application services
Focuses on image construction	Focuses on service configuration
Uses Dockerfile instructions	Uses YAML configuration
`docker build`	`docker compose up`
`docker run` starts the resulting image	Compose manages the defined application stack

A Dockerfile might create the image for an application:

Dockerfile
     │
     ▼
Application Image

Docker Compose can then use that image as part of a larger application:

                Docker Compose
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
    Application             Database
     Container              Container

Understanding both technologies provides a stronger foundation for building and operating containerized applications.

Key Docker Commands

The primary commands used throughout the project include:

Build an image

docker build -t docker-node-app:final .

List images

docker images

Run a container

docker run -d -p 3000:3000 \
  --name docker-node-container \
  docker-node-app:final

List running containers

docker ps

List all containers

docker ps -a

View container logs

docker logs docker-node-container

Stop and remove a container

docker stop docker-node-container && docker rm docker-node-container

Skills Demonstrated

This implementation demonstrates practical experience with:

Dockerfile authoring
Docker image creation
Docker image tagging
Docker build context
Docker build layers and caching
Node.js containerization
Base image selection
Working directory configuration
Application file management with COPY
Dependency installation with RUN
Container port configuration
Runtime commands with CMD
Docker container lifecycle management
Port mapping
Container inspection
Container log analysis
Troubleshooting failed containers
Image rebuild and validation workflows
Linux command-line operations
Git and GitHub
Technical documentation

Conclusion

A Dockerfile provides the foundation for turning application source code into a portable, reproducible container image.

By defining the base runtime, working directory, application files, dependencies, exposed port, and startup command, the Dockerfile establishes how the application is packaged and executed.

The implementation also demonstrates that containerization is more than simply building an image. A reliable workflow includes:

Build
  ↓
Run
  ↓
Inspect
  ↓
Test
  ↓
Troubleshoot
  ↓
Rebuild
  ↓
Validate

These concepts form a practical foundation for container-based application development and provide the building blocks for more advanced workflows involving Docker Compose, CI/CD pipelines, container registries, orchestration platforms, and cloud-native deployments.

Project Repository

The complete implementation, Dockerfile iterations, application files, and supporting screenshots are available on GitHub:

https://github.com/rahimahisah17/dockerfiles-lab

The repository provides the complete implementation and evidence of the build, run, troubleshooting, and validation process documented in this article.

Related Work

This Dockerfile implementation pairs naturally with a multi-container deployment workflow using Docker Compose.

Docker Compose can be used to take individually containerized applications and combine them with supporting services such as databases, caches, and other dependencies into a complete application stack.

DEV Community: Rahimah Sulayman

Azure Container Apps Guided Project (AZ-2026), Part 5: Traffic Splitting and Revision Management

Introduction

Set revision management to multiple

Configure a traffic percentage and labels on the revisions

Check your work

Summary

Skills practiced:

Azure Container Apps Guided Project (AZ-2026), Part 4: CI/CD with Azure Pipelines and a Self-Hosted Agent

Introduction

Configure Pipeline1 to use the self-hosted agent pool

Configure Pipeline1 with an Azure Container Apps deployment task

Run the Pipeline1 deployment task

Check your work

Summary

Skills practiced:

Part 3: Deploying a Container App with Managed Identity, Service Bus, and HTTP Scaling

Introduction

Create a container app that uses an ACR image

Configure the container app to authenticate using the user assigned identity

Configure a connection between the container app and Service Bus

Configure HTTP scale rules

Check your work

Summary

Skills practiced:

Part 2: Securing Azure Container Registry with Managed Identity and Private Endpoints

Introduction

Complete the following steps to configure a user-assigned managed identity.

Configure Container Registry with AcrPull permissions for the managed identity

Configure Container Registry with a private endpoint connection

Check your work

Summary

Skills practiced: Azure Container Registry, Managed Identity, Azure RBAC, Private Endpoints, Private DNS, Least Privilege, Cloud Networking.

Getting Started with Azure Container Apps. Part 1: Setting Up Your Deployment Tools and Resources

Introduction

Prepare your app deployment tools and resources

Project overview

Setup

Install Docker Desktop

Install the .NET Software Development Kit

Install Visual Studio Code with Docker and Azure App Service extensions

Install Azure CLI and the containerapp extension

Install Microsoft PowerShell

Configure a Resource Group for your Azure resources

Configure a Virtual Network and subnets

Configure Service Bus

Configure Azure Container Registry

Create a WebAPI app and publish to a GitHub repository

Create Docker image and push to Azure Container Registry

Configure Azure DevOps and a starter Pipeline

Deploy a self-hosted Windows agent

Summary

Skills practiced so far:

Promoting a Member Server to Domain Controller, Transferring FSMO Roles, and Configuring Active Directory Sites

Introduction

Install Active Directory Domain Services (AD DS) and promote to Domain Controller

Transfer Flexible Single Master Operations Roles

Create an Active Directory site and configure a subnet for that site

Summary

Strengthening Active Directory Security with NTLM Restrictions, Auditing, and Logon Controls

Introduction

Overview

Restrict NTLM Authentication

Audit User Account Management in Sydney

Deny Log On As a Service

Conclusion

Securing Active Directory with Password Policies and Recycle Bin

Introduction

Overview

Configure Domain Password Policy

Configure Fine-Grained Password Policy

Enable Active Directory Recycle Bin

Project Summary

Administering Active Directory Users, Groups, and Organizational Units

Introduction

Overview

Create Organizational Units

Create users

Create the Sydney Admins group

Configure a user as a Protected User

Configure `Pipeline1` to use the self-hosted agent pool

Install Azure CLI and the `containerapp` extension

Why `package.json` Matters

`FROM`: Choosing the Base Image

`WORKDIR`: Setting the Working Directory

`COPY`: Adding Application Files

`RUN`: Installing Dependencies

`EXPOSE`: Documenting the Application Port

`CMD`: Defining the Default Container Command

Why `CMD` Matters