DEV Community: Rahimah Sulayman

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.

Docker Compose: Running WordPress and MySQL as a Multi-Container Application

Rahimah Sulayman — Wed, 29 Jul 2026 11:30:19 +0000

Introduction

Managing containers individually with docker run works well for simple applications, but once an application depends on multiple services, managing each container separately quickly becomes inefficient.

A typical WordPress deployment, for example, requires more than the WordPress application itself. It also needs a database service, networking between the services, configuration, and persistent storage.

This is where Docker Compose becomes useful.

In this project, I configured a multi-container WordPress environment using Docker Compose, with WordPress and MySQL defined as separate services and managed through a single compose.yml file.

What is Docker Compose?

Docker Compose is a tool for defining and managing multi-container applications using a YAML configuration file.

Instead of manually creating and configuring each container with multiple docker run commands, the required services and their configuration can be declared in one file.

For this project, the architecture is:

                    Docker Compose
                          │
              ┌───────────┴───────────┐
              │                       │
              ▼                       ▼
        WordPress Service       MySQL Service
        wordpress:latest          mysql:8.0
              │                       │
              └─────── Network ───────┘
                         │
                  Persistent Volumes
                   ┌─────┴─────┐
                   ▼           ▼
                wp_data     db_data

The two services work together:

WordPress provides the web application.
MySQL provides the database.
Docker Compose networking allows WordPress to communicate with MySQL.
Named volumes provide persistent storage.

Project Architecture

The environment consists of two services:

Service	Image	Purpose
`wordpress`	`wordpress:latest`	Web application
`db`	`mysql:8.0`	Database

The WordPress container exposes port 80 internally, which is mapped to port 8080 on the host.

The MySQL service is not exposed directly to the host because WordPress communicates with it through the internal Docker network.

Project Structure

my-wordpress-site/
├── screenshots/
├── compose.yml
└── README.md

The core configuration is contained in:

compose.yml

Creating the Project Workspace

The project begins with a dedicated directory:

mkdir my-wordpress-site
cd my-wordpress-site

This keeps the Compose configuration and project documentation organized in a single workspace.

Defining the Docker Compose Configuration

The environment is defined in compose.yml.

The file contains two services:

services:
  db:
    image: mysql:8.0

  wordpress:
    image: wordpress:latest

The services section is the foundation of the Compose configuration. Each service represents a containerized component of the application.

The complete configuration defines:

Container images
Environment variables
Service dependencies
Port mapping
Persistent volumes
Service-to-service communication

Inspecting `compose.yml`

Before starting the application, the Compose configuration can be inspected directly from the terminal:

cat compose.yml

Configuring the MySQL Service

The database service is defined as:

db:
  image: mysql:8.0
  restart: always
  environment:
    MYSQL_ROOT_PASSWORD: supersecretpassword
    MYSQL_DATABASE: wordpress
    MYSQL_USER: wordpressuser
    MYSQL_PASSWORD: wordpresspassword
  volumes:
    - db_data:/var/lib/mysql

Image

image: mysql:8.0

Docker Compose uses the official MySQL 8.0 image rather than building a custom database image.

Restart Policy

restart: always

This instructs Docker to automatically restart the container when appropriate.

Environment Variables

The database configuration is supplied through environment variables:

MYSQL_ROOT_PASSWORD: supersecretpassword
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpressuser
MYSQL_PASSWORD: wordpresspassword

These variables configure the initial MySQL database, user, and credentials.

Production note: Credentials should not be committed directly into a public repository. In production environments, use environment files, Docker secrets, or an appropriate secrets-management solution.

Persistent Database Storage

volumes:
  - db_data:/var/lib/mysql

The named volume db_data is mounted to MySQL's data directory.

This allows database data to persist independently of the container lifecycle.

Configuring the WordPress Service

The WordPress service is defined as:

wordpress:
  depends_on:
    - db
  image: wordpress:latest
  ports:
    - "8080:80"
  restart: always
  environment:
    WORDPRESS_DB_HOST: db:3306
    WORDPRESS_DB_USER: wordpressuser
    WORDPRESS_DB_PASSWORD: wordpresspassword
    WORDPRESS_DB_NAME: wordpress
  volumes:
    - wp_data:/var/www/html

Image

image: wordpress:latest

The official WordPress image is used as the application container.

Port Mapping

ports:
  - "8080:80"

This maps:

Host port 8080 → Container port 80

This allows the WordPress application to be accessed through port 8080 on the host.

Database Connection

The WordPress container is configured to connect to MySQL using:

WORDPRESS_DB_HOST: db:3306

This is an important Docker Compose concept.

db is not a hostname from the host machine. It is the service name defined in the Compose file.

Docker Compose creates a network for the application, allowing services to communicate with each other using their service names.

The connection therefore looks like:

WordPress
    │
    │ db:3306
    ▼
MySQL

Service Dependency

depends_on:
  - db

This establishes a dependency relationship between WordPress and the database service.

WordPress Persistent Storage

volumes:
  - wp_data:/var/www/html

The wp_data named volume stores WordPress application data outside the container's writable layer.

Starting the Multi-Container Application

Once the Compose configuration is ready, the complete environment can be started with:

docker compose up -d

The up command creates and starts the services defined in compose.yml.

The -d option starts them in detached mode, allowing the terminal to remain available while the containers run in the background.

docker compose
       │
       └── up
            │
            └── -d
                 │
                 ├── MySQL container
                 └── WordPress container

Verifying the Services

After starting the environment, the service status can be checked with:

docker compose ps

This provides a quick overview of the containers managed by the Compose project.

It can be used to verify:

Service names
Container status
Ports
Running state

Inspecting Container Logs

Logs are essential when troubleshooting containerized applications.

Docker Compose provides a convenient way to inspect logs from all services:

docker compose logs --tail 20

The --tail 20 option limits the output to the most recent 20 log lines.

This is useful for identifying:

Startup issues
Configuration problems
Database connection errors
Application errors
Service initialization messages

Managing Persistent Volumes

The Compose configuration defines two named volumes:

volumes:
  db_data:
  wp_data:

These are mounted into the respective services:

db_data
   │
   └── /var/lib/mysql

wp_data
   │
   └── /var/www/html

Named volumes are useful because container storage is otherwise tied to the container's lifecycle.

For a database-backed application, separating persistent data from the container itself is particularly important.

Cleaning Up the Environment

Once the deployment has been verified, the entire Compose environment can be removed with:

docker compose down -v

The down command stops and removes the containers and the Compose network.

The -v option additionally removes the named volumes created by the project.

In this lab, that means:

WordPress container   → removed
MySQL container       → removed
Compose network       → removed
wp_data volume        → removed
db_data volume        → removed

Warning: docker compose down -v removes the project's named volumes and therefore deletes the persistent data stored in them. Use this carefully when working with real application data.

Verifying the Cleanup

The cleanup can be verified using:

docker compose ps
docker ps -a
docker volume ls

The verification confirms that the project's containers and named volumes have been removed.

Docker Compose vs. Individual `docker run` Commands

Without Compose, running this type of environment manually would require separate commands for the database and WordPress containers, along with their networking, environment variables, volumes, and port configuration.

Docker Compose consolidates those requirements into a single declarative configuration.

Manual Docker	Docker Compose
Multiple `docker run` commands	One `compose.yml`
Configuration spread across commands	Configuration centralized in YAML
Manual container relationships	Services defined together
Manual volume configuration	Named volumes declared in Compose
Multiple commands to start services	`docker compose up -d`
Individual cleanup commands	`docker compose down`

This becomes increasingly valuable as application architectures grow.

Key Docker Compose Commands

The main commands used in this project were:

Start services

docker compose up -d

Check service status

docker compose ps

Inspect logs

docker compose logs --tail 20

Stop and remove services

docker compose down -v

Skills Demonstrated

This project demonstrates practical experience with:

Docker Compose
Multi-container application architecture
YAML configuration
WordPress containerization
MySQL containerization
Docker networking and service discovery
Docker named volumes
Persistent application storage
Environment-based service configuration
Container lifecycle management
Container log inspection
Docker CLI
Linux command-line operations
Technical documentation
Git and GitHub project management

Conclusion

Docker Compose provides a practical way to define, configure, and manage applications composed of multiple containers.

By defining WordPress and MySQL as services in a single compose.yml, the application environment becomes easier to deploy, inspect, manage, and remove.

The key concepts demonstrated in this implementation include:

Declarative multi-container configuration
Service-to-service communication
Docker Compose networking
Persistent volumes
Environment variables
Container lifecycle management
Log-based troubleshooting

The same principles can be extended to more complex architectures involving application servers, databases, caches, message brokers, reverse proxies, and other supporting services.

Project Repository

The complete project, including the compose.yml configuration and implementation screenshots, is available on GitHub:

https://github.com/rahimahisah17/my-wordpress-site

Building a Production-Style Azure Infrastructure with Azure CLI: Lessons from a Real Deployment

Rahimah Sulayman — Tue, 21 Jul 2026 11:11:27 +0000

How I deployed Linux and Windows virtual machines, configured networking, secured public access, and troubleshot real Azure deployment issues using only Azure CLI.

Introduction

One of the best ways to learn cloud engineering is to build infrastructure the same way it is deployed in real environments.

Instead of clicking through the Azure Portal, I challenged myself to provision an entire production-style environment using Azure CLI. The objective wasn't simply to deploy virtual machines: it was to understand the deployment process, solve real-world problems, validate every resource, and document the entire journey.

The final environment included:

Ubuntu Server running Nginx
Windows Server running IIS
Windows 11 client VM
Shared Virtual Network
Network Security Groups
Public connectivity validation
Complete cleanup after deployment

More importantly, the project involved several real Azure deployment challenges that required investigation and troubleshooting before the infrastructure was fully operational.

Project Objectives

The goals of this lab were to:

Provision Azure infrastructure entirely with Azure CLI
Deploy Linux and Windows virtual machines
Configure virtual networking
Deploy a Windows 11 client VM
Install and configure Nginx
Install and configure IIS
Configure Network Security Groups
Validate public connectivity
Practice troubleshooting real Azure deployment issues
Document the entire implementation

Architecture

The deployed environment consisted of:

Azure Resource Group
Virtual Network
Shared Subnet
Ubuntu Server VM
Windows Server VM
Windows 11 Client VM
Network Security Groups
Nginx Web Server
IIS Web Server

Although this is a learning project, the overall deployment closely resembles the structure used in many production Azure environments.

Infrastructure Deployed

Resource	Name
Resource Group	rg-globalretail-prod-001
Region	West Europe
Ubuntu VM	vm-linux-web-01
Windows Server VM	vm-win-admin01
Windows 11 VM	vm-win11-ha
Virtual Network	vm-linux-web-01VNET
Subnet	vm-linux-web-01Subnet

Deployment Process

Step 1 — Creating the Resource Group

Everything began by creating a dedicated Resource Group to logically organize every Azure resource used throughout the project.

This became the container for all virtual machines, networking resources, storage, and security components.

Resource Group Created

Step 2 — Deploying the Ubuntu Server

The first virtual machine deployed was an Ubuntu Server running Ubuntu 22.04 LTS.

This server would later host the Nginx web server.

Deployment was completed using Azure CLI without touching the Azure Portal.

Linux VM Created

Step 3 — Deploying Windows Server

Next came the Windows Server virtual machine.

This VM would later host Internet Information Services (IIS).

The deployment wasn't completely smooth, however...

Real-World Troubleshooting

One thing I appreciated about this project was that it wasn't a perfect "follow-the-lab" experience.

Several real deployment issues occurred along the way.

Windows Computer Name Limitation

The initial deployment failed because the Windows computer name exceeded Microsoft's 15-character limit.

After shortening the VM name, deployment continued successfully.

Azure CLI Returned `ResourceNotFound`

Immediately after deployment, Azure CLI displayed a ResourceNotFound error for the Windows VM.

Instead of assuming the deployment had failed, I verified the environment using:

az vm list --resource-group rg-globalretail-prod-001 --output table

The VM had actually been created successfully.

This reinforced an important lesson:

Always verify the actual Azure resource state instead of relying solely on CLI output.

Windows 11 Deployment Failed

The Windows 11 deployment initially failed because Azure attempted to create a subnet that conflicted with the existing virtual network.

The solution was to query the existing subnet and explicitly specify it during deployment.

SSH Authentication Failed

Connecting to Ubuntu initially produced:

Permission denied (publickey)

After investigating, I discovered the local machine did not contain an SSH key pair.

Generating a new RSA key pair resolved the issue immediately.

Configuring the Servers

With the infrastructure successfully deployed, the next phase involved configuring the workloads.

Ubuntu

After connecting through SSH:

Updated package repositories
Installed Nginx
Verified the service was running

sudo apt update
sudo apt install nginx -y
sudo systemctl status nginx

Windows Server

After connecting through Remote Desktop:

Opened PowerShell
Installed IIS

Install-WindowsFeature -Name Web-Server -IncludeManagementTools

Network Security

Neither web server was initially reachable.

The reason?

HTTP traffic wasn't allowed through the Network Security Groups.

After creating inbound TCP port 80 rules for both virtual machines, browser access worked immediately.

This served as a good reminder that:

Infrastructure deployment is only one part of cloud engineering.

Networking and security configuration are equally important.

Validation

The environment was validated by confirming that:

SSH access worked correctly
Remote Desktop access worked correctly
Nginx was running
IIS was installed successfully
HTTP traffic was permitted
Both web servers were accessible from a web browser

Browser showing Nginx or IIS page

What I Learned

This project reinforced several important Azure concepts:

Azure regions don't always have capacity for every VM size.
Windows virtual machines have naming constraints.
Existing VNets and subnets should be reused explicitly.
SSH authentication requires both server-side and client-side configuration.
Azure CLI responses should always be validated.
Network Security Groups are critical for application accessibility.
Cleaning up cloud resources prevents unnecessary costs.

Most importantly...

Cloud engineering isn't simply deploying resources.

It's understanding how infrastructure, networking, security, authentication, and troubleshooting all work together.

Source Code

The complete project — including Azure CLI commands, deployment documentation, troubleshooting notes, and screenshots is available on GitHub:

👉 https://github.com/rahimahisah17/globalretail-prod-lab

Final Thoughts

This project pushed me beyond simply following documentation.

It required investigating deployment failures, validating Azure resources, solving networking issues, configuring Linux and Windows servers, and documenting every stage of the deployment process.

Every challenge became an opportunity to better understand how Azure behaves in real-world scenarios.

I'm looking forward to building even more production - style cloud infrastructure projects as I continue developing my Azure and cloud engineering skills.

Thanks for reading! If you have suggestions, questions, or similar experiences deploying infrastructure with Azure CLI, I'd love to hear about them.

azure #azurecli #cloud #cloudcomputing #devops #linux #windowsserver #nginx #iis #networking #cloudengineering

From Feature Branch to Container Registry: Building a Complete CI/CD Pipeline with Docker and GitHub Actions

Rahimah Sulayman — Fri, 17 Jul 2026 21:17:41 +0000

Building a Complete CI/CD Pipeline with Docker and GitHub Actions

Modern software delivery is about much more than writing code. Successful engineering teams rely on automation, collaboration, repeatable workflows, and reliable delivery pipelines to move software from development to deployment.

To strengthen my DevOps skills, I built a production-inspired CI/CD project that simulates the workflow used by modern engineering teams.

Rather than focusing on building a complex application, I focused on building a professional software delivery pipeline—from planning and development to automated container image publishing.

This project demonstrates:

Git workflow
Feature branch development
Pull Requests
Docker containerization
GitHub Actions automation
Continuous Integration (CI)
Continuous Delivery (CD)
GitHub Container Registry (GHCR)

Note: This article has been updated to include Continuous Delivery with GitHub Container Registry (GHCR), along with improvements made after the initial publication.

The complete project is available on GitHub:

👉 GitHub Repository

https://github.com/rahimahisah17/cloud-devops-ci-cd-lab

Project Objectives

The objective was to simulate a realistic DevOps workflow that mirrors how software is developed, reviewed, automated, and delivered in production environments.

The completed project includes:

GitHub Issues for task tracking
Feature branch development
Pull Request-based collaboration
Docker containerization
GitHub Actions automation
Continuous Integration
Continuous Delivery
GitHub Container Registry (GHCR)
Comprehensive project documentation

Technology Stack

Git
GitHub
GitHub Actions
Docker
GitHub Container Registry (GHCR)
Nginx
Linux (WSL)
Visual Studio Code

Development Workflow

Every feature followed a structured Git workflow before reaching the main branch.

GitHub Issue
      │
      ▼
Feature Branch
      │
      ▼
Development
      │
      ▼
Commit
      │
      ▼
Push
      │
      ▼
Pull Request
      │
      ▼
GitHub Actions
      │
      ▼
Build Docker Image
      │
      ▼
Publish to GHCR
      │
      ▼
Continuous Delivery

CI/CD Architecture

👩‍💻 Developer
│
▼
📁 GitHub Repository
│
▼
🌿 Feature Branch
│
▼
🔀 Pull Request
│
▼
⚙️ GitHub Actions
│
├── Repository Validation
├── Docker Build
└── Push to GHCR
│
▼
📦 GitHub Container Registry
│
▼
🚀 Deployable Container Image

Continuous Delivery with GitHub Container Registry

The project initially implemented Continuous Integration by automatically validating the repository and building the Docker image.

To extend the workflow into Continuous Delivery, I enhanced the GitHub Actions pipeline to:

Authenticate with GitHub Container Registry (GHCR)
Tag Docker images using the GitHub Container Registry naming convention
Automatically publish Docker images after successful workflow execution

Every successful pipeline execution now produces a deployable Docker image stored in GitHub Container Registry, making the workflow suitable for downstream deployment environments.

Containerizing the Application

The application is packaged inside a lightweight Docker container using Nginx.

FROM nginx:alpine

COPY index.html /usr/share/nginx/html/index.html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

Containerization ensures the application behaves consistently regardless of where it runs.

Automating CI/CD with GitHub Actions

Every push and pull request automatically triggers GitHub Actions.

The workflow performs the following tasks:

Validates the repository
Builds the Docker image
Authenticates with GitHub Container Registry
Publishes the Docker image to GHCR

This eliminates manual build steps while ensuring every change follows the same automated delivery process.

Debugging the Pipeline

One of the most valuable aspects of this project wasn't creating the workflow—it was troubleshooting it.

After migrating the application from Python to an Nginx-based static website, the CI pipeline failed because it was still validating a Python file that no longer existed.

Instead of simply rerunning the workflow, I:

Investigated the workflow logs
Identified the obsolete validation step
Updated the workflow
Verified the fix by rerunning the pipeline

Watching the workflow transition from ❌ failed to ✅ successful reinforced an important DevOps lesson:

CI/CD pipelines evolve alongside the applications they support.

Lessons Learned

This project strengthened my practical understanding of:

Git workflows
Feature branch development
Pull Requests
Docker containerization
GitHub Actions
Continuous Integration
Continuous Delivery
GitHub Container Registry (GHCR)
Pipeline troubleshooting
Technical documentation

More importantly, it demonstrated that successful DevOps projects are built through continuous improvement, testing, and iteration.

Explore the Complete Project

The repository has continued to evolve beyond the initial publication of this article.

It now includes:

📘 Professional README
📝 Detailed implementation log
📸 Step-by-step screenshots
🐳 Dockerized Nginx application
⚙️ GitHub Actions CI/CD workflow
🚀 Continuous Delivery to GitHub Container Registry
🏷️ Official v1.0.0 release
📄 MIT License

Final Thoughts

What began as a simple Docker containerization exercise gradually evolved into a complete CI/CD implementation using GitHub Actions and GitHub Container Registry.

Beyond the technical outcome, this project strengthened my understanding of Git workflows, automation, pipeline troubleshooting, Docker, and technical documentation.

More importantly, it reinforced that DevOps is not just about writing automation scripts—it's about designing reliable, repeatable engineering processes that enable teams to deliver software with confidence.

I hope this walkthrough helps anyone learning DevOps by showing what an end-to-end project looks like in practice.

Thank you for reading!

Happy learning! 🚀

If you found this project helpful, feel free to ⭐ the repository, share your thoughts, or connect with me here on Dev.to. Feedback and suggestions are always welcome!

Strengthening Identity Security with Conditional Access Policies in Microsoft Entra ID

Rahimah Sulayman — Thu, 09 Jul 2026 14:49:43 +0000

Introduction

As organizations embrace cloud-first environments, protecting user identities requires more than just strong passwords. Conditional Access in Microsoft Entra ID enables administrators to make intelligent access decisions based on user identity, device compliance, location, application, and risk, ensuring that only trusted users can access organizational resources under the right conditions.

In this hands-on guide, I'll walk through creating and configuring a Conditional Access policy, targeting specific users and cloud applications, enforcing access controls, and using the What If tool to validate policy behavior before deployment. These practical exercises demonstrate how Conditional Access helps organizations implement Zero Trust principles while minimizing the risk of misconfigured security policies.

Exercise - Perform basic Conditional Access policy tasks

In this exercise you will learn to create and configure a Conditional Access policy and test its results with the What If analysis tool.

This exercise should take approximately 10 minutes to complete.

Task 1 - Review a Conditional Access policy

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, select Conditional access submenu.

4.Review the information provided on the Conditional Access Overview page.

Note - You can see how many policies you have enabled, and how many users who have logged in recently that are not covered by a policy, along with other details(if you created any).
5.Select the + Create new policy from the top menu.

6.In the Name box enter Block Bhogeswar from using Sway.

7.In the Assignments section select 0 users and agents selected text.

In the Include section mark the Select users and groups item.
Put a mark in the Users and groups box.

When the list of users and groups opens, select Bhogeswar Kalita from the list.
Use the Select button to add the user.

Select the word Exclude to switch tabs.
Put a mark in the Users and groups box.
When the list of users and groups opens, select the admin user you are using from the list.
Use the Select button to exclude this user.

Lab tip - We have added a user for this policy and we have added an exclude for our admin, to make sure they are not accidentally locked out by a policy change.

8.Find the section Target resources section.

9.Select the No target resources selected text from this section.

Make sure Resources (formerly cloud apps) is chosen in the dropdown.
Put a mark in the Select resources item.
In the section titled Select choose the word None.
When the resource selection dialog opens, enter Sway into the search bar.
Put a check in the box next to Sway then use the Select button to approve the choice.

Lab tip - We have chosen the app Sway to be the resource this policy works on. You could choose multiple apps, or you could even choose to exclude apps.

Notice the name and target resource.

10.Open and review the Network section, but we are not going to use that for this lab.

11.Open and review the Conditions section, but we are not using it for this lab.

Lab tip - Network and Conditions are powerful options in the Conditional Access policy, but they are not required for this simple policy to block access to an app. You would use them if you wanted to do things like restrict access for user working from a specific location, or block access if a user has shown risky behavior. There are many granular options that you can choose from, or even combine together.

12.Find the section titled Access controls.
13.Under the word Grant select the text 0 controls selected.
14.When the Grant dialog opens, select the Block access item.

15.Use the Select button to accept the change.

Lab tip - You have not set the values needed to create a simple block access policy to the Sway app for Bhogeswar. In the Access controls section, we could have allowed access with specific conditions like MFA or a domain joined device.
16.At the bottom of the Conditional Access interface, find the Enable policy item.
17.Set the value to On.

18.Select the Create button.

Lab tip - You have three options to pick from, and you can change value at any time, without having to change the policy.

On = enables the policy to run
Off = turn the policy off in case you need to modify it.
Report-only = use this option to review the outcome of the policy before you fully turn it on.

Task 2 - Perform a What If analysis for a conditional access policy

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, select Conditional access submenu.
4.From the Conditional access screen select the What if option from the top menu.

5.In the section User or Workload identity select the text No user or service principal selected.
6.Make sure the box next to User is marked.
7.Select the text No user selected or Edit user.
8.From the Users list, put a mark next to Bhogeswar Kalita, then use the Select button.

9.In the Cloud apps, actions, or authentication context, select the text Any cloud app.
10.When the Select target type dialog opens, confirm that Cloud apps is chosen in the dropdown.
11.Click on the + Select cloud app.
12.Use the search to find the Sway app, then use the Select botton to finalize.

13.Scroll down to the bottom of the What If tool.

14.Select the button What If.

Note - the results appear off the bottom of the screen, so you will need to scroll down again.
15.You should see the Block Bhogeswar from using Sway policy listed, and it is blocking access.

16.You have to make selections for Device platform and Client app under sign-in conditions.

Subtask 1 - Try a different app in the What If analysis

1.Scroll back to the top of the What If tool.
2.In the Cloud apps, actions, or authentication context, select delete next to Sway and remove it..

3.Then select select cloud app to pick a new app.
4.Search for Office 365 Reports and choose it from the list, then use the Select button.

5.Scroll down to the bottom again.
6.Select the What If button.
7.You should see that the Block Bhoseswar from using Sway policy did not apply.

Summary

In this article, I demonstrated how to create and configure Conditional Access policies in Microsoft Entra ID, assign policies to specific users and cloud applications, define access controls, and validate policy behavior using the What If analysis tool. By testing policies before enforcement, administrators can confidently implement secure access controls, reduce the risk of unintended user lockouts, and strengthen their organization's identity security posture through a Zero Trust approach.

Securing User Identities with Multi-Factor Authentication (MFA) in Microsoft Entra ID

Rahimah Sulayman — Wed, 08 Jul 2026 21:54:23 +0000

Introduction

Passwords alone are no longer enough to protect user accounts from today's evolving cyber threats. Multi-Factor Authentication (MFA) adds an essential layer of security by requiring users to verify their identity using multiple authentication factors, significantly reducing the risk of unauthorized access caused by compromised credentials.

In this hands-on guide, I'll walk through configuring Multi-Factor Authentication in Microsoft Entra ID, including enabling and disabling per-user MFA, reviewing MFA service settings, and configuring account lockout policies. These practical exercises demonstrate how to strengthen identity security while balancing usability and administrative control in a modern cloud environment.

Exercise - Perform basic Multifactor Authentication tasks

In this exercise you will explore the MFA setup process and configure a basic MFA deployment.

This exercise should take approximately 10 minutes to complete.

Task 1 - Enable / Disable Per-user MFA settings

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, open the Identity submenu
4.Select Users and then select All users.
5.Look at the menu on the top of the new screen and find Per-user MFA.
6.Select Per-user MFA.

7.Put a mark in the box next to Bhogeswar Kalita.

8.Select Enable MFA from the top of the list.

9.Read the message box that pops up.

Note - This is a manual URL that you can email to the user, if you want to let them know to set up MFA.

10.Select Enable button.

11.Then select the Enforce button.

12.Note that after a few seconds enforced shows up next to Bhogeswar’s name.

Task 2 - Review the Service settings for MFA

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, open the Identity submenu.
4.Select Users and then select All users.
5.Select Per-user MFA item.

6.Select Service settings.

7.Review the settings you can configure:

Setting	What is it for
App passwords	There are some legacy apps that won’t work with MFA, use this setting to allow a user to keep using them.
Trusted IPs	If your company has a specifc set of IP-address ranges that are always known safe, you can allow users to by-pass MFA the logging in.
Verification options	Select the methods you are willing to allow users to use for their second factor of authentication.
Remember multifactor authentication on trusted device	If your users are using a device that you trust, like a company managed laptop, you can allow them to retain thier MFA approved status for a specified number of days.

8.Select the Discard button if you made any changes. Save if you want to deliberately make changes.
This is one method of configuring MFA for your users.

Task 3 - View MFA account lockout settings

1.Open the Microsoft Entra admin center at https://entra.microsoft.com.
2.Log in using the credentials for your tenant.
3.From the menu on the left, open the Protection submenu.
4.Scroll to the bottom of the list and select Show more.
5.Select Multifactor authentication from the menu.
6.Select Account lockout from the menu.
7.Set the following lockout values:

Field	Value
Number of MFA denials to trigger account lockout	3
Minutes until account lockout counter is reset	180
Minutes until account is automatically unblocked	15

8.Select the Save option at the top of your screen.

Review some of the other configuration options you have on MFA like:

Fraud alert
Block / unblock users
Notifications

Summary

In this article, I explored the core aspects of configuring Multi-Factor Authentication (MFA) in Microsoft Entra ID. I demonstrated how to enable and manage per-user MFA, review and customize MFA service settings, and configure account lockout policies to protect against repeated unauthorized sign-in attempts. By implementing these security measures, organizations can significantly improve identity protection, reduce the risk of account compromise, and build a more resilient authentication framework for their cloud environments.