DEV Community: Florian Demel

How to use App Service Deployment Slots (with containers)

Florian Demel — Mon, 29 Dec 2025 13:58:44 +0000

TLDR

Using Azure App Service deployment slots requires key architectural decisions early on. Running zero-downtime deployments or blue-green deployments sadly does not come 100% out of the box. This post covers my learnings and my ideal approach of an enterprise App Service setup:

Use a single Azure Subscription: This is necessary because deployment slots of one App Service cannot run across subscriptions or resource groups.
Create a "shared" Resource Group: This group holds the App Service Plan and the App Service itself, allowing slots to be managed centrally over multiple environments.
Isolate environment-specific resources: Use separate Resource Groups for production and preview resources like databases and Key Vaults to maintain environment isolation.

Following this setup avoids the pitfalls with deployments of multiple App Service resources in multiple subscriptions for the same application. Always keep in mind that deployment slots for multiple environments do work with one App Service resource only.

Introduction

I have been working for quite a while now with Azure App Service Deployment Slots, and the experience has mostly been great. It feels seamless and safe to deploy applications by swapping a container from one App Service slot to another.

When working in a professional environment with App Services, deployment slots will most likely become a topic at one point. This is because:

Your team wants to enable blue-green deployments to test a newly built application in a production-like environment before replacing the old version with the new one. - For more information, refer to Red Hat's great docs of this topic.
Or your team wants to create a second deployment environment to integrate applications with one another before deploying them to production. - For more information, refer to Martin Fowler's great Blog about continuous integration.

Both strategies are well known and often implemented at the same time. To enable blue-green deployments and deployment environments side-by-side, you seriously need to make some architectural decision early on.

To prepare you for these decisions, I want to outline my preferred approach for an App Service setup and discuss its most critical topics to enable environments and slots:

Environment subscription structure
Deployment with and without Deployment Slots
Side effects of Deployment Slots

Please note: This post will dive pretty deep into the topic, if you are not familiar with App Service deployment Slots, have a look at Microsoft's deployment slot docs.

Preferred Approach

Deployment Slots basics

A deployment slot is essentially another—closely related—App Service running on your App Service Plan alongside your existing "main" App Service. It comes with two important features:

You are able to configure the deployment slots and the main slot of each App Service independently. This works by setting different app settings for each slot—effectively different environment variables. Microsoft calls this slot feature "unswappable settings", settings that always stay with one slot, not with the container running inside. This way you are able to configure an isolated development environment around each of the slots.
You are able to swap slots. That means you can run new containers on a deployment slot—effectively in a specific development environment—before swapping exactly that already running version to the main slot. If you are not satisfied with the way the new container performs in the main slot, you are always able to roll back the new container and swap the slots back to its previous version.

Beyond these two features, Azure promotes this capability heavily. Have a look at the docs to get a broad picture of all the features coming with App Service slots.

Example

To illustrate a typical setup, I want to make a simple example:

We want to run one application on Azure App Services in two environments: Preview (preview.app.com) and Production (app.com).
Each application uses one Azure SQL database and stores its environment secrets in a Key Vault. Both resources are needed in each environment.
To provision the App Service main slot (production environment) and the App Service deployment slot (preview environment) there must be one App Service Plan resource that hosts the slots.
To provision Azure SQL databases, there must be one SQL Database Server that hosts the production and preview databases.

To enable both development environments and to swap slots between preview and production, my preferred setup looks like this:

One Subscription: All resources of our example are living in one subscription.
Shared Resource Groups: The App Service resource with the main and the deployment slot, the App Service plan resources, and the Azure SQL Server are cross-environment resources. They are needed by both the production and preview environments and are part of a "shared" resource group. It is not possible to maintain one App Service resource for each environment, as Azure does not support the provisioning of slots in multiple resource groups (or subscriptions). This would force us to use multiple resources instead of multiple slots!
Production Resource Groups: The production database and a production Key Vault are an isolated part of the production environment, provisioned in a production resource group.
Preview Resource Groups: The preview database and a preview Key Vault are an isolated part of the preview environment, provisioned in a preview resource group.

With a setup like this, we are able to maintain two isolated environments for both application environments (preview & production). Both have their own persistent database and separated secrets in their Key Vaults, while still being able to run everything using one App Service resource. This allows us to use the swap slot features between the two environments.

To outline the architectural decisions behind this setup, the next sections dive deeper into the technical details.

Environment subscription structure

You may have already seen that Azure typically recommends using different Azure subscriptions for each development environment in its cloud adoption framework. However, I found this contradicts the default App Service deployment slot setup for one main reason:

All environments must connect to exactly one App Service resource. This is critical because an App Service can create slots only as part of the same resource and resource group. Therefore, it is not possible to use multiple deployment slots of one App Service between different subscriptions or even resource groups.
That is why I prefer to have a shared resource group hosting the App Service. Any other approach would prevent swaps between the App Services runtimes of the different environments entirely.

Another option would be to use multiple App Service resources, which could be part of different resource groups or even subscriptions.

App Service resources in multiple subscriptions would require multiple App Service plans and could possibly introduce other architectural challenges, for example, with networking, resource moving, or your IAM setup.
App Service resources in multiple resource groups would be easier to manage, as they can still run on the same App Service plan and inside the same subscription boundaries. However, you would lose the opportunity to swap slots.

Deployment

While you might be able to solve the challenges coming with multiple subscriptions or find a viable setup with multiple resource groups, there is one thing you will not find an easy solution for: the missing swap slot feature. It is the most critical feature you would not want to lose.

Kudu deployments

Without the swap slot feature, you need to rely on Kudu deployment. Kudu is the deployment engine behind App Service container deployment, which is used as soon as a container registry and image tag is set at an App Service. It pulls the container image, starts a new container, and throws the old container away as soon as the new one starts.

In a setup where multiple App Service resources are used, either across resource groups or subscriptions, this deployment method is the only option to deploy. The process would look like this:

Kudu deploys new container to main slot -> publicly available

compared to a deployment slot deployment:

Kudu deploys new container to preview slot -> preview slot is tested -> preview slot container is swapped to main slot -> publicly available

The issue with Kudu deployments is that they are not entirely zero-downtime. Although in most cases, especially when the App Service is running on multiple instances, Kudu manages to shut down and start new containers on the different instances one after another—which keeps the application practically without downtime—this approach has some caveats:

Transient downtime: Some users might experience issues when interacting with one of the instances that is shut down in the deployment process. As they lose their session and are redirected to the other instance, it is also possible to have different versions on different instances, which might cause issues for the users.
Scaling: The moment the container is updated by Kudu, it becomes unavailable. This basically reduces the capacity of the application, shifting more load to the other instances.

You might understand why Kudu deployments are not labeled as zero-downtime by Azure, and why they should not be used for high-professional production workloads. Nevertheless, the decision always depends on your specific use case.

Side Effects of Deployment Slots

There is another method to enable zero-downtime deployments with multiple App Service resources in multiple resource groups or subscriptions: using deployment slots for each resource.

This option is probably the one you must choose if your company has specific requirements for resource allocation in an environment subscription or if you want to follow Microsoft's cloud adoption framework.

This option depends strongly on your individual case; often, it is fairly simple. But some cases come with pretty remarkable side effects.

Two Environments

Imagine you create two applications running in the same environment. If you are using REST HTTP calls and a simple database, this is not an issue. Load balancing will pass each request to only one of the applications or instances running, and the database will prevent parallel write operations by default. You are likely fine running two apps in two slots side-by-side in one environment. There are no side effects so far.

However, be aware: If you were to use the deployment slot as another testing environment now, for example with different databases, you are essentially creating another new environment besides the one already existing. This introduces even more complexity and fiddling around with the setup and resources.

Async Communication

Another problematic point is async events, for example when you are using Kafka to communicate from one of your apps to another. Imagine there is an event consumed by your app that triggers it to write a new user to your database.

In this case the following issue might appear: Your environment has one event publisher that sends these user events, e.g. App 1. App 1 user events can now be consumed by both your main slot and your deployment slot—because both are in the same environment. You are now coming to a point where the deployment slot might "steal" the event from your main slot—because it is connected to the same user events. In this case it writes the user to its database, not the one of the main slot—so the user is not available in your main slot.

Another issue could be that the deployment slot processes the event in another way than expected because it is running a different code version than the main slot.

These side effects are nothing that a developer could not solve, but they are introducing another layer of complexity that someone must handle. This is often hard to grasp for application developers who do not want to dive deep into the infrastructure.

Wrap up

Choosing the right architecture for your Azure App Service environments is critical. While Microsoft's Cloud Adoption Framework often recommends separate subscriptions, this approach conflicts with the core functionality of deployment slots, which cannot be swapped across subscription or resource group boundaries.

By using a single subscription with a shared resource group for the App Service and separate, environment-specific resource groups for databases and secrets, you get the best of both worlds. You maintain clear environment isolation while retaining the powerful, zero-downtime swap capability.

As always, the optimal approach depends on various factors. I hope you are now aware of the pitfalls and key decisions required for deployment slot setups.

About me

My name is Florian, I am a platform engineer who wants to share his dev experience with you, hoping it makes us all a bit smarter. Please let me know what you think about my post!

In case you want to see more of my posts, you can also find me on X.com, where I share all of my content.

How to Dockerize a Next.js App (2025)

Florian Demel — Sat, 29 Nov 2025 09:53:31 +0000

Introduction

In the last week, my team and I were working on a new setup of our Next.js app, and it was an annoying experience. It sometimes feels like Next.js's build functionality is designed to be overly complicated, pushing developers towards the Vercel deployment platform - while Vercel is also the creator of Next.js.

Nevertheless, we took the challenge and made it work for us. Today, I want to outline our findings.

You will learn:

How to build an optimized Next.js server.
How to make public files work with that build.
How to package the build inside a Docker image.

How we decided to deploy

There are multiple ways to build a Next.js app, either for a server runtime to support all features of Next.js, or for a static runtime with a limited feature set but without the need to operate a server. If you are unsure what this means, read here first.

We utilized the full feature set of Next.js and therefore need a server runtime. While Vercel, or any other kind of easily deployable adapter tooling sounds nice - read here for more infos about adapters - we are bound to Azure, which does not offer an easy solution for the moment.

So we decided to build a Docker Image with our Next.js application and deploy it to a container runtime service, specifically Azure App Service.

Build the Next.js app standalone

Our first step to build the Next.js app for a Docker container is a standalone build. You activate it by setting the output parameter in the next.config.js accordingly.

// next.config.js
module.exports = {
  output: 'standalone',
}

After running next build, the .next/standalone folder of your project includes a simple server.js entrypoint together with a stripped-down node_modules folder including all your dependencies. The build is ready to run.

If you want to test it at this point, run:

node ./[...]/.next/standalone/server.js

Add static resources

After building the standalone Next.js app, you might wonder why public resources are not working. To fix it, you need to copy the public folder of your Next.js app to the .next/standalone build directory, together with the .next/static folder.

cp -r public .next/standalone/ && cp -r .next/static .next/standalone/.next/

FYI: If you are working on a serious production-level build, you should consider a **CDN* at this point. Both the static Next.js build files (.next/static) and the public resources could also be distributed by a CDN as they do not include any server runtime.*

Next.js supports splitting the server and the static files. For high-scaling applications, a CDN might be the better solution. We decided not to take this route to decrease complexity for our setup.

At this point your build is ready, either to be used as-is, or to be packed into a container image.

Building a Container Image

When following the official Next.js guide to Dockerize Next.js, you will come across a multi-stage container build, see this documentation.

In our opinion, this is often more complex than necessary, especially if your build process already runs on a CI/CD pipeline runner. The standalone output already includes the stripped-down node_modules and everything needed to run the application. A simpler, single-stage Dockerfile keeps things straightforward and easy to understand. It avoids duplicating the build process inside the container, which you have likely already run on your machine or in a pipeline.

This is how your Dockerfile could look like:

# Final production stage using a fixed Alpine Node image.
FROM node:20-alpine
WORKDIR /app

ENV NODE_ENV=production
# Uncomment the following line in case you want to disable telemetry during runtime.
# ENV NEXT_TELEMETRY_DISABLED=1

# Create only the non-root 'nextjs' user (and its default group, also named 'nextjs')
RUN adduser --system --uid 1001 nextjs

# --- IMPORTANT ASSUMPTION ---
# This single-stage Dockerfile relies on the following directories
# being present in the local build context (pre-built application):
# ./.next/standalone, ./.next/static, and ./public

# Copy standalone output (server.js, node_modules, traced files) and set ownership
# Ownership is now set to 'nextjs' user and its primary group (also 'nextjs')
COPY --chown=nextjs:nextjs ./.next/standalone ./
# Copy static assets (e.g., built JS, CSS files)
COPY --chown=nextjs:nextjs ./.next/static ./.next/static
# Copy public assets (e.g., favicon, robots.txt)
COPY --chown=nextjs:nextjs ./public ./public

# Switch to the non-root user
USER nextjs

EXPOSE 3000

ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

# Start the Next.js server
CMD ["node", "server.js"]

This Dockerfile already copies the public and static directories to the correct place. So you just need to build standalone before to use it.

Wrap Up

And that's it! We have successfully built a production-ready Next.js application, packaged it into a simple, single-stage Docker image, and made sure all our static and public assets are included.

This approach is perfect for deploying to container runtimes like Azure App Service, Google Cloud Run, or AWS Fargate.

About me

My name is Florian, I am a platform engineer who wants to share his dev experience with you, hoping it makes us all a bit smarter. Please let me know what you think about my post!

In case you want to see more of my posts, you can also find me on X.com, where I share all of my content + daily dev news.

How to move resources between subscriptions in Azure

Florian Demel — Sun, 23 Nov 2025 12:55:02 +0000

TL;DR

Moving resources in Azure is a powerful capability, but it's not easy. The official documentation can be a maze, making it impossible to plan with all different requirements. The biggest watch-out is for your Infrastructure as Code state, as resource ID changes will break it, requiring manual state fixes. The practical path forward is often a hybrid one: move the truly irreplaceable resources, but don't be afraid to recreate everything else. It might just be faster.

Introduction

Have you ever thought about moving resources in Azure? About moving resources that are part of a production workload to other resource groups, subscriptions, or even regions?
I did, and the conclusion was always: Avoid the hassle and just keep things as they are.

Today I want to tell a story about my first move of a production workload from one subscription to another, and the lessons I learned doing so.
This post will show you the important practical steps and a summary of the theoretical details about moving resources between resource groups and subscriptions.

How Microsoft wants you to act

When following the many MS Learn documentation available for Azure resource migration, you might become a bit confused reading about all the requirements you need to comply with. That is absolutely relatable, as there are so many different requirements regarding the relation of resources, their current place, or their networking setup.

For example, moving an Azure App Service has several requirements. The App Service and its corresponding App Service Plan must be in the same resource group to be moved together. To make it more complex, they must be moved from the resource group where the App Service was originally created. This means you first have to move the App Service Plan into the App Service's original resource group before you can move them together to a new subscription.

Why do I tell you about that? I want to make it obvious that you can not foresee all of these rules by reading one simple documentation, first because Azure documentation is too scattered and second because the rules of moving resources are too opaque.

Nevertheless, there are two high-level rules that always apply:

You need to follow the basics. Azure generally does not allow the move between different Azure tenants. It does not move resources from or to a Cloud Solution Provider (CSP), one of Azure's partner companies. And it needs an active subscription. Just remember, if you are using a typical tenant with typical subscriptions, you will probably be fine. All basic rules are collected by Azure in their move resources MS Learn page.
You need to determine whether a resource is meant to be moved at all. There are 3 different move operations in Azure, a move to another subscription, to another resource group or to another region. No matter which one you need, there is a MS Learn page that will tell you which resource can be moved in which way.

Besides these 2 rules, many resources have specific rules applying to them. Often there are some limitations documented somewhere. I'd recommend a quick google search to find such document for the resources you are targeting, e.g. Limitations for App Services.

Be aware: Resources might change!

There is one thing that is great about moving resources:

"Despite [some...] restriction[s], [resources] continue to operate normally, and services relying on it do not experience any downtime." - MS Learn

This is what makes the move possible, because you do not need to worry about downtimes in the first place.

But that is not entirely true. While I did not experience any issues with the resources we moved between subscriptions, you need to be aware that things might need to change before and will change after the move:

Networking: The move of networking resources is widely restricted. While moving a VNet is generally possible, public IPs, peerings and resource links can not be moved at all. Follow MS Learn limitation if you need to tackle networking.
Scope Change: With the new subscription, the scope of many cross-resource functionalities changes. Alerts, RBAC and subscription quotas now apply for the new subscription. Be aware that this might break things in your setup.
Resource IDs Change: As the resource IDs in Azure always follow their subscription ID, the resource ID does change with a subscription move. For example:

/subscriptions/901a2c3d-xxxx-xxxx-xxxx-00000000/resourceGroups/rg-production-web/providers/Microsoft.Compute/virtualMachines/vm-web-01

will become

/subscriptions/b54f9a8e-yyyy-yyyy-yyyy-ffffffff/resourceGroups/rg-production-web/providers/Microsoft.Compute/virtualMachines/vm-web-01

This does not only cause Azure dashboards to break, it will also cause all Infrastructure as Code tools, and scripts, to lose their current state with the resources.

Infrastructure as Code

As resource IDs in Azure change with a move, look after your Infrastructure as Code (IaC) setup, and especially its state.

Most software organizations are building upon a setup of Terraform, ARM- or Biceps templates, or any other kind of IaC tools. If you are now starting to work on resources without using IaC, which is required when moving resources, the IaC state will break - a typical issue with IaC tools. Up to now there is no option to move resources with the IaC tools, which would solve the issue.

When moving resources this state out of sync issue can become really big depending on the amount of resources you are moving. But most likely you will corrupt your entire state. That will require you to recreate the entire state manually after the move.

So looking from an IaC point of view, recreating the resources seems a lot easier than manually importing them into your state.

PS: Be aware that Azure offers some features like export for Terraform, which allows you to import existing resources easily. Sadly this did not work for us but might solve your issues with importing the moved resources into your state.

Why all the hassle?

"So far so good, but would it not be easier to just tear down all infrastructure and provision it all again? - With IaC that is a quick operation, which makes the resource move easier and more predictable. Why all the hassle?"

A discussion like that will most likely be part of each decision regarding resource moving. And it is absolutely fair, it probably is easier in most cases. Especially if you would need to manually rebuild a big IaC state.

But there are two elephants in the room.

First, there are resources you really do not want to recreate when moving. There might be a database with many TB of data that requires a long lasting backup and restore procedure, or there might be any other resource you might not want to tear down for many other reasons.

For example in my recent project there was an internal reference on one of the KeyVault secrets, that requires a Service Now ticket and a lot of waiting to be referenced again by internal IT. It was one of these things you just do not want to do again. So we decided that moving seems like the easier way.

Second, there are systems that need to be up and running all the time. Recreating such a system would either require to spin up a second copy and hot-swapping the two systems afterward, or just moving the resources entirely. This new level of complexity might tip the scales toward the move quite quickly.

While it is hard for me to answer the question if you should try to move resources, it might be worth a discussion on your side.

Stay Practical

My most important learning is that you should stay practical and just try it out yourself. After going through pages of documentation, your only way to know for sure is to see what happens. Before you touch your production environment, use a testing environment or make some prod-like test cases.

We, for example, used a deprecated service that wasn't doing a lot for the system. Downtime would not affect the system to much and after we moved it, we were sure that it is possible.

At this point I want to recommend Azure Resource Mover, an Azure tool that allows to move resource in the Azure portal. It is simple and gives great feedback before executing the move. You are able to configure the operation you'd like to execute and Azure Resource Mover will check if it might work before executing. Play around with it a bit and you will know what works and what does not.

You should also remember that you do not need to go all-in on moving everything. It is perfectly fine to take a hybrid approach. For some critical resources you absolutely can not recreate — like a database with terabytes of data — the move operation is perfect. For everything else, you might find it is faster to just recreate them from scratch in the new location and move the database into the new setup.

When starting to think about hybrid solutions, you will quickly find a way that could work for you.

What happens when shit hits the fan?

Even if the move process is designed to be safe on Azure`s side, always be prepared for the unexpected.

First, be prepared to handle an unexpected downtime by having a Plan B. Make sure you know exactly how to set things up from scratch if the move fails. If you use Infrastructure as Code, this might just be your standard deployment process to the old environment, but it is a critical fallback to have ready.

For example, we moved all of our resources from one subscription to another without a downtime. Already thinking everything worked out perfect. But while recreating the state in our IaC tool Pulumi, Pulumi decided to destroy an entire resource group because it would not import a resource group correctly in its state. Things will happen...

Second, create backups. Even though the process should not cause data loss, create backups of everything important before you start. You probably will not need them, but it is a simple and essential safety measure.

Finally, do not perform a migration in secret. Keep your stakeholders informed about what you are doing and when. Be transparent about the small possibility of downtimes.

After all, it is not easy, but always remember: Just try it!

About me

My name is Florian, I am a platform engineer who wants to share his dev experience with you, hoping it makes us all a bit smarter. Please let me know what you think about my post!

In case you want to see more of my posts, you can also find me on X.com, where I share all of my content + daily dev news.

How to pass AZ-104 or any other Azure Certificate

Florian Demel — Sun, 09 Nov 2025 10:13:42 +0000

TL;DR

Preparing for an Azure certification like the AZ-104 is not about memorizing everything - it is about understanding patterns in the questions and topics. In this post, I will tell my experience about Azure exam preparation, so you know how to approach your own certification journey.

Introduction

Azure certificates are among the harder to pass certificates available in the software industry. When looking up information online, you will often see comments or posts about how hard to pass some Azure exams are...

I myself was fairly insecure how I should handle preparation for my AZ-104 exam because of that. And it was for the good: You must seriously prepare for your Azure certificate to pass the exam.

As I would have loved to have someone coaching me before approaching my Azure journey. I want to do exactly that for you! Tell you about my pattern-based preparation approach, and give some general information that I would have loved to have on hand.

Where to Start?

Before even thinking about exam prep, make sure to choose the right certificate for your personal situation. There are multiple different certification paths available, inform yourself at Microsoft´s information page or read some posts on your favorite platform (e.g. Dev.to, Reddit ...).

My personal hint when it comes to certificate selection: Match your current skill level. This does not only allow you to prepare for the exam in a reasonable timeframe, it is also the way Azure wants you to move forward. Many exams require certificates as prerequisite for one another. E.g. the AZ-305 professional requires the AZ-104 associate.

For sure you would be able to take multiple exams shortly after one another or skip some certs overall, to show for a job interview that you are at an even higher level. This is exactly what I aimed to do starting my way with Azure. And it might be a strategy that works.

But be aware, that there is not only knowledge required for exams to be learned from Microsoft’s material. There is additional knowledge and experience expected from your professional background with Azure. You might be able to make up for that missing experience with enough learning and preparation, but it is the hard way. Be aware that such a tactic requires more preparation time and exam experience, so it might be a bad choice for someone starting with certificates overall.

Preparation Material

After selecting the right certificate for your personal background and goals, get familiar with the learning material available. Not only the expected amount of knowledge for an Azure exam is huge, also is the material available for preparations out there.

Microsoft Resources

The default preparation material everyone gets to see is on the overview page of each Azure certificate. There are different kinds prepared by Microsoft on their MS Learn platform:

MS Learn: Exam Courses - Microsoft offers self-directed learning courses for each certificate, which covers all topics required for the exam. E.g. For the AZ-104 Microsoft Azure Administrator exam. The Course AZ-104T00-A: Microsoft Azure Administrator.
MS Learn: Documentation - Microsoft offers openly available documentation for all Azure resources and Microsoft products. This is the reference for all topics of your exam and a great tool for information about the ecosystem overall. Even better, the MS Learn page is available in some exams to look up details, so it pays off to have experience using it.
MS Learn: Prep Videos - Some certificates even have dedicated learning videos to get into the topics easier (e.g. the videos to start with the az-104 exam). Even if they are linked at the certificate overview page, I personally did not get involved with them from the start up. Do not make the same mistake and start with these videos into the exam topics.
MS Learn: Learning Assessment - To get a feeling how real exam questions are working, Microsoft offers a practice assessment. A multiple choice quiz with questions close to a real exam. This is a great way to get a feeling for the real exam, but do not become to confident about a high score. Often there is a limited amount of questions and more work needed to pass the real thing reliably.
MS Learn: Exam Sandbox - Besides the practice assessment, which does not use the same UI as the real exam, there is a Exam Sandbox to get familiar with its user interface. It does not include any questions related to your exam but provides a great opportunity to peek into your exam session.

External Resources

While most Microsoft resources are well prepared and a great start, external providers are offering learning resources as well. As there are so many providers and kinds of resource, that I would not be able to list all of them, I want to introduce the two most common types:

External Courses - For additional information about your cert´s topics there are courses available for free on platforms like YouTube (e.g. the channel free code camp offers some great free videos). Also some paid services like Pluralsight or Tutorialsdojo offer courses as an addition to Microsoft´s content with high quality.
Exam Dumps - When searching around YouTube or Google, there are some sites and videos with "real exam questions" coming up for all kinds of certs. These vendors are often trying to sell you some packages including hundreds of "real exam questions". While some of the questions are really close to the ones in the exams, they are many times outdated or served with a wrong answer. These dumps can be a great to get a feeling for the exam questions overall. But be careful when relying to much on this type of material.

Process

Next, we want to look at the most important part of each preparation. You can think of it as 2 major steps towards your exam:

Basic Knowledge: In this first step, you want to understand what the exam is all about.
Deep Dive: In the second step, you need to transfer knowledge and get the context and patterns needed for the exam.

Basic Knowledge

After you made the decision to acquire one of Azure´s exams, you will first need to get into exam´s topics. This is the part where you are preparing for the exam the „good old" way by going through Microsoft´s preparation materials and remembering all the information about Azure´s products.

Your most important overview of the exam topics, is the topic overview of your exams study guide. It is a list of all topics needed for your exam. Make sure to have the guide for your respective exam always on hand. You will find the overview directly at the exam page (e.g. the study guide of the AZ-104 exam). Become familiar with each of the listed topics. Your first step will automatically be the Microsoft Learn exam courses. Focus especially on the practical exercises coming up, which will guide your through a learning version of the Azure Portal, as practical knowledge is fairly likely to be tested in the exams.

I myself intensively went through all the learning paths, and went through most practical exercises for my AZ-104 exam. This took me at least a good 2 days, but was worth it.

After finishing the exam courses, you will feel at least 80% ready for the exam. But do not get fooled to much. After doing your first learning assessment, you will probably be back on the ground. For most exams you might be at around 30% of your preparation journey now - just to throw in a guess. Ask yourself:

Do I feel confident enough to explain all the exam topics to another dev?
Am I missing any of the exams topics?

You should be able to explain each topic of the overview at least on the surface level now. If you are missing a topic, move to different sources besides the learning path. I would suggest to get your hands on one of two other leaning products:

If you are generally unfamiliar with the topics of the exam or Azure,
consider a learning course of an external provider. There might be a freely available YouTube video. Consider a paid one too, if there are no free high quality options. Be careful about one thing: Outdated resource. Most exams do not change often. But if you encounter topics in Microsoft external guides you never heard of before, compare them with the study guide overview.

If you are familiar with the Azure world,
Read the MS Learn documentation about the topics missing or shortcoming in the learning paths. This is feeling hard, but it will get you into all details to understand what’s going on.

Now you should be prepared for all topics of you exam, one last personal hint before moving to the next step: Work with flash cards. I created 500 flash cards for my AZ-104 exam, covering the basic fundamentals of each topic. This helped me a lot to remember all the basic information. A great tool to keep your knowledge fresh and remember things effectively.

Deep Dive

After understanding all exam topics, you probably did some learning assessments already. Maybe you realized, that some of the details required in the questions are really detailed. Maybe you even thought that you would not be able to remember all of the little details about all topics at all. That´s where it gets interesting. To solve this issue, you will need to be able to transfer knowledge, apply it to new situations and find patterns for your exam. That´s what I am calling it the pattern-based approach.

The Deep Dive is - because of that - not only about remembering all topics entirely. It is about finding the patterns in the topics that are relevant for your exam, which will get you through the exam safely. Do be fooled - It is true that you can not learn all details of all products. But you can learn which patterns are used in the question and prepare to transfer these patterns to the questions in your exam. Let’s make an example to show you the twist.

This is a question example as it might appear in the AZ-104 practice assessment:

Question: Your Microsoft Entra tenant and on-premises Active Directory domain contain multiple users.
You need to configure self-service password reset (SSPR) password writeback functionality. The solution must minimize costs.
Which Microsoft Entra ID edition should you use?
Select only one answer.

Microsoft Entra ID Free
Microsoft Entra ID P1
Microsoft Entra ID P2

Answer: Only Microsoft Entra ID P1 and P2 support SSPR, but Microsoft Entra ID P1 is the lower cost option.

To know the correct answer to this question you must be aware of the different Entra licenses and their features. This might have been one of the details about Entra ID that you probably did not remember even with preparation in the first step. But after reading this questions you understood a first pattern: There are multiple Entra licenses with different features.

This is not the only question of all AZ-104 questions related to Entra licenses and the features coming with the respective license. Take a note here: You want to search for patterns like that. If there is a question related to Entra licenses and the features coming with it, be aware of all Entra licenses and all the features coming with the different ones because that might be a pattern coming up for all license tiers and features. Sounds easy right.

To make an example, the following question could be one of the questions coming up in the real exam as well. It could look like this:

Question: Your Microsoft Entra tenant and on-premises Active Directory domain contain multiple users.
You need to enforce MFA for specific SaaS apps integrated with SSO The solution must minimize costs.
Which Microsoft Entra ID edition should you use?
Select only one answer.

Microsoft Entra ID Free
Microsoft Entra ID P1
Microsoft Entra ID P2

Answer: Only Microsoft Entra ID P1 and P2 support MFA with SSO, but Microsoft Entra ID P1 is the lower cost option.

Azure works exactly with patterns like that. Make sure that you focus on patterns and learn all the little details included in the patterns.

But how do you find questions to extract patterns from?

Learning Assessment: Use the questions Microsoft offers in its learning assessments. They are easy accessible and cover many patterns.
Exam Dumps: For everyone, who is searching around for more information online, you probably already found some kind of exam dump. They might not always have the correct answer for all questions, neither are all of these "real exam questions" real exam questions. But these dumps are a great source for patterns as well.

After all, you know your learning type and how you remember information the best way for yourself. But when it is about what kind of information is important for the exam. Focus on Patterns.

Surroundings

Besides the obvious preparation - learning things - there are some soft skills supporting you to pass the exam.

Multiple Choice Questions

Most questions in Azure exams are multiple choice questions. That is great, because these kind of questions are not about the exact details, they are about understanding the options available to cross out wrong answers. Follow one famous rule for multiple choice: Do not get into to much thinking about the right answer, just try to figure out which ones are not the right one.

Time Management, Exam Design & MS Learn

There is not lots of time in your Azure certificates exam, but from my perspective the time is not rushing to fast either. One thing that might get you into trouble is the option to open MS Learn in the exam (which is possible in many, but not all, exams). It is tempting to look up details you do not know. But do not spend to much time doing so. Go through the questions you can answer first, mark the ones you can not answer and before finishing a section of the exam, search for all MS Learn details at once with a fixed number of minutes. So you will be able to manage your time properly.

Be aware that most exams are divided into multiple sections. You will not be able to repeat all question at the end, each sections is like a mini exam that is over as soon as you finished it. So be aware of the structure and plan your MS Learn time accordingly.

Some of the sections are designed, so you can not answer a question twice. Be aware of such details and read the descriptions in the exam carefully. After all, clicking through the exam sandbox is a great way to get the feel for the exam user interface.

Wrap Up

This is the final "pass the exam" checklist:

Take the right exam for your skill level
Get familiar with the available materials
Learn all topics the "hard way"
Use some additional materials, if the Microsoft one are not sufficient for all topics
Focus on patterns and understand them
Do not mess your time management up

Hope you are now feeling ready to finally book an exam ;)