See Azure Administration as One Connected System

1. Why Azure Administration Exists

If Azure were just a pile of servers, storage, and network switches, administration would be simple. But Azure is really a shared system: Microsoft runs the underlying cloud platform, and you manage the parts your organization controls. That split is the whole reason Azure administration exists.

Think of it like a large apartment building. Microsoft owns the building, keeps the power on, maintains the foundation, and secures the structure. You manage your apartment: who can enter, what gets stored inside, how the rooms are organized, and what gets connected to what. Azure administration is the skill of managing your side of that boundary without confusing it with Microsoft’s side.

That boundary matters because cloud work is mostly about control, access, and responsibility:

• Control: what resources exist and how they behave
• Access: who can use them
• Responsibility: who is accountable for security, cost, and uptime

Once you see Azure this way, the AZ-104 domains stop looking like random exam buckets. They are all different ways of answering the same question: how do you keep cloud resources organized, secure, connected, and usable?

By the end of this course, you will be able to explain Azure administration in plain language, including how Azure resources, identities, networking, governance, and monitoring fit together. You will be able to describe why the AZ-104 topics exist at all, instead of treating them like disconnected commands or menus.

Hold on to this one idea: Azure administration is about governing what you control inside a platform you do not fully own. Everything else in the course hangs from that.

2. The Core Building Blocks of Azure

Remember earlier when we said Azure administration is about governing what you control inside a platform you do not fully own? Now we can zoom in and ask: what exactly are you controlling?

At the simplest level, Azure is made of a small set of building blocks that combine into everything else:

• Identities — who or what is allowed to act
• Resources — the individual things you create and use
• Resource groups — the containers that organize those things
• Subscriptions — the billing and access boundary above them
• Regions and availability — where things live and how resilient they are
• Networking — how things communicate
• Monitoring and governance — how you keep it all safe, visible, and under control

These are not random exam categories. They are the basic ingredients of any cloud environment. Once you understand these, the AZ-104 domains start to feel less like separate topics and more like different angles on the same system.

1) Identity is the first building block

Before anything can happen in Azure, something needs to prove who it is.

That “something” might be a person, a service, a virtual machine, or an app. In cloud systems, identity is the answer to a simple question:

Who are you, and what are you allowed to do?

This matters because cloud systems are not managed by touching a physical machine in a room. They are managed by requests: sign in, create, read, modify, delete. So Azure must know whether the request comes from a trusted person or a trusted workload.

Analogy: Identity is like the badge at a secure office building. The badge does not do the work itself. It simply tells the building what doors can be opened and what areas are off limits.

Remember this idea, because it shows up everywhere later. Even networking, storage, and monitoring all depend on identity in some way. If Azure cannot tell who is acting, it cannot decide what to allow.

2) Resources are the actual things you manage

A resource is any Azure object you create or configure: a virtual machine, storage account, virtual network, key vault, web app, public IP address, and so on.

The key idea is that Azure is not one giant thing. It is a collection of many smaller things, each with a job.

Analogy: Think of a city. The city is not one object. It contains roads, buildings, water pipes, traffic lights, parks, and power lines. Each piece serves a different purpose, but together they form a functioning system.

This is the same idea in Azure. A virtual machine is not “the cloud.” It is one component inside the cloud. A storage account is not “your app.” It is one part of the system your app may depend on.

This matters because cloud problems are often really relationship problems:

• the app cannot reach storage
• the user cannot access the VM
• the resource is in the wrong region
• the permissions are too broad

When you know Azure is a system of separate resources, these issues become easier to diagnose. You stop asking, “What is wrong with Azure?” and start asking, “Which building block is not connected, trusted, or configured correctly?”

3) Resource groups are for organizing by lifecycle

A resource group is a logical container for related resources.

The important word here is logical. It is not a physical box. It is an organizing boundary.

Analogy: Imagine a folder on your desk labeled “New Website Project.” Inside are the design notes, invoices, vendor contacts, and contracts for that one project. When the project ends, you can review everything in one place. A resource group works like that folder.

Why does this matter? Because cloud environments become messy fast. Without grouping, each resource becomes an isolated object floating around by itself. That makes it hard to manage, secure, delete, or track.

A resource group helps answer:

• What belongs together?
• What should be managed together?
• What should be removed together when the project ends?

Remember earlier when we said Azure administration is about control? Resource groups are one of the main ways you impose structure on that control. They do not change what a resource is. They make the environment easier to reason about.

A useful way to think about it:

4) Subscriptions are the boundary for ownership and cost

If resource groups help organize resources, subscriptions help organize responsibility.

A subscription is where Azure tracks things like billing, quotas, and access boundaries. It is often the level at which an organization says, “This set of resources belongs to this team, department, project, or environment.”

Analogy: If resource groups are folders, subscriptions are more like separate accounts at a bank. They keep ownership, spending, and oversight separated.

This separation matters because companies rarely manage Azure as one giant shared pile. They split it by purpose:

• production vs. testing
• department A vs. department B
• one business unit vs. another

Why? Because boundaries reduce confusion. They also help with cost tracking and administrative control.

This is the same pattern we saw with identity: Azure always needs a boundary to decide who can do what, where, and under whose responsibility. Subscriptions are one of the strongest boundaries in the system.

5) Regions and resilience answer the question: where does this live?

Azure resources are deployed into regions, which are geographic areas containing data centers.

At first, this sounds like a location detail. But it is actually a design decision.

Where a resource lives affects:

• latency, or how quickly users can reach it
• data residency, or where data is stored
• resilience, or how well the system survives failure

Analogy: Putting a shop near customers makes it faster to reach. Putting all your inventory in one warehouse makes it vulnerable if that warehouse has a problem. Azure region choices work the same way.

You are always balancing three forces:

1. Speed — closer is often faster
2. Reliability — more separation can reduce risk
3. Compliance — some data must stay in certain places

Remember earlier when we said cloud administration is about keeping resources organized, secure, connected, and usable? Region choice is one of the clearest examples of that. It is not just geography. It is part of system design.

And resilience is the natural extension of location. One building can have a problem. One region can have an outage. Azure gives you ways to reduce the impact, but the first principle is simple: don’t assume a single place is safe enough for everything important.

6) Networking is how the pieces talk to each other

A cloud system is only useful if its parts can communicate.

Networking is the set of rules and pathways that decide:

• what can reach what
• what stays private
• what is exposed publicly
• how traffic moves between services

Analogy: Think of networking like roads, gates, and traffic rules in a city. A building can exist, but if the roads are blocked, nobody can reach it. A private home is useful, but not every door should face the street.

This is why networking is not just “internet stuff.” It is the circulation system of the cloud.

If identity is about who you are, networking is about how things get to each other.

And this is where Azure administration gets very practical. Many cloud failures are not failures of the app itself. They are failures of connection:

• the VM exists but cannot be reached
• the database is deployed but the app cannot access it
• the service is live but blocked by network rules

This is the same idea showing up again: cloud control is not just about creating things. It is about making sure the right things can interact in the right way.

7) Monitoring and governance keep the system understandable

A cloud environment can only stay healthy if you can answer three questions:

• What do I have?
• What is happening?
• Is it following the rules?

That is where monitoring and governance come in.

Monitoring tells you what the system is doing: performance, errors, usage, health, and changes.

Governance tells you what the system is allowed to do: policy, standards, naming, access boundaries, and compliance expectations.

Analogy: Monitoring is the dashboard in a car. Governance is the traffic law and maintenance schedule. One tells you the current state; the other keeps the car operating safely over time.

These are not optional extras. They are what prevent the cloud from turning into a confusing sprawl of resources nobody fully understands.

Remember the apartment building analogy from Section 1. If you own your apartment but never check smoke detectors, door locks, utility usage, or building rules, you may still “own” it, but you do not really control it well. Monitoring and governance are how Azure stays manageable instead of becoming a pile of forgotten settings.

The big picture: the blocks are simple, the system is not

Here is the important insight:

Azure is not difficult because the parts are mysterious. It is difficult because the parts interact.

Identity affects access. Resources depend on location. Resource groups shape management. Subscriptions shape responsibility. Networking determines connection. Monitoring shows behavior. Governance sets boundaries.

That is why AZ-104 is built the way it is. Each domain is really asking you to understand one of these forces well enough to manage a live environment without guesswork.

If you can explain these building blocks in plain language, you are already thinking like an Azure administrator.

And that is the key shift: you are no longer memorizing menus. You are learning the logic of a cloud system.

3. How Azure Admin Tasks Connect

Remember earlier when we said Azure is a system of building blocks — identities, resources, resource groups, subscriptions, regions, networking, monitoring, and governance? Now we can answer the next question:

How do Azure admin tasks actually connect into one working environment?

This is where the course starts to feel real.

Up to now, the pieces may have seemed separate. But in an actual Azure environment, they never stay separate for long. Every admin task touches more than one building block at the same time. A VM is not just a VM. It has an identity, belongs to a resource group, lives in a region, follows network rules, and is watched by monitoring tools. That same pattern repeats everywhere.

Think of Azure like a living city:

• Identity is who gets access
• Resources are the buildings and services
• Resource groups are the neighborhoods
• Subscriptions are the governing districts
• Networking is the roads and gates
• Monitoring is the city dashboard
• Governance is the rulebook

A city only works when all of those layers line up. Azure administration is the work of keeping them aligned.

The real job is not “doing tasks”

This is an important shift.

A beginner often thinks Azure administration means learning separate actions:

• create a VM
• create a network
• assign permissions
• set up monitoring
• apply policies

But that is only the surface.

The deeper job is this:

Make sure the right thing exists, in the right place, with the right access, under the right rules, and with the right visibility.

That sentence is basically the hidden logic behind AZ-104.

If a resource exists but nobody can reach it, it is not useful. If it is reachable but over-permissioned, it is risky. If it is secure but unmonitored, it is invisible. If it is visible but unmanaged, it becomes noise.

Remember the apartment building analogy from Section 1. The building is not safe just because the walls exist. Safety comes from how the doors, keys, alarms, utilities, and rules work together. Azure is the same way.

One change usually affects several layers

This is where cloud administration becomes interesting.

In a real Azure environment, one choice often ripples through multiple parts of the system.

For example, if you deploy a workload in a different region, that can affect:

• latency for users
• compliance rules
• backup strategy
• network design
• cost
• availability goals

So a “location decision” is never just a location decision.

Or if you give a team access to a resource group, that can affect:

• what they can create
• what they can delete
• what costs they can generate
• what they can accidentally expose

So a “permissions decision” is never just a permissions decision.

This is why Azure admins have to think in systems, not in isolated clicks.

Azure tasks are connected because the environment itself is connected.

That is the key idea.

Example: a simple web app is already a system

Let’s make this concrete.

Imagine a company wants a simple internal web app. From the outside, it sounds like one thing. But Azure sees it as a set of related parts:

If any one of those is missing, the app may still exist, but it will not be well managed.

For example:

• The app may be deployed, but the network blocks users.
• The app may run, but the team cannot update it.
• The app may work, but logs are not being collected.
• The app may be useful, but it lives in the wrong subscription and costs cannot be tracked properly.

That is why Azure administration is not just infrastructure work. It is coordination work.

Remember earlier when we said cloud problems are often relationship problems? This is that idea in action. The app is only useful when all the relationships around it are correct.

Access, placement, and control are always linked

Three forces keep showing up again and again:

1. Access — who can do something
2. Placement — where it lives
3. Control — what rules and limits apply

These are not separate topics. They are three angles on the same environment.

If you change access, you change risk. If you change placement, you change performance and compliance. If you change control, you change how predictable the environment is.

Here is a useful way to think about it:

• Identity answers: Who are you?
• Networking answers: Can you reach it?
• Governance answers: Are you allowed to do that?
• Monitoring answers: What is happening right now?
• Resource structure answers: Where does this belong?

When these answers line up, the environment feels coherent. When they do not, the environment feels broken even if all the resources technically exist.

That is why experienced Azure admins look for mismatches first. They ask:

• Is this resource in the right place?
• Does the right identity have the right access?
• Is the network path open?
• Are the logs being captured?
• Is the resource under the right policy and boundary?

Those are not five separate questions. They are one system check.

Why resource groups and subscriptions matter more than they first appear

At first, resource groups and subscriptions can feel like bookkeeping. But bookkeeping is not the right word. They are actually control surfaces.

A resource group is where related things are managed together. A subscription is where responsibility and cost are separated.

Together, they shape the environment’s behavior.

If a team owns a resource group, they can usually manage the resources inside it as a unit. If a subscription is dedicated to production, it creates a stronger boundary between production and test.

That means the structure of Azure is not accidental. It is there to reduce confusion and keep environments from bleeding into one another.

This is also why Azure administration is often about scope.

Scope is the answer to:

• How far does this permission apply?
• How broadly does this policy apply?
• How much of the environment does this setting affect?

Scope is one of the quiet themes behind many AZ-104 tasks. You are always asking: what does this apply to, and what stays outside it?

A locally relevant example: what you would notice first

Imagine you are helping a small company move its customer portal into Azure.

You notice a few things right away:

• The portal should not be in the same subscription as the test environment.
• The web app and database should not be treated as unrelated pieces.
• The team needs access, but not full control over everything.
• The app should be monitored so failures are visible quickly.
• Network access should be limited so only the right traffic gets in.

That is the Azure admin mindset.

You are not just provisioning services. You are shaping a safe operating environment.

If you were to explain this to someone else, you would not say, “I created a bunch of resources.” You would say, “I organized access, placement, network paths, and monitoring so the system could be managed safely.”

That difference matters.

Because the second explanation shows you understand the system, not just the commands.

The exam domains start to make sense now

AZ-104 domains can look unrelated if you treat them like a list. But once you see the system, they start to connect naturally.

These are not separate islands. They are layers of the same environment.

For example, a VM is not only a compute object. It also needs:

• an identity or access path for administration
• a network position so it can be reached
• a region that fits the workload
• monitoring so its health is visible
• governance so it stays within policy

That is why exam questions often seem to involve multiple topics at once. In the real world, they do.

The main mental model to keep

If you remember only one thing from this section, make it this:

Azure administration is the art of keeping many connected pieces aligned so the system stays secure, usable, and understandable.

That is the whole pattern.

Not just creation. Not just access. Not just monitoring. Not just networking.

All of them together.

And once you see that, the remaining course becomes much easier to absorb, because the later topics are just deeper versions of this same idea:

• services depend on structure
• structure depends on scope
• scope depends on identity and governance
• usability depends on networking and monitoring

This is why the course keeps returning to the same core question: what has to be true for Azure to work safely?

Hold onto that question. It will make the next section feel like a natural conclusion instead of a new list of facts.

4. Thinking Like an Azure Administrator

You’ve made it to the point where the course stops feeling like separate facts and starts feeling like a way of thinking. That is the real shift.

Earlier, you saw why Azure administration exists at all: Microsoft owns the platform, but you manage the part your organization controls. Then you learned the core building blocks — identity, resources, resource groups, subscriptions, regions, networking, monitoring, and governance. After that, you saw how those pieces do not stay isolated; they constantly affect one another.

That means you are no longer looking at Azure as a list of services. You are looking at it as a connected system.

What you can now see

You can now look at an Azure environment and ask the right questions:

• Who is acting here? → identity
• What is being managed? → resources
• What belongs together? → resource groups
• What boundary owns this? → subscriptions
• Where does it live? → regions
• How does it connect? → networking
• What is happening right now? → monitoring
• What rules apply? → governance

That is not memorization. That is recognition.

And recognition is powerful, because it means you can take almost any AZ-104 scenario and reduce it to the same few forces: access, placement, control, and visibility. Remember how we kept returning to those ideas? That was not repetition for its own sake. It was the shape of the system showing itself from different angles.

The identity shift

You now think like an Azure administrator when you stop asking, “What button do I click?” and start asking, “What relationship is broken?”

That is a very different kind of skill.

It means you can diagnose faster, explain more clearly, and make safer decisions. You can look at a resource and understand that it is never just a resource — it lives inside a group, a subscription, a region, a network path, and a set of rules. You can also see why a change in one place can ripple into several others.

This is the kind of understanding that makes the rest of AZ-104 feel less intimidating. You are not trying to collect disconnected facts anymore. You are learning how the cloud stays organized.

What this unlocks next

With this mental model, you can now do something much more useful than recite terms:

• explain why a resource is placed where it is
• describe why access is granted or blocked
• understand why monitoring matters even when everything seems fine
• notice when a design is likely to become messy, insecure, or hard to manage

In other words, you can start reading Azure like a system instead of a menu.

That is the real win.

Carry this forward

When you meet a new Azure concept, do not treat it as an isolated fact. Ask where it fits in the system:

Who controls it? What does it depend on? What boundary contains it? How is it connected? How will you know it is healthy?

If you keep thinking this way, the details will have somewhere to land.

You now have the foundation to understand Azure administration with clarity, not guesswork. Keep this model in mind, and every new topic will feel less like something to memorize and more like something you can already reason through.