Microsoft AZ-104: What to Learn Next

Microsoft AZ-104 gives an Azure administrator a wide operational base: identity and governance, storage, compute, virtual networking, monitoring, and recovery all sit inside the current role. Finishing the exam can therefore create a strange problem. You know more of Azure than before, but the platform is still too large for “learn more Azure” to be a useful career plan.

The productive move after AZ-104 is to look at the work you enjoyed while preparing and the incidents you would actually like to own. Some administrators are drawn toward architecture because they like balancing constraints before deployment. Others keep going deeper into networking, automation, security, or platform operations. None of those directions is automatically more senior. They reward different kinds of judgment.

The Microsoft AZ-104 exam and the Azure Administrator Associate certification are most useful as a foundation for that decision because they expose you to several parts of the environment. The question after the exam is which of those parts you want to understand well enough that other people can depend on you when it breaks.

Make sure the administrator foundation survives without the portal

Before specializing, test whether your AZ-104 knowledge is operational. Can you explain why a role assignment is ineffective at a particular scope? Can you follow traffic through a virtual network and identify where it is blocked? Can you recover a resource, interpret monitoring evidence, or tell whether a storage problem is caused by identity, networking, configuration, or the client?

Portal familiarity can hide gaps because the interface exposes the available choices and often suggests defaults. Try the same tasks through PowerShell, Azure CLI, and infrastructure-as-code templates where appropriate. You do not need to abandon the portal; you need to understand enough of the underlying model that a changed interface does not change your reasoning.

Build a small environment and keep it for several weeks. Add identities, policy, storage, compute, networking, monitoring, and backup. Then change it. Move resources. Rotate credentials. Restrict access. Introduce a bad route. Break DNS. Restore from backup. The most useful exercise is not creating the environment; it is explaining what happened after you disturbed it.

This gives you a baseline for specialization. If networking failures consistently feel interesting, that is evidence. If identity and policy work holds your attention while application issues do not, that is evidence too. Career direction becomes easier when it comes from repeated work rather than from certification names.

Architecture changes the question from “how” to “why this design”

An administrator usually enters a problem after some important design choices have already been made. A solutions architect has to make or defend those choices before implementation. That means translating business requirements into technical constraints and accepting that the “best” service in isolation may be wrong for the system.

Availability, latency, data residency, recovery objectives, security, cost, team capability, and migration risk can pull a design in different directions. Architecture work is learning to rank those pressures and document the consequences.

AZ-104 administration and AZ-305 architecture overlap technically but differ in responsibility. Administrator experience helps architecture because you already know what operational friction looks like. Architecture study helps administration because it explains why environments were designed with certain boundaries, dependencies, and failure patterns.

If you are considering architecture, practice with design records rather than only diagrams. Take an existing workload and write the requirements first. State the recovery target, expected traffic, sensitive data, identity model, deployment pattern, budget pressure, and operational ownership. Then design. When one requirement changes, revise the design and explain what else moves with it.

That exercise tells you quickly whether architecture is genuinely interesting or whether you prefer being closer to implementation and troubleshooting.

Networking rewards administrators who want to understand the path end to end

Azure networking becomes a deep specialty once you move beyond creating virtual networks and subnets. Hybrid connectivity, route propagation, DNS, private endpoints, load balancing, firewalls, hub-and-spoke topologies, Virtual WAN, and cross-region design all create failure modes that are difficult to diagnose without a clear packet-path model.

If you enjoy asking “where exactly did the traffic stop?” networking can be a very strong continuation from AZ-104. The administrative base is useful because network behavior is tied to identity, service endpoints, platform resources, monitoring, and governance.

The difference between Azure administration and Azure network engineering becomes obvious in troubleshooting. An administrator needs enough networking to deploy and operate resources safely. A network engineer goes deeper into connectivity design, routing behavior, security boundaries, name resolution, resiliency, and performance across the environment.

A good networking project is not another clean lab. Connect two environments in different ways, add a private service, control egress, introduce conflicting routes, and capture the evidence you would use to isolate failures. Draw the path before opening the portal. If the drawing is wrong, fix the model first.

Automation becomes valuable when you are tired of solving the same class of problem twice

AZ-104 includes enough repetitive administration that automation opportunities appear quickly. Resource creation, access reviews, tagging, inventory, compliance checks, reporting, configuration, and remediation are all poor candidates for endless manual repetition.

The first step is usually not a large DevOps pipeline. It is making one repeated task safe and reviewable. Put a script or template in source control. Parameterize it. Separate secrets from code. Add validation. Make the output observable. Run it in a test subscription. Let someone else review the change.

From there, infrastructure as code and deployment automation become easier to understand because they solve a problem you have already felt: manual state drifts and repeated clicks do not scale. Bicep, ARM templates, Terraform, PowerShell, Azure CLI, GitHub Actions, and Azure DevOps can all participate, depending on the environment. As automation expands, DevOps engineering brings source control, CI/CD, observability, release safety, secrets management, rollback, and operational feedback into the same delivery system.

Automation is also a good test of how well you understand administration. A manual process can hide uncertainty because you make small decisions as you click. Code forces assumptions into the open.

Security depth starts with understanding why access was possible

Every Azure administrator works with security, but specialization begins when security questions become the main problem rather than one part of administration. Identity, privilege, policy, network boundaries, workload hardening, secrets, posture management, and evidence all become deeper areas of responsibility.

A useful exercise is to investigate your own lab as though you did not build it. Which identities can change critical resources? Which secrets exist and where? Can a compromised account move laterally? Which network paths are exposed? What logging would prove what happened? Which controls are preventive, and which merely tell you afterward?

Do not treat security as a list of features to enable. Controls interact with operations. A restrictive policy that administrators routinely bypass is not strong security. A private service with broken monitoring can create a different risk. The skill is finding a design that reduces exposure without making the environment impossible to operate.

This is also where Azure administration often intersects with Microsoft Entra ID and broader cloud-security work. Deep identity knowledge is particularly valuable because permissions and authentication sit behind so many apparent “Azure problems.”

Platform engineering keeps you close to administration but changes the customer

Some administrators discover that they do not want to specialize in a single Azure technology. They want to make the platform easier for other engineering teams to use. That is the beginning of platform engineering.

The customer becomes another technical team. Instead of asking only whether you can deploy a compliant network, you ask whether application teams can obtain an approved network pattern without filing a bespoke ticket. Instead of creating one monitoring setup, you create defaults that every workload can inherit. Instead of manually reviewing every resource, you encode guardrails.

This work can include landing zones, policy, role design, reusable infrastructure modules, naming and tagging standards, network patterns, observability, cost controls, golden paths, service catalogs, and automated provisioning. It uses broad administrator knowledge but applies it to consistency and developer experience.

Platform engineering is a good direction for someone who enjoys Azure as a system and wants to improve how teams consume it. It also exposes a different kind of operational challenge: a platform feature is only successful if teams can adopt it without constantly escaping the standard.

Use real work to decide which branch deserves another year

Do not choose a specialization from its exam outline alone. Give each plausible direction a small but serious project. For architecture, redesign a workload against explicit constraints. For networking, build and troubleshoot a multi-segment topology. For automation, turn a manual process into reviewed code. For security, perform an access and exposure assessment. For platform engineering, create one reusable pattern another team could consume.

Then compare the work, not the labels. Which project made you curious enough to keep digging after the requirement was met? Which failures did you want to understand instead of simply fix? Which skills appear in the jobs available to you?

AZ-104 is broad enough that it can support several careers. Its value after the exam is not that it tells you which credential to collect next. It gives you enough exposure to recognize the type of Azure problem you want to become unusually good at solving.