DEV Community: Rahimah Sulayman

S3 Has No Folders. Here's What You're Really Using.

Rahimah Sulayman — Thu, 22 Oct 2026 10:41:57 +0000

Overview

In my previous article, I created an S3 bucket and uploaded a single object. This time I'm organizing that bucket: creating folders, uploading multiple files at once, moving an object between folders, and finally deleting the bucket.

Along the way I'll explain a fact that trips up many people: Amazon S3 doesn't have folders. What the console shows you is something else, and once you understand it, a lot of S3 behavior starts to make sense.

By the end of this article, you'll be able to:

Create folders (and nested folders) in a bucket
Upload several files in one go
Explain what a prefix is and how it differs from a real folder
Move an object from one folder to another, and understand what S3 does behind the scenes
Empty and delete a bucket correctly

Where we're starting

I'm using the same bucket from the first article, aws-lab1-rahimah, which currently holds one object, datacenter.png.

Step 1: Create a folder

Inside the bucket, I clicked Create folder. The form asks for a folder name, so I entered food. Notice the hint under the field: folder names can't contain a /, because S3 uses that character itself to mark folder boundaries (more on that shortly).

The page also has a Server-side encryption section with two options:

Don't specify an encryption key: the folder uses the bucket's default encryption setting. I kept this one.
Specify an encryption key: choose a key just for this folder object.

Two warnings on that page are worth reading. The encryption settings apply only to the folder object itself, not to the files you later put inside it. And if your bucket policy requires a specific encryption key, you must specify that same key here, or folder creation will fail.

After clicking Create folder, S3 confirmed with a green banner, and the bucket now lists Objects (2): datacenter.png and food/. The Type column shows Folder for food/.

Opening food/ shows an empty folder: Objects (0).

So what is a "folder" in S3?

Here's the important part. S3 uses a flat structure. There is a bucket, and inside it there are objects. That's it. There are no real directories nested inside each other.

What the console calls a folder is built from three ideas:

Key: the full name of an object. A file I upload into food/ has the key food/burger.png, not just burger.png.
Prefix: the beginning part of a key. For food/burger.png, the prefix is food/.
Delimiter: the character that separates the parts of a key. In S3, it's the forward slash /.

When you click Create folder, S3 creates a tiny, empty object whose key ends in / (here, food/). The console then uses the / delimiter to display objects with the same prefix as if they lived in a folder. It's a presentation layer that makes a flat store feel familiar.

Coming from Azure? It works much the same way in Blob Storage. A container holds blobs in a flat namespace, and "folders" are just / characters in blob names (virtual directories). Real directories only appear when you enable the hierarchical namespace on a storage account (Data Lake Storage Gen2).

Step 2: Upload multiple files into the folder

With food/ open, I clicked Upload, then Add files. In the file picker, I selected three images at once: burger.png, cake.png and pizza.png.

The Upload page lists all three (3 total, 8.2 MB), and the Destination is now s3://aws-lab1-rahimah/food/. That path is the S3 URI of the folder, which is exactly the prefix the files will receive.

I clicked Upload, and the status page reported Upload succeeded: 3 files, 8.2 MB, 100%, with 0 failures.

Back at the bucket's root, there are still only two entries, datacenter.png and food/. The three new files live inside the folder.

Opening food/ shows Objects (3): burger.png, cake.png and pizza.png, each with the Standard storage class and its own last-modified time.

Step 3: Open a file and see the prefix in the URL

To prove the prefix idea, I selected burger.png and clicked Open. The image loaded in a new tab, and the address bar shows the key right in the path:

https://aws-lab1-rahimah.s3.eu-north-1.amazonaws.com/food/burger.png?X-Amz-Algorithm=...

See food/burger.png? That's the full key. There's no directory lookup involved. The long X-Amz-... parameters after it are the presigned URL signature I covered in the first article, which is why the file opens even though the bucket is private.

Step 4: Create a nested folder

Next, I wanted a sub-folder. Inside food/, I clicked Create folder again and named it menu. S3 confirmed with Successfully created folder "menu".

Now food/ contains burger.png, cake.png, pizza.png and the new menu/ folder. The key of that new folder is food/menu/, which is just a longer prefix. Nesting folders only means chaining more prefixes with /.

I deleted the datacenter.png and created an empty folder called menu/.

Step 5: Move a file into the new folder

I wanted cake.png to live in menu/. I ticked the checkbox next to cake.png and opened the Actions menu. It offers a lot of options:

Download as and Share with a presigned URL
Calculate total size
Copy and Move
Query with S3 Select
Under Edit actions: Rename object, Edit storage class, Edit server-side encryption, Edit tags, and Make public using ACL

I chose Move. The page opens with an important note at the top: this action creates a copy of the object with a new last-modified date, and depending on the bucket's versioning status, a delete marker will be inserted or the original object will be permanently deleted. Keep that sentence in mind, because it explains what move really does (more below).

The Destination field expects an S3 path in the format s3://bucket-name/optional-prefix/. You can type it, or click Browse S3 and navigate to the folder. I used Browse S3, went into aws-lab1-rahimah > food/, and selected the menu/ folder.

The browser also lets you open menu/ to check what's inside. At this point, it says there are no objects under this path, which is expected for a brand-new folder.

After clicking Choose destination, the form filled itself in:

Destination: s3://aws-lab1-rahimah/food/menu/
Destination bucket name: aws-lab1-rahimah
Destination prefix: food/menu/

Below that, Destination details shows the settings of the target bucket: Bucket Versioning is Disabled, Default encryption is SSE-S3, and Object Lock is Disabled. Because versioning is off, the console shows a recommendation to enable it. The Specified objects table confirms the one file being moved, cake.png (2.7 MB).

Last, Additional copy settings offers three choices. I kept the default, Copy source settings, which carries over the source object's storage class, tags, metadata and encryption. The other two let you skip those settings or specify new ones.

I clicked Move. The status page reported Successfully moved objects: 1 object, 2.7 MB, with 0 failures.

Checking the results:

food/ now shows Objects (3): burger.png, menu/ and pizza.png. cake.png is gone from here.

menu/ shows Objects (1): cake.png.

What "move" really does

Look at the Last modified time on the moved file. It changed to a newer timestamp than when I originally uploaded it. That's the giveaway: S3 has no true "move" or "rename" operation. The console does two steps for you:

Copy the object to the new key (food/cake.png becomes food/menu/cake.png).
Delete the original.

This matters for two reasons. First, because versioning was disabled on this bucket, the original was permanently deleted. If versioning were enabled, S3 would insert a delete marker instead, and the old version could be recovered. Second, the same logic applies to Rename object: it's also a copy followed by a delete, since a rename just means giving the object a new key.

For anything you can't afford to lose, enable versioning before you start moving things around.

Step 6: Delete the bucket

When the lab is finished, clean up so nothing lingers in your account. On the General purpose buckets page, I selected the radio button next to aws-lab1-rahimah. The toolbar offers Copy ARN, Empty, Delete and Create bucket.

I clicked Delete first, and S3 stopped me with this error: "This bucket is not empty. Buckets must be empty before they can be deleted." The page also asks you to type the bucket's name to confirm deletion, but the Delete bucket button stays disabled until the bucket is empty.

The solution is to empty the bucket first:

Click Empty bucket (on that error banner, or Empty on the bucket list). Or go back to the bucket, select the objects and click delete.
Confirm by typing permanently delete when prompted, then click Empty. This can never be retrieved because versioning is not enabled.

Return to Delete bucket, type aws-lab1-rahimah in the confirmation field, and click Delete bucket.

Emptying removes every object, including the folder objects, and it cannot be undone. That's why S3 makes you confirm twice.

Key takeaways

S3 has no real folders. A "folder" is a prefix that the console displays using the / delimiter.
An object's key is its full name, including the prefix. burger.png inside food/ has the key food/burger.png.
Creating a folder just creates a small, empty object whose key ends in /.
You can upload several files at once, and they all receive the destination folder's prefix.
Move and Rename are really copy + delete, which is why the last-modified date changes.
With versioning disabled, a move permanently removes the original. With versioning enabled, a delete marker is added instead.
A bucket must be emptied before it can be deleted.
In Azure terms, this is the same flat-namespace model as Blob Storage virtual directories.

Conclusion

Folders in S3 are a convenience, not a structure. Once you think in terms of keys and prefixes, things like moving files, setting lifecycle rules and writing IAM policies for food/* all make sense, because they all work on prefixes.

Next up in this series, I'll look at S3 permissions and what it takes to make an object public safely.

Which S3 feature should I cover after that: versioning, lifecycle rules or static website hosting? Let me know in the comments.

Getting Started with AWS S3: Creating a Bucket, Uploading an Object, and Understanding Why the Object URL Says Access Denied

Rahimah Sulayman — Tue, 20 Oct 2026 23:11:02 +0000

Introduction

I'm starting a new series on AWS, and this first article covers Amazon S3 (Simple Storage Service), one of the most widely used services on AWS. I did this lab in my own personal AWS free-tier account, and I'll explain every term as it comes up.

By the end, you'll know how to:

Create an S3 bucket with a consistent naming convention
Read the bucket's ARN and properties
Upload a file to the bucket
Find an object's URL, and understand why opening the image works while opening the Object URL doesn't

What is Amazon S3?

Amazon S3 is an object storage service. Instead of organizing data in a traditional disk with a file system, S3 stores data as objects inside buckets. You can store and retrieve any amount of data from anywhere, and you pay only for what you use.

Three terms to know first:

Bucket: a container for your data. Every object in S3 lives inside a bucket.
Object: the thing you store. It's the file itself plus its metadata (size, type, last modified date and so on).
Key: the object's unique name inside the bucket. For my file, the key is datacenter.png.

Step 1: Open the S3 service

In the AWS Management Console, I typed S3 into the search bar and selected S3 (Scalable Storage in the Cloud) from the results.

This opens the Amazon S3 landing page, where Create bucket is the first thing you see.

Step 2: Create a bucket

I clicked Create bucket, and the only thing I had to provide was the bucket name. The region was already set for me (more on that below), and I left everything else at the defaults to keep things simple.

Region

I didn't pick the region on this page. The Create bucket page shows it as plain text, not a dropdown: Europe (Stockholm) eu-north-1. That's because S3 creates a bucket in whichever region your console is currently set to, and mine was already set to Stockholm. I can't change it because this is a free plan. If you want a different region, switch it with the region selector in the top bar of the console before you click Create bucket.

A region is a physical geographic location where AWS runs data centers. Your bucket's data stays in the region it was created in, and the region affects latency (how close the data is to your users) and pricing.

Bucket type

I kept General purpose, which AWS recommends for most use cases. The other option, Directory, is for low-latency workloads that use a single Availability Zone.

Bucket namespace

I kept Global namespace. A namespace is the set of names in which yours has to be unique. In the global namespace, a bucket name must be unique across all AWS accounts, in every region. If someone else already has my-bucket, you can't use it. The console also offers an Account Regional namespace (labelled "recommended"). Buckets created there are unique only within your own account, so no other AWS account can ever claim the same name. I stayed with the global namespace for this lab.

Bucket name and the prefix naming convention

I named my bucket aws-lab1-rahimah.

The aws-lab1- part is a prefix I chose as a naming convention. A consistent prefix gives you three things:

It keeps names unique, since adding your own name or project helps avoid clashes in the global namespace.
It groups related resources together (aws-lab1-..., aws-lab2-...).
It makes resources easy to find and to clean up later.

S3 bucket names must be 3 to 63 characters long, can contain only lowercase letters, numbers, periods and hyphens, and must begin and end with a letter or number.

Default encryption

Further down the page, Default encryption was already set to Server-side encryption with Amazon S3 managed keys (SSE-S3). This means S3 automatically encrypts every new object at rest, using keys that AWS manages for you. You don't have to do anything. I left it as it was and clicked Create bucket.

S3 confirmed with a green banner: Successfully created bucket "aws-lab1-rahimah". The Objects tab shows Objects (0) because the bucket is empty.

Step 3: Look at the bucket's properties and ARN

I opened the Properties tab. The Bucket overview shows three things:

AWS Region: Europe (Stockholm) eu-north-1
Creation date: October 20, 2026
Amazon Resource Name (ARN): arn:aws:s3:::aws-lab1-rahimah

What is an ARN?

An Amazon Resource Name (ARN) is the unique identifier AWS gives every resource. It's how you point at a specific resource in IAM policies, logs and other services. The general shape is:

arn:partition:service:region:account-id:resource

For S3 buckets, the region and account sections are empty, which is why you see three colons in a row (:::). The bucket name is the final part.

The Properties tab also shows two settings that were off by default:

Bucket Versioning: Disabled. Versioning keeps multiple versions of an object, so you can recover from accidental overwrites or deletions. With it disabled, uploading a file with the same key replaces the old one.
Multi-factor authentication (MFA) delete: Disabled. This extra layer of security requires MFA before you can permanently delete object versions.

Step 4: Upload a file to the bucket

Back on the Objects tab, I clicked Upload.

On the Upload page, I clicked Add files and picked an image called datacenter.png from my Downloads folder. You can also drag and drop files, or use Add folder to upload a whole folder.

The page then listed the file as 1 total, 2.4 MB, type image/png, with the destination shown as s3://aws-lab1-rahimah.

Scrolling down, you'll see two collapsed sections:

Permissions: where you can grant public access and access to other AWS accounts.
Properties: where you can set the storage class, encryption settings and tags.

I left both alone and clicked Upload.

The next page showed Upload succeeded, with a summary of 1 file, 2.4 MB, 100% succeeded and 0 failed.

Back in the bucket, Objects (1) now lists datacenter.png, size 2.4 MB, and storage class Standard.

Storage class controls how your data is stored and what it costs. Standard is the default and is meant for frequently accessed data. Other classes, such as Glacier, are cheaper for data you rarely need to retrieve.

Step 5: Explore the object's details

I clicked datacenter.png to open its details. The Object overview shows:

Owner: the canonical ID of the AWS account that owns the object
AWS Region: eu-north-1
Last modified, Size and Type
Key: datacenter.png
S3 URI: s3://aws-lab1-rahimah/datacenter.png
ARN: arn:aws:s3:::aws-lab1-rahimah/datacenter.png
Entity tag (ETag): an identifier for this specific version of the object's content
Object URL: https://aws-lab1-rahimah.s3.eu-north-1.amazonaws.com/datacenter.png

Two of these are easy to confuse:

The S3 URI (s3://bucket/key) is what AWS tools like the AWS CLI and SDKs use to refer to an object.
The Object URL is the HTTPS address of the object on the internet, in the form https://bucket-name.s3.region.amazonaws.com/key.

The ARN here is the bucket's ARN with the object key added on the end.

Step 6: Open the image vs. use the Object URL

This is the part that surprised me, and it taught me the most. There are two ways to view the uploaded image, and they behave differently.

Option 1: Click "Open"

Clicking the Open button displays the image in a new browser tab. The address bar shows a very long URL that carries extra parameters such as X-Amz-Algorithm=AWS4-HMAC-SHA256.

That is a presigned URL. When you click Open, the console uses your own credentials to generate a temporary, signed link that grants access to the object for a short time. S3 sees the signature, confirms that a permitted user created it, and serves the file.

Option 2: Paste the Object URL

When I copied the plain Object URL into the browser, I got this:

<Error>
  <Code>AccessDenied</Code>
  <Message>Access Denied</Message>
  ...
</Error>

Why the difference?

The Object URL is an unauthenticated request. When you paste it into a browser, there's no signature and nothing that tells S3 who you are, so S3 treats you as an anonymous visitor. S3 buckets and objects are private by default, and only the owner can access them unless permissions are explicitly granted. So the anonymous request is refused with AccessDenied.

The error is not a bug. It shows S3's security model working as designed: nothing is public until you deliberately make it so.

Making objects public

If you need public access, for example to host images on a website, you'd have to change two things: turn off the relevant Block Public Access settings on the bucket, and then grant read access through a bucket policy or object permissions. Only do this for data that's genuinely meant to be public. For private files, presigned URLs are a safer way to share something temporarily.

Key Takeaways

A bucket is a container and an object is a file inside it, identified by its key.
Bucket names must be globally unique, so a naming prefix like aws-lab1- helps keep names unique and organized.
The region determines where your data physically lives.
An ARN uniquely identifies any AWS resource, and an object's ARN is its bucket's ARN plus the key.
The S3 URI is for AWS tools, while the Object URL is the HTTPS address.
S3 is private by default. Opening an object from the console works because it uses a presigned URL, while the plain Object URL returns AccessDenied.

Clean up

To avoid unexpected charges, delete what you created. You must empty a bucket before you can delete it:

Select datacenter.png and click the box, make sure you tick it, so that the Delete button is not greyed out.

Then confirm deletion.

Go back to the bucket list, select aws-lab1-rahimah and click Delete object.

Conclusion

In this first lab, I created an S3 bucket, uploaded an object, and learned why access to it is blocked by default. Next in the series, I'll build on this with more S3 features and other AWS services.

If you're learning AWS, let me know in the comments which service I should cover next.

Configure a project and repository structure to support secure pipelines.

Rahimah Sulayman — Fri, 16 Oct 2026 08:37:18 +0000

In this lab, you will learn how to configure a project and repository structure in Azure DevOps to support secure pipelines. This lab covers best practices for organizing projects and repositories, assigning permissions, and managing secure files.

Before you start

You’ll need an Azure subscription, Azure DevOps organization, and the eShopOnWeb application to follow the labs.

Follow the steps to validate your lab environment.

Validate your lab environment

In preparation for the labs, it is crucial to have your environment correctly set up. This section will guide you through the setup process, ensuring all prerequisites are met.

The labs require Microsoft Edge or an Azure DevOps-supported browser.
Set up an Azure Subscription: If you don’t already have an Azure subscription, create one by following the instructions on this page or visit https://azure.microsoft.com/free to sign up for a free.
Set up an Azure DevOps organization: If you don’t already have an Azure DevOps organization that you can use for the labs, create one by following the instructions on this page, or at Create an organization or project collection.
Git for Windows download page. This will be installed as part of prerequisites for this lab.
Visual Studio Code. This will be installed as part of prerequisites for this lab.
Azure CLI. Install the Azure CLI on the self-hosted agent machines.
.NET SDK - Latest version. Install the .NET SDK on the self-hosted agent machines.

Instructions to create an Azure DevOps Organization (you only have to do this once)

Note: Start at step 3, if you do already have a personal Microsoft Account setup and an active Azure Subscription linked to that account.

1.Use a private browser session to get a new personal Microsoft Account (MSA) at https://account.microsoft.com.

2.Using the same browser session, sign up for a free Azure subscription at https://azure.microsoft.com/free.

3.Open a browser and navigate to Azure portal at https://portal.azure.com, then search at the top of the Azure portal screen for Azure DevOps. In the resulting page, click Azure DevOps organizations.

4.Next, click on the link labelled My Azure DevOps Organizations or navigate directly to https://aex.dev.azure.com.

5.On the We need a few more details page, select Continue.

6.In the drop-down box on the left, choose Default Directory, instead of Microsoft Account.

7.If prompted (“We need a few more details”), provide your name, e-mail address, and location and click Continue.

8.Back at https://aex.dev.azure.com with Default Directory selected click the blue button Create new organization.

9.Accept the Terms of Service by clicking Continue.

10.If prompted (“Almost done”), leave the name for the Azure DevOps organization at default (it needs to be a globally unique name) and pick a hosting location close to you from the list.

11.Once the newly created organization opens in Azure DevOps, select Organization settings in the bottom left corner.

12.At the Organization settings screen select Billing (opening this screen takes a few seconds).

13.Select Setup billing and on the right-hand side of the screen, select your Azure Subscription and then select Save to link the subscription with the organization.

14.Once the screen shows the linked Azure Subscription ID at the top, change the number of Paid parallel jobs for MS Hosted CI/CD from 0 to 1. Then select SAVE button at the bottom.

Note: You may wait a couple of minutes before using the CI/CD capabilities so that the new settings are reflected in the backend. Otherwise, you will still see the message “No hosted parallelism has been purchased or granted”.

15.In Organization Settings, go to section Pipelines and click Settings.

16.Toggle the switch to Off for Disable creation of classic build pipelines and Disable creation of classic release pipelines

Note: The Disable creation of classic release pipelines switch sets to On hides classic release pipeline creation options such as the Release menu in the Pipeline section of DevOps projects.

17.In Organization Settings, go to section Security and click Policies.

18.Toggle the switch to On for Allow public projects

Note: Extensions used in some labs might require a public project to allow using the free version.
That option no longer exists.
Instructions to create and configure the Azure DevOps project (you only have to do this once)

Note: make sure you completed the steps to create your Azure DevOps Organization before continuing with these steps.

To follow all lab instructions, you’ll need set up a new Azure DevOps project, create a repository that’s based on the eShopOnWeb application, and create a service connection to your Azure subscription.

Create the team project

First, you’ll create an eShopOnWeb Azure DevOps project to be used by several labs.

1.Open your browser and navigate to your Azure DevOps organization.

2.Select the New Project option and use the following settings:

name: eShopOnWeb
visibility: Private
Advanced: Version Control: Git
Advanced: Work Item Process: Scrum

3.Select Create.

Import eShopOnWeb git repository
Now, you’ll import the eShopOnWeb into your git repository.

1.Open your browser and navigate to your Azure DevOps organization.

2.Open the previously created eShopOnWeb project.

3.Select the Repos > Files, Import a Repository and then select Import.

4.On the Import a Git Repository window, paste the following URL https://github.com/MicrosoftLearning/eShopOnWeb and select Import:

5.The repository is organized the following way:

.ado folder contains Azure DevOps YAML pipelines.
.devcontainer folder container setup to develop using containers (either locally in VS Code or GitHub Codespaces).
.azure folder contains Bicep & ARM infrastructure as code templates.
.github folder container YAML GitHub workflow definitions.
src folder contains the .NET 8 website used on the lab scenarios.

6.Leave the web browser window open.

7.Go to Repos > Branches.

8.Hover on the main branch then click the ellipsis on the right of the column.

9.Click on Set as default branch.

Create a service connection to access Azure resources

Next, you will create a service connection in Azure DevOps which will allow you to deploy and access resources in your Azure subscription.

1.Start a web browser, navigate to the Azure DevOps portal with the eShopOnWeb project open and select Project settings in the bottom left corner of the portal.

2.Select the Service connections under Pipelines, and then select Create service connection button.

3.On the New service connection blade, select Azure Resource Manager and Next (may need to scroll down).

4.Select Workload Identity federation (automatic) and Next.

Note: You can also use Workload identity federation (manual) if you prefer to manually configure the service connection. Follow the steps in the Azure DevOps documentation to create the service connection manually.

5.Fill in the empty fields using the information:

Subscription: Select your Azure subscription. Then sign in to your azure account.

Resource group: Select the resource group where you want to deploy resources.
Service connection name: Type azure subs. This name will be referenced in YAML pipelines to access your Azure subscription.

6.Make sure the Grant access permission to all pipelines option is unchecked and select Save.

Note: The Grant access permission to all pipelines option is not recommended for production environments. It is only used in this lab to simplify the configuration of the pipeline.

Note: If you see an error message indicating you don’t have the necessary permissions to create a service connection, try again, or configure the service connection manually.

You have now completed the necessary prerequisite steps to continue with the labs.

Instructions

Exercise 1: Configure a secure project structure

In this exercise, you will configure a secure project structure by creating a new project and assigning it project permissions. Separating responsibilities and resources into different projects or repositories with specific permissions supports security.

Task 1: Create a new team project

1.Navigate to the Azure DevOps portal at https://aex.dev.azure.com and open your organization.

2.Open your organization settings at the bottom left corner of the portal and then Projects under the General section.

3.Select the New Project option and use the following settings:
- name: eShopSecurity
- visibility: Private
- Advanced: Version Control: Git
- Advanced: Work Item Process: Scrum

4.Select Create to create the new project.

5.You can now switch between the different projects by clicking on the Azure DevOps icon in the upper left corner of the Azure DevOps portal.

You can manage permissions and settings for each project separately by going to the Project settings menu and selecting the appropriate team project. If you have multiple users or teams working on different projects, you can also assign permissions to each project separately.

Task 2: Create a new repository and assign project permissions

1.Select the organization name in the upper left corner of the Azure DevOps portal and select the new eShopSecurity project.

2.Select the Repos menu.

3.Select the Initialize button to initialize the new repository by adding the README.md file.

4.Open the Project settings menu in the lower left corner of the portal and select Repositories under the Repos section.

5.Select the new eShopSecurity repository and select the Security tab.

Note: Ensure that you select the Security tab in the specific repository only, and not for all repositories in the project. If you select all repositories, you may lose access to other repositories in the project.

6.Remove the Inherit permissions from parent by unchecking the Inheritance toggle button.

7.Select the Contributors group and select the Deny dropdown for all permissions except Manage permissions and Read. This will prevent all users from the Contributors group from accessing the repository.

Note: In a real world scenario, you will deny the manage permissions to the Contributors group as well. For this lab, we are allowing the Contributors group to manage permissions to allow you to complete the lab.

8.Select your user under Users and select the Allow button to allow all permissions.

Note: If you don’t see your name in the Users section, enter your name in the Search for users or groups text box and select it in the list of results.

9.Your changes will be saved automatically.

Now only the user you assigned permissions and the administrators can access the repository. This is useful when you want to allow specific users to access the repository and run pipelines from the eShopOnWeb project.

Exercise 2: Configure a pipeline and template structure to support secure pipelines

Task 1: Import and run the CI pipeline

Let’s start by importing the CI pipeline named eshoponweb-ci.yml.

1.Navigate to the Azure DevOps portal at https://aex.dev.azure.com and open your organization.

2.Open the eShopOnWeb project in Azure DevOps.

3.Go to Pipelines > Pipelines.

4.Select the Create Pipeline button.

5.Select Azure Repos Git (Yaml).

6.Select the eShopOnWeb repository.

7.Select Existing Azure Pipelines YAML File.

8.Select the /.ado/eshoponweb-ci.yml file then click on Continue.

9.Select the Run button to run the pipeline.

Note: Your pipeline will take a name based on the project name. You will rename it to easier identify the pipeline.

10.Go to Pipelines > Pipelines and select the recently created pipeline. Select the ellipsis and then select Rename/move option.

11.Name it eshoponweb-ci and select Save.

Task 2: Import and run the CD pipeline

Note: In this task, you will import and run the CD pipeline named eshoponweb-cd-webapp-code.yml.

1.Go to Pipelines > Pipelines.

2.Select New pipeline button.

3.Select Azure Repos Git (Yaml).

4.Select the eShopOnWeb repository.

5.Select Existing Azure Pipelines YAML File.

6.Select the /.ado/eshoponweb-cd-webapp-code.yml file then select Continue.

7.In the YAML pipeline definition, set the variables section to:

variables:
 resource-group: 'YOUR-RESOURCE-GROUP-NAME'
 location: 'centralus'
 templateFile: 'infra/webapp.bicep'
 subscriptionid: 'YOUR-SUBSCRIPTION-ID'
 azureserviceconnection: 'YOUR-AZURE-SERVICE-CONNECTION-NAME'
 webappname: 'YOUR-WEB-APP-NAME'

8.Replace the values of the variables with the values of your environment:

Replace YOUR-RESOURCE-GROUP-NAME with the name of the resource group you want to use in this lab, for example, rg-eshoponweb-secure.
Set the value of the location variable to the name of the Azure region you want to deploy your resources, for example, centralus.
Replace YOUR-SUBSCRIPTION-ID with your Azure subscription id.
Replace YOUR-AZURE-SERVICE-CONNECTION-NAME with azure subs
Replace YOUR-WEB-APP-NAME with a globally unique name of the web app to be deployed, for example, the string eshoponweb-lab-multi-123456 followed by a random six-digit number.

9.Select Save and Run and choose to commit directly to the main branch.

10.Select Save and Run again.

11.Open the pipeline run. If you receive the message “This pipeline needs permission to access a resource before this run can continue to Deploy to WebApp”, select View, Permit and Permit again. This is needed to allow the pipeline to create the Azure App Service resource.

12.The deployment may take a few minutes to complete, wait for the pipeline to execute. The pipeline is triggered following the completion of the CI pipeline and it includes the following tasks:

AzureResourceManagerTemplateDeployment: Deploys the Azure App Service web app using bicep template.
AzureRmWebAppDeployment: Publishes the Web site to the Azure App Service web app.

Note: In case the deployment fails, navigate to the pipeline run page and select Rerun failed jobs to invoke another pipeline run.

Note: Your pipeline will take a name based on the project name. Let’s rename it for identifying the pipeline better.

13.Go to Pipelines > Pipelines and select the recently created pipeline. Select the ellipsis and then select Rename/move option.

14.Name it eshoponweb-cd-webapp-code and click on Save.

Now you should have two pipelines running in your eShopOnWeb project.

After troubleshooting, the pipeline finally succeeded.
NOTE: Check the Troubleshooting section below to see how I resolved the errors.

Task 3: Move the CD pipeline variables to a YAML template

In this task, you will create a YAML template to store the variables used in the CD pipeline. This will allow you to reuse the template in other pipelines.

1.Go to Repos and then Files.

2.Expand the .ado folder and select New file.

3.Name the file eshoponweb-secure-variables.yml and select Create.

4.Add the variables section used in the CD pipeline to the new file. The file should look like the following:

variables:
  resource-group: 'rg-eshoponweb-secure'
  location: 'southcentralus' #the name of the Azure region you want to deploy your resources
  templateFile: 'infra/webapp.bicep'
  subscriptionid: 'YOUR-SUBSCRIPTION-ID'
  azureserviceconnection: 'azure subs' #the name of the service connection to your Azure subscription
  webappname: 'eshoponweb-lab-secure-XXXXXX' #the globally unique name of the web app

Important: Replace the values of the variables with the values of your environment (resource group, location, subscription ID, Azure service connection, and web app name).

5.Select Commit, in the commit comment text box, enter [skip ci], and then select Commit.

Note: By adding the [skip ci] comment to the commit, you will prevent automatic pipeline execution, which, at this point, runs by default following every change to the repo.

6.From the list of files in the repo, open the eshoponweb-cd-webapp-code.yml pipeline definition, and replace the variables section with the following:

variables:
     - template: eshoponweb-secure-variables.yml

7.Select Commit, accept the default comment, and then select Commit to run the pipeline again.

8.Verify that the pipeline run completed successfully.

Now you have a YAML template with the variables used in the CD pipeline. You can reuse this template in other pipelines in scenarios where you need to deploy the same resources. Also, your operations team can control the resource group and location where the resources are deployed and other information in your template values and you don’t need to make any changes to your pipeline definition.

Task 4: Move the YAML templates to a separate repository and project

In this task, you will move the YAML templates to a separate repository and project.

1.In your eShopSecurity project, go to Repos > Files.

2.Create a new file named eshoponweb-secure-variables.yml.

3.Copy the content of the file .ado/eshoponweb-secure-variables.yml from the eShopOnWeb repository to the new file.

4.Commit the changes.

5.Open the eshoponweb-cd-webapp-code.yml pipeline definition in the eShopOnWeb repo.

6.Add the following to the resources section before the variables section in the pipeline definition:

   repositories:
     - repository: eShopSecurity
     type: git
     name: eShopSecurity/eShopSecurity #name of the project and repository

7.Replace the variables section with the following:

variables:
     - template: eshoponweb-secure-variables.yml@eShopSecurity #name of the template and repository

8.Select Commit, accept the default comment, and then select Commit to run the pipeline again.

9.Navigate to the pipeline run and verify that the pipeline is using the YAML file from the eShopSecurity repository.

Now you have the YAML file in a separate repository and project. You can reuse this file in other pipelines in scenarios where you need to deploy the same resources. Also, your operations team can control the resource group, location, security and where the resources are deployed and other information by modifying values in the YAML file and you don’t need to make any changes to your pipeline definition.

[!IMPORTANT] Remember to delete the resources created in the Azure portal to avoid unnecessary charges.

Review

In this lab, you learned how to configure and organize a secure project and repository structure in Azure DevOps. By managing permissions effectively, you can ensure that the right users have access to the resources they need while maintaining the security and integrity of your DevOps pipelines and processes.

Troubleshooting: Problems I Hit and How I Fixed Them

1. “Could not find any file matching the template file pattern”

Symptom: The “Deploy App Service Plan Bicep” step failed before reaching Azure.

Cause: I set templateFile: 'infra/webapp.bicep'. The task already builds the path as $(Pipeline.Workspace)/eshoponweb-ci/Bicep/$(templateFile), so it looked for .../Bicep/infra/webapp.bicep, which doesn’t exist. The CI pipeline publishes the file in a Bicep folder in the artifact, not in infra.

Fix: Set templateFile: 'webapp.bicep', with no folder prefix.

2. Quota error: `SubscriptionIsOverQuotaForSku`

Symptom:

Current Limit (S1 VMs): 0 Amount required for this deployment (S1 VMs): 1

Cause: The Bicep template defaults to the S1 SKU, and my subscription had a quota of 0 for it. This can happen even on pay-as-you-go subscriptions, because new subscriptions often start with no App Service quota for some tiers.

Fix attempt: I changed the SKU in infra/webapp.bicep to the Free tier, F1.

3. The change didn’t take effect, and F1 failed too

Symptom: The next run still reported S1 VMs.

Cause: The CD pipeline deploys the copy of the Bicep file inside the eshoponweb-ci build artifact, not the file in the repo. My edit only took effect after I re-ran eshoponweb-ci. After that, the error changed to Current Limit (F1 VMs): 0, so the subscription had no Free-tier quota in that region either.

Fix: Quota is per region, so I created a new resource group in West Europe and updated the resource-group and location variables.

4. 403 when checking the new resource group

Symptom:

Checking if the following resource group exists: RG. Failed to check the resource group status. Error: {"statusCode":403}

Cause: The Azure DevOps service connection signs in as a service principal whose role assignment only covered my original resource group.

Fix:

In Azure DevOps, Project settings → Service connections → Manage App registration gave me the service principal’s display name.
In the Azure portal, on the new resource group: Access control (IAM) → Add → Add role assignment.
I picked the plain Contributor role (not Web Plan Contributor or Website Contributor) and selected the service principal as the member. Check that the Role tab doesn’t say “None” before clicking Review + assign.
After waiting a few minutes, the deployment succeeded.

5. TF401027: You need the Git 'CreateBranch' permission

Symptom: Clicking Initialize on the empty eShopSecurity repo failed.

Cause: My account lacked the Create branch permission on that repository, even though I was the organization owner and in the Project Collection Administrators group. An explicit Deny or a repo-level permission issue overrides group membership.

Fix: I checked the repo’s Security tab for a Deny, then created a fresh repo instead, because the creator of a repo gets full rights on it. I reused the name eShopSecurity.

6. Pipeline run “Informational run” with a YAML error

Symptom: A run appeared with an error about YAML preventing Azure Pipelines from deciding whether to run, and clicking into it showed No plan found for identifier.

Cause: The YAML couldn’t be parsed, so the pipeline never started. There’s no execution plan to open or rerun.

Fix: Don’t rerun that entry. Use Edit → ⋮ → Validate on the pipeline to find the broken line, fix it, and start a new run.

7. The shared variables template

The lab moves variables into a template in a separate repo and references it from the pipeline:

resources:
  repositories:
    - repository: eShopSecurity
      type: git
      name: eShopSecurity/eShopSecurity

variables:
  - template: eshoponweb-secure-variables.yml@eShopSecurity

Things to check:

The alias after @ must match the repository: name in resources.
Put a space before any # comment, or YAML treats it as part of the value.
The template file holds the variable definitions (- name: / value:). It must not contain a template: line pointing to itself.
Because the pipeline no longer defines variables, the template must include every one it uses (resource-group, location, templateFile, subscriptionid, azureserviceconnection, webappname).
On the first run, Azure DevOps may ask you to permit access to the other repo.

Errors resolved while trying to view the App in a browser

8. Git: “Authentication failed” and PATs

Symptom: git pull and git push over HTTPS asked for a password and rejected it.

Cause: Azure Repos doesn’t accept your Microsoft account password. It needs a Personal Access Token with Code → Read & write, created for the right organization.

Fix: I created a new PAT (User settings → Personal access tokens), pasted it at the prompt (nothing shows as you type, and Shift+Insert or right-click pastes in WSL), and the push worked. I revoked the unused token afterwards.

After the push, I waited for the pipeline to run successfully.

9. Build warning NU1903 (known high severity vulnerability)

Symptom: The CI run and dotnet build both warned that Microsoft.AspNetCore.Components.WebAssembly.Server 8.0.15 had a known high severity vulnerability.

Fix:

dotnet list src/Web/Web.csproj package --outdated --highest-patch showed the newest 8.0.x patch (8.0.32).
Because the repo uses central package management, I changed the version in Directory.Packages.props.
Rebuilding with dotnet build eShopOnWeb.sln reported 0 warnings.

10. Running the app locally in WSL

MSB1011: more than one project or solution file: the repo root has both a .sln and a .dcproj. Name the target: dotnet build eShopOnWeb.sln and dotnet run --project src/Web.
LocalDB is not supported on this platform: LocalDB is Windows-only. Run with the in-memory database: UseOnlyInMemoryDatabase=true dotnet run --project src/Web, then open http://localhost:5001.

Key takeaways

A quota error is per SKU and per region, so changing either can clear it.
The CD pipeline deploys the CI artifact, so Bicep changes only apply after CI runs again.
A new resource group needs its own role assignment for the service connection’s service principal.
A failed YAML parse produces an informational run, so use Validate rather than rerunning it.
Azure Repos over HTTPS needs a PAT, not your account password.

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

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

Introduction

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

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

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

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

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

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

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

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

You complete the following tasks during this exercise:

1.Set revision management to multiple.

2.Create a new revision with a v2 suffix.

3.Configure labels on the revisions.

4.Configure a traffic percentage on the revisions.

5.Verify the configuration.

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

Set revision management to multiple

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

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

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

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

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

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

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

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

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

Configure a traffic percentage and labels on the revisions

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

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

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

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

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

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

Check your work

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

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

3.Verify that your revisions are configured as follows:

Summary

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

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

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

Skills practiced:

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

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

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

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

Introduction

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

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

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

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

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

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

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

You complete the following tasks during this exercise:

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

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

3.Run the Pipeline1 deployment task.

4.Verify the configuration.

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

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

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

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

4.Select Pipeline1, and then select Edit.

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

trigger:
- main

pool:
  name: default

steps:

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

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

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

Configure Pipeline1 with an Azure Container Apps deployment task

1.Ensure that you have Pipeline1 open for editing.

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

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

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

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

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

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

7.Configure the following Pipeline1 Task information:

Azure Resource group name: RG1

Note

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

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

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

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

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

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

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

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

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

Run the Pipeline1 deployment task

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

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

A Run pipeline page opens to display the associated job.

3.Select Run.

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

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

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

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

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

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

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

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

Then store the password as a secret:

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

Name: acrPassword
Value: paste the password.

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

Docker permissions issue:

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

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

Check your work

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

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

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

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

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

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

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

Summary

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

Part 4 covers continuous integration with Azure Pipelines:

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

Skills practiced:

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

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

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

Introduction

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

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

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

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

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

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

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

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

You complete the following tasks during this exercise:

1.Create a container app that uses an ACR image

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

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

4.Configure HTTP scale rules

5.Verify the configuration

Create a container app that uses an ACR image

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

1.Open your Azure portal.

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

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

4.Select Create.

5.On the Basics tab, specify the following:

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

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

Container Apps Environment: Select Create new.

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

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

Note

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

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

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

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

9.Select Review + create.

10.Once verification has Passed, select Create.

11.Wait for the deployment to complete.

Note

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

Configure the container app to authenticate using the user assigned identity

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

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

2.Under Security, select Identity.

3.Select the tab for User assigned.

4.Select Add user assigned managed identity.

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

Note

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

Configure a connection between the container app and Service Bus

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

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

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

3.Select Connect to your Services.

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

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

5.Select Next: Authentication.

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

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

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

8.To change tabs, select Review + Create.

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

10.Wait for the connection to be created.

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

Configure HTTP scale rules

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

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

3.Notice the Name assigned to your active revision.

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

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

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

7.Configure the Min / max replicas as follows:

Set Min replicas: 0
Set Max replicas: 2

8.Under Scale rule, select + Add.

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

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

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

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

12.Ensure that your new scale rule is displayed.

Check your work

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

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

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

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

4.Verify that the expected Registry settings are reported:

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

5.Close the Container App page.

6.Open your Container Apps Environment resource.

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

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

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

Run the following command:

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

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

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

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

Note:

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

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

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

To confirm it's healthy, run:

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

The results should show success for each check.

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

Run:

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



![role](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/rc6oeqj7xlcw9zjxv8bv.png)

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

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

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

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

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

## Summary

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

Part 3 covers deploying and connecting the container app:

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

### Skills practiced: 
Azure Container Apps, Managed Identity, Service Bus, Service Connector, Azure CLI, Autoscaling, Azure RBAC

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

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

Introduction

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

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

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

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

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

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

Important

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

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

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

You complete the following tasks during this exercise:

1.Configure a user-assigned managed identity.

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

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

4.Verify the configuration.

Note

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

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

1.Open your Azure portal.

2.On the Search bar, enter managed identity

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

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

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

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

6.Select Review + create.

7.Select Create.

Configure Container Registry with AcrPull permissions for the managed identity

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

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

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

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

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

5.Select Next.

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

7.Select + Select members.

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

For example: uai-az2003.

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

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

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

12.Wait for the role assignment to be added.

Configure Container Registry with a private endpoint connection

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

2.Under Settings, select Networking.

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

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

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

5.Select Next: Resource.

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

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

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

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

9.Select Next: DNS.

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

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

11.Select Next: Tags.

12.Select Next: Review + create.

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

14.Wait for the deployment to complete.

Check your work

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

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

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

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

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

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

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

For example, select per-acr-az2003

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

8.Verify the following DNS setting:

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

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

10.Verify the following setting:

Virtual network/subnet: set to VNET1/PESubnet.

Summary

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

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

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

Skills practiced:

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

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

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

Introduction

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

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

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

Prepare your app deployment tools and resources

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

Important

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

Project overview

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

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

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

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

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

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

Setup

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

Configure host environment tools.

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

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

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

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

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

Install Docker Desktop

Complete the following steps to install Docker Desktop.

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

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

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

3.Follow the online instructions to install Docker Desktop.

Install the .NET Software Development Kit

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

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

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

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

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

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

Install Visual Studio Code with Docker and Azure App Service extensions

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

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

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

Note

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

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

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

Note

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

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

Accept the default options during the remainder of the installation.

6.Ensure that you have Visual Studio Code open.

7.On the Activity bar, select Extensions.

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

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

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

10.To install the extension, select Install.

11.Wait for the installation to complete.

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

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

14.To install the extension, select Install.

15.Wait for the installation to complete.

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

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

18.To install the extension, select Install.

19.Wait for the installation to complete.

20.Close Visual Studio Code.

Install Azure CLI and the `containerapp` extension

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

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

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

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

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

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

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

5.Follow the prompts to complete the authentication process.

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

Install Microsoft PowerShell

Complete the following steps to install Microsoft PowerShell.

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

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

Configure a Resource Group for your Azure resources

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

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

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

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

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

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

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

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

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

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

6.Select Review + create.

7.Once validation has passed, select Create.

8.Verify

Configure a Virtual Network and subnets

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

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

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

3.In the search results, select Virtual networks.

4.Select Create virtual network.

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

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

6.Select the Address space tab.

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

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

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

9.Select Save.

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

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

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

12.Select Add.

13.Select Review + create.

14.Once validation has passed, select Create.

15.Wait for the deployment to complete.

Configure Service Bus

Complete the following steps to configure a Service Bus instance.

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

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

3.In the search results, select Service Bus.

4.Select Create service bus namespace.

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

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

6.Select Review + create.

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

8.Wait for the deployment to complete.

Configure Azure Container Registry

Complete the following steps to configure a Container Registry instance.

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

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

3.In the search results, select Container registries.

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

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

Note

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

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

Important

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

6.Select Review + create.

7.Select Create.

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

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

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

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

Create a WebAPI app and publish to a GitHub repository

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

Open Visual Studio Code.

2.On the File menu, select Open Folder.

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

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

4.On the Terminal menu, select New Terminal.

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

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

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

.NET CLI
`dotnet build`

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

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

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

gitignore
[Bb]in/
[Oo]bj/

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

10.Open the Source Control view.

11.Select Publish to GitHub.

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

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

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

Create Docker image and push to Azure Container Registry

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

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

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

3.When prompted, specify the following information:

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

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

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

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

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

5.Wait for the Docker Build command to complete.

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

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

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

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

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

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

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

The following Docker command is executed:

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

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

You can also verify via Docker Desktop.

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

Configure Azure DevOps and a starter Pipeline

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

Open the Azure portal.

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

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

4.Select My Azure DevOps Organizations.

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

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

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

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

9.Return to the home page of your organization.

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

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

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

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

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

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

14.Under Import a repository, select Import.

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

Your repository URL should be similar to the following example:

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

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

17.Select Create Pipeline.

18.Select Azure Repos Git.

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

20.Select Starter pipeline.

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

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

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

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

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

Note

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

Deploy a self-hosted Windows agent

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

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

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

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

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

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

4.Under Name, enter AZ2003.

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

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

Ensure that all the other boxes are cleared.

7.Select Create.

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

You use this token when you configure the agent.

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

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

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

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

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

a. To select the default pool, select Default.

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

i.Under Pool type, select Self-hosted.

ii.Under Name, enter default

iii.Select Create.

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

b.Select Agents, and then select New agent.

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

a.Select the Windows tab.

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

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

c.On the right pane, select Download.

d.Follow the instructions to download the agent.

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

dos
`C:\agents`

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

16.Open PowerShell as an Administrator.

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

.\config`

18.Respond to the configuration prompts as follows:

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

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

Summary

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

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

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

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

Skills practiced so far:

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

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

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

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

Introduction

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

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

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

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

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

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

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

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

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

7.On the Select features page, click Next.

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

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

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

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

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

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

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

15.On the DNS Options page, click Next.

16.On the Additional Options page, click Next.

17.On the Paths page, click Next.

18.On the Review Options page, click Next.

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

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

Transfer Flexible Single Master Operations Roles

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

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

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

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

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

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

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

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

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

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

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

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

8.Close Active Directory Sites and Services.

Summary

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

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

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

Introduction

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

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

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

Overview

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

This exercise should take approximately 10 minutes to complete.

Restrict NTLM Authentication

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

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

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

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

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

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

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

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

9.Close the Group Policy Management Editor.

Audit User Account Management in Sydney

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

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

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

6.Right-click SydneyOUPolicy and select Edit.

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

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

11.Close the Group Policy Management Editor

Deny Log On As a Service

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

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

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

6.Select the Define this policy setting.

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

9.Select Sydney Administrators group.

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

Conclusion

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

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

Securing Active Directory with Password Policies and Recycle Bin

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

Introduction

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

Overview

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

This exercise should take approximately 10 minutes to complete.

Configure Domain Password Policy

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

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

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

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

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

5.Double click the Minimum password length policy item.

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

8.Close the Group Policy Management console.

Configure Fine-Grained Password Policy

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

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

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

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

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

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

10.Open the new policy Domain Admins Password Policy.

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

12.Click OK.

Enable Active Directory Recycle Bin

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

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

4.Click OK to dismiss the warning.

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

Project Summary

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

Administering Active Directory Users, Groups, and Organizational Units

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

Introduction

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

Overview

In this exercise, you perform user management operations.

This exercise should take approximately 25 minutes to complete.

Create Organizational Units

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

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

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

3.Select New, then Organizational Unit.

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

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

Create users

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Create the Sydney Admins group

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

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

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

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

5.In the Member Of tab, click Add.

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

8.Click OK, then click OK.

Configure a user as a Protected User

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

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

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

Delegate Security Permissions to an OU to a security group

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

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

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

4.Click Add and type Sydney Administrators.

5.Click Check Names.

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

8.Click Finish.

Configure City Attribute for a User

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

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

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

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

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

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

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

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

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

Disable the Melbourne Contractor User

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

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

3.Click OK.

Reset the password of the Brisbane Contractor User

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

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

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

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

Project Summary

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

DEV Community: Rahimah Sulayman

S3 Has No Folders. Here's What You're Really Using.

Overview

Where we're starting

Step 1: Create a folder

So what is a "folder" in S3?

What the console calls a folder is built from three ideas:

Step 2: Upload multiple files into the folder

Step 3: Open a file and see the prefix in the URL

Step 4: Create a nested folder

Step 5: Move a file into the new folder

What "move" really does

Step 6: Delete the bucket

Key takeaways

Conclusion

Getting Started with AWS S3: Creating a Bucket, Uploading an Object, and Understanding Why the Object URL Says Access Denied

Introduction

What is Amazon S3?

Step 1: Open the S3 service

Step 2: Create a bucket

Region

Bucket type

Bucket namespace

Bucket name and the prefix naming convention

Default encryption

Step 3: Look at the bucket's properties and ARN

What is an ARN?

Step 4: Upload a file to the bucket

Step 5: Explore the object's details

Step 6: Open the image vs. use the Object URL

Option 1: Click "Open"

Option 2: Paste the Object URL

Why the difference?

Making objects public

Key Takeaways

Clean up

Conclusion

Configure a project and repository structure to support secure pipelines.

Before you start

Validate your lab environment

Instructions

Exercise 1: Configure a secure project structure

Task 1: Create a new team project

Task 2: Create a new repository and assign project permissions

Exercise 2: Configure a pipeline and template structure to support secure pipelines

Task 1: Import and run the CI pipeline

Task 2: Import and run the CD pipeline

Task 3: Move the CD pipeline variables to a YAML template

Task 4: Move the YAML templates to a separate repository and project

Review

Troubleshooting: Problems I Hit and How I Fixed Them

1. “Could not find any file matching the template file pattern”

2. Quota error: SubscriptionIsOverQuotaForSku

3. The change didn’t take effect, and F1 failed too

4. 403 when checking the new resource group

5. TF401027: You need the Git 'CreateBranch' permission

6. Pipeline run “Informational run” with a YAML error

7. The shared variables template

Errors resolved while trying to view the App in a browser

8. Git: “Authentication failed” and PATs

9. Build warning NU1903 (known high severity vulnerability)

10. Running the app locally in WSL

Key takeaways

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

Introduction

Set revision management to multiple

Configure a traffic percentage and labels on the revisions

Check your work

Summary

Skills practiced:

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

Introduction

Configure Pipeline1 to use the self-hosted agent pool

Configure Pipeline1 with an Azure Container Apps deployment task

Run the Pipeline1 deployment task

Check your work

Summary

Skills practiced:

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

Introduction

2. Quota error: `SubscriptionIsOverQuotaForSku`

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

Install Azure CLI and the `containerapp` extension