Why I Earned Two Azure Fundamentals Certifications

In November 2025, I earned Microsoft Certified: Azure Fundamentals (AZ-900) and Microsoft Certified: Azure AI Fundamentals (AI-900).

After 28 years in software engineering, I did not pursue fundamentals certifications to prove that I had just discovered cloud computing or artificial intelligence. I pursued them because I wanted a current, structured understanding of Microsoft’s platform and vocabulary before offering modernization and AI consulting to oil and gas companies in the Permian Basin.

Azure is common in enterprise and oilfield environments because it connects cloud infrastructure, Microsoft identity, data platforms, integration services, analytics, developer tooling, and AI. I wanted to understand how Microsoft positioned those pieces, where the responsibility boundaries sat, and how the newer AI capabilities could fit real operating workflows.

The certifications became a bridge between experience I already had and platform depth I wanted to build next.

Experience does not eliminate the need to refresh

Long experience gives an architect pattern recognition. It can also create blind spots if familiar answers become automatic.

Cloud providers change quickly. Service names, identity models, deployment choices, governance tools, pricing structures, AI capabilities, and recommended architectures evolve. A design that was sensible several years ago may now have a safer or simpler managed option.

Studying AZ-900 forced me to revisit the platform from first principles: cloud service models, shared responsibility, regions and availability, identity, governance, cost, security, and support. AI-900 added machine learning workloads, computer vision, language, generative AI, and responsible-AI concepts.

Fundamentals do not create production expertise. They create a shared map. That map makes deeper learning and better technical conversations possible.

Why Azure mattered to my consulting direction

My goal was practical: help local oil and gas companies improve aging or disconnected software, integrate field and office workflows, move appropriate workloads to the cloud, and use AI where it could produce a measurable result.

For many of those companies, modernization cannot begin with a blank slate. Existing Microsoft identities, Office 365, Windows environments, SQL Server databases, vendor applications, SCADA systems, and reporting tools shape the options. Azure can provide a path that works with those realities.

The architecture still has to begin with the business problem. A company does not need “Azure” as an outcome. It may need a field workflow that survives lost connectivity, a governed API between acquired systems, a faster production-reporting process, better recovery evidence, or a safe way to search internal operating knowledge.

Platform knowledge helps translate that outcome into responsible options.

What AZ-900 added to the conversation

Azure Fundamentals covers the cloud operating model as much as individual services.

The most useful themes for architecture were:

• the division of responsibility across infrastructure, platform, and software services;
• regional design and availability choices;
• identity and role-based access through Microsoft Entra;
• governance through policy, management structure, and cost controls;
• the difference between capital and consumption-based spending;
• the support and lifecycle implications of managed services.

Those ideas affect build-versus-buy decisions, landing zones, workload ownership, and production readiness. They also create useful questions. Who owns the platform? Which team owns the workload? What happens when consumption grows? Which control is provided by Azure, and which remains ours?

What AI-900 added

Azure AI Fundamentals gave me a structured view of common AI workloads and responsible-AI concerns. The biggest value was not learning product names. It was reinforcing that an AI feature is still a software system with data, security, evaluation, operations, cost, and human consequences.

For oil and gas, promising use cases may include document retrieval, maintenance support, exception summarization, field knowledge access, data-quality assistance, and workflow automation. The right first use case should be bounded, measurable, and low enough in authority that the organization can learn safely.

AI should not be placed directly in a control loop or trusted to resolve ambiguous operational data because its output sounds confident. It needs grounding, evaluation, identity, tool restrictions, audit, and a human decision boundary appropriate to the task.

Where the certifications did not make me an expert

AZ-900 did not make me an Azure platform engineer. AI-900 did not make me an enterprise Microsoft Foundry or Databricks operator.

I say that plainly because certification claims lose value when they are stretched beyond their level. My deeper evidence comes from software architecture, application delivery, integration, cloud-hosted systems, infrastructure as code, CI/CD, and oil and gas work. The certifications show that I deliberately connected that experience to Microsoft’s current cloud and AI foundation.

The next step had to involve building.

How the learning led to WellOS

The certification work made me think more concretely about a market I already knew. Smaller and midsize oil and gas companies often need better operational software but may not be able to afford the largest enterprise systems and implementation programs.

That led me to start WellOS, a personal project exploring a more accessible operating platform for upstream workflows. It brought together field work, wells, production, work orders, revenue, SCADA data, tenant isolation, cloud infrastructure, and administration.

WellOS let me test Azure-oriented architecture ideas against real implementation concerns. It also taught me that the business would require substantial funding and support to launch responsibly. Oil and gas systems are complicated, and an affordable product still has to pay for integration, data migration, security, customer onboarding, field support, and domain validation.

I stopped the product effort in January 2026. The certification goal still held: learn the platform, use it to ask better questions, and find responsible ways to help companies modernize.

The standard I use for certification study

A certification is worth the time when it changes what I can do next.

I want study to produce five things:

1. Vocabulary: I can communicate accurately with platform specialists and business leaders.
2. Decision structure: I understand which tradeoffs a service or pattern introduces.
3. Hands-on evidence: I can build a bounded workload and test the assumptions.
4. Honest limits: I know which responsibilities still require deeper expertise.
5. A learning path: I can identify the next capability that matters for the work I want to do.

That is also why I moved from the fundamentals toward the Azure AI engineering path. The goal is not a longer badge list. It is stronger judgment about secure, governed AI applications in a real enterprise environment.

What I would tell another experienced engineer

Do not let the word “fundamentals” make you dismiss structured learning. And do not let a credential tempt you to overstate what it proves.

Use the material to update your mental model. Connect every service to a business scenario. Build something that crosses identity, data, delivery, observability, and recovery. Then be candid about the difference between what you studied, what you implemented, and what you have operated at scale.

Experience and current learning are not competing signals. Together, they show that an engineer can carry durable judgment forward without becoming trapped by yesterday’s tools.

Sources and related reading

• Microsoft Certified: Azure Fundamentals
• Microsoft Certified: Azure AI Fundamentals
• Why I Started Building WellOS
• What Building WellOS Taught Me About Oilfield Software