From Microsoft Student Partner to Microsoft MVP: My Journey Through Azure, DevOps, and Technology Education
My journey from Microsoft Student Partner in 2014 to Microsoft Certified Trainer in 2020 and Microsoft MVP in 2026, and what teaching, building, and sharing taught me along the way.
In August 2026, I became a Microsoft Most Valuable Professional (MVP).
For many people, an MVP award may look like another professional title, another badge on LinkedIn, or another line on a résumé. For me, it represents something much more personal: more than a decade of learning, teaching, mentoring, building, and sharing within the Microsoft technology community.
My journey with Microsoft started long before the MVP award. It began when I was still a university student, discovering what kind of engineer I wanted to become and what role technology would play in my career.
Looking back, I can see a clear path connecting the different stages:
- 2014: Microsoft Student Partner
- 2020: Microsoft Certified Trainer (MCT), a role I still hold today
- 2026: Microsoft MVP
Throughout these years, I trained students and professionals, mentored young developers, built cloud and DevOps environments, and shared what I learned with others. Becoming an MVP feels like a recognition of that entire journey rather than of a single achievement.
Where It All Started: 2014
My story with the Microsoft community began in 2014, when I joined the Microsoft Student Partner program at university.
At the time, I was mainly a curious student. I was learning software development and exploring different areas of IT, but I did not yet have the perspective I have today.
The program taught me something that shaped my whole career: being a technology professional is not only about learning technologies yourself. It is also about helping other people discover them.
I became more involved in technical activities, shared knowledge with other students, took part in community events, and introduced people around me to Microsoft technologies.
It was an early lesson that has stayed with me ever since:
Technology becomes much more interesting when you learn it together.
A concept that feels complicated when you study it alone can become simple when someone explains it from another angle. A problem that takes hours to solve can sometimes be resolved in minutes when you ask the right person. And explaining something to someone else is often the best way to find out whether you truly understand it.
Those university years planted the first seeds of what would become a major part of my professional life: technology education and community contribution.
From Learner to Trainer
As my technical experience grew, teaching naturally became part of my career. I discovered that I genuinely enjoyed helping people understand technology, and there is something deeply rewarding about watching a student go from "I don't understand this" to building something on their own.
Teaching also changed the way I learn. When you learn something for yourself, it is tempting to stop once it works. When you teach it, you have to understand the reasons behind it. You need to explain not only what to do but why, and you need to know the architecture, the alternatives, the limitations, the common mistakes, and the situations where a given approach should not be used.
That pushed me to go deeper technically.
Over the years, I worked with learners at many different levels. Some were taking their first steps in programming. Others were already developers trying to move into cloud engineering or DevOps. Their questions varied, but the challenge was often the same: technology can feel overwhelming when nobody guides you through it.
That is when I started to see training not just as delivering information, but as helping people build confidence.
Becoming a Microsoft Certified Trainer in 2020
In 2020, I reached another milestone: I became a Microsoft Certified Trainer (MCT).
By then, training was no longer an occasional activity. It had become an important part of my professional identity. The MCT program brings together trainers who combine technical expertise with instructional skills to help learners develop their abilities with Microsoft technologies.
For me, it was a natural continuation of what I had started as a student. The difference was that I was no longer only attending sessions and learning from others. I was now responsible for helping others learn.
Since 2020, I have continued to train and mentor learners while constantly updating my own knowledge. That last part matters, because you cannot remain an effective trainer by teaching the same things forever. Azure services evolve, DevOps practices change, new architectures appear, security requirements become more demanding, Kubernetes and cloud-native technologies keep moving, and artificial intelligence is becoming deeply integrated into modern cloud platforms.
A trainer has to remain a learner. Every course, every new technology, and every student question is another reason to keep growing.
What Training Taught Me About Technology
One of the biggest lessons I learned is that technical knowledge and the ability to communicate it are two different skills.
You can be an excellent engineer and still struggle to explain a complex concept. You can be a great communicator without enough technical depth. The most effective trainers need both, and they need empathy too.
You have to understand where the learner is starting from. If someone has never worked with the cloud, explaining Azure with the vocabulary of an experienced architect will create more confusion than value. Instead, you build step by step:
- Start with the problem.
- Explain the architecture.
- Show the technology.
- Demonstrate it.
- Let the learner experiment.
- Help them understand what happens when things go wrong.
That last step is essential. Real engineering is not only about successful demos. It includes errors, failed deployments, broken pipelines, wrong configurations, security issues, unexpected costs, networking problems, container failures, and systems that behave differently in production than they did in development.
I always wanted the people I trained to understand that reality. My goal was never simply to help someone pass an exam. It was to help them become capable of solving problems.
Building My Expertise Around Azure and DevOps
As my career developed, Azure and DevOps became the center of my technical interests.
What attracted me to Azure was not only the number of services, but the fact that cloud computing brings so many areas of engineering together: infrastructure, networking, identity, security, automation, monitoring, application development, data, containers, Kubernetes, and increasingly artificial intelligence.
DevOps adds another dimension. It is not just about creating a CI/CD pipeline. It is about building a reliable way to build, test, secure, deploy, monitor, and continuously improve software.
Over the years, I have worked extensively with infrastructure as code, CI/CD, containers, Kubernetes, cloud networking, monitoring, automation, and cloud architecture, using tools such as Terraform, Azure DevOps, GitHub Actions, Docker, and Kubernetes.
But the tools themselves are not the most important part. The real skill is knowing how to combine them to solve a business or engineering problem.
A senior cloud or DevOps engineer should not simply know how to create an Azure resource. They should understand why it is needed, how it fits into the architecture, how to secure it, how to monitor it, how much it will cost, how it will be deployed, and what happens when it fails.
That is the mindset I try to bring to both engineering and training.
Training Is Not Only About Technology
After years of working with students and professionals, I realized that a trainer's role is much broader than explaining technical concepts.
People come to training with different goals. Some want their first job. Some want to change careers. Some want to pass a certification. Some are experienced developers moving into cloud engineering, while others already work in IT and need to modernize their skills.
That means a trainer is often also a mentor. You help people decide what to learn next and how to navigate an industry that changes very quickly. And sometimes the most valuable thing you can offer is not a technical answer, but confidence.
I have seen students struggle with technologies that seemed far beyond their reach, then go on to build real projects, pass certifications, find opportunities, and start professional careers. Those moments are among the most rewarding parts of my work, and they remind me why I started teaching in the first place.
Building a Learning Environment
Over time, my involvement in education grew beyond individual training sessions. I became interested in creating an environment where people could learn continuously: how content should be structured, how practical exercises can complement theory, and how learners can move from simple concepts to real-world projects.
For me, practical experience is essential. You can spend weeks studying cloud architecture, but the moment you deploy a real application, configure networking, build a CI/CD pipeline, manage infrastructure with Terraform, or troubleshoot a Kubernetes deployment, the learning changes. You start to see how the components relate to each other, you discover limitations, you meet unexpected behavior, and you learn how to troubleshoot. That is where technical maturity develops.
This is why I always encourage learners to build:
- Don't only read about Azure. Use it.
- Don't only watch a DevOps tutorial. Create a pipeline.
- Don't only study Terraform syntax. Manage real infrastructure with it.
- Don't only learn Kubernetes concepts. Deploy something and troubleshoot it.
The mistakes are part of the education.
Why Community Became So Important
My journey from Microsoft Student Partner to MCT gradually changed how I saw the technology community.
At the beginning, I was mainly a consumer of knowledge. I searched for tutorials, read documentation, attended sessions, and asked questions. Then I became someone who could help others: answering questions, teaching, and sharing what I had learned.
That transition is one of the most important changes in a technology professional's career. At some point, you stop asking only:
"What can I learn?"
and you start asking:
"What can I give back?"
That question changed my relationship with technology. When I solved a difficult problem, I wondered whether the solution could help someone else. When a concept was hard to grasp, I thought about how to explain it more clearly. When I saw students struggling with the same issue again and again, I looked for better ways to teach it.
This is how community contribution becomes part of your professional identity. It does not start with a large audience. It starts with helping one person, then another, and another. Over time, those small contributions become something meaningful.
Becoming a Microsoft MVP in 2026
This brings me to August 2026.
After more than a decade in the Microsoft ecosystem, I became a Microsoft MVP. Microsoft describes the MVP program as recognizing exceptional technical community leaders for their expertise, leadership, speaking, online influence, and commitment to solving real-world problems. The program also gives MVPs opportunities to share their expertise, expand their networks, and give real-world feedback to Microsoft engineering teams.
When I received the news, I thought about how different that moment would have looked to me in 2014. Back then, I was a university student discovering the Microsoft ecosystem. I could never have imagined that twelve years later Microsoft would recognize me as an MVP.
What makes it most meaningful is that the road between those two moments was never built around chasing an award. It was built around learning and helping. The MVP recognition feels less like a destination and more like a reflection of the journey.
What the MVP Recognition Means to Me
There is an important distinction between being technically skilled and being recognized for community contribution. Many excellent engineers, architects, developers, trainers, and technical leaders never become MVPs, and the award does not define anyone's technical worth.
For me, it represents something specific: the combination of technical expertise and a sustained commitment to sharing knowledge and helping others.
That is why I value it. It connects parts of my career that once felt separate:
- The student I was in 2014.
- The trainer I became in 2020.
- The Azure and DevOps engineer shaped by years of technical work.
- The mentor who has worked with students and professionals.
- The community contributor who keeps sharing knowledge.
The MVP recognition brings all of these together.
The Value of the MVP Community
Another reason I value the program is the community itself.
Technology is global. The problems we solve in Tunisia are often similar to those faced by engineers in Europe, North America, Asia, Africa, or the Middle East. At the same time, every community has its own perspectives, constraints, and experiences.
Being connected with other technical leaders creates opportunities to learn from those differences. An Azure architect may approach a problem differently from a DevOps engineer. A trainer may see a technology differently from someone working only in production. A developer may have a completely different view from someone responsible for infrastructure. These different viewpoints make the community stronger.
For someone who has spent years both using and teaching Microsoft technologies, having a closer connection with this ecosystem, and a channel to provide feedback to product teams, is something I genuinely appreciate.
The Responsibility That Comes with Recognition
Recognition also creates responsibility.
If people see you as someone with technical expertise, they may trust your recommendations. That means being careful with what you publish. It means distinguishing between personal experience and official guidance, explaining trade-offs, and admitting when you don't know something.
Above all, it means continuing to learn. Technology changes too quickly for anyone to stay an expert simply because they earned a title years ago. An MVP title does not mean you know everything. If anything, it is a reminder to keep learning.
What I Learned from More Than a Decade of Community Involvement
Looking back from 2026, I understand several things differently than I did in 2014:
- Expertise is a journey. There is no moment when you suddenly become an expert and stop learning.
- Teaching makes you better. Every time you explain something, you are forced to organize your own thinking.
- Practical experience matters enormously. Real projects teach you things documentation cannot.
- Community creates opportunities that technology alone cannot. Some of the most valuable professional relationships begin with a simple technical conversation.
- Helping others is one of the best ways to build a meaningful career. Not because it guarantees recognition (it doesn't), but because it gives your career a purpose.
What I Want to Keep Doing
Becoming an MVP does not change the direction I want to take.
I want to keep working deeply with Azure and DevOps, and to keep developing my expertise in cloud architecture, infrastructure automation, Kubernetes, CI/CD, security, observability, and modern cloud-native platforms. I also want to explore the fast-growing relationship between cloud platforms and artificial intelligence.
Alongside the technical work, I want to keep teaching, mentoring students and engineers, writing, and sharing practical experience. I want to help more people build careers in cloud and DevOps.
There is a lot of talent in Tunisia and across the wider region. Sometimes what people need is not more information, but direction: what to learn first, what to ignore for now, how to practice, how to build a project, how to prepare for an interview, and how to turn knowledge into professional experience. That is where I want to keep contributing.
From a Student in 2014 to an MVP in 2026
When I look at the timeline, the journey feels almost unreal.
In 2014, I was a university student and Microsoft Student Partner, discovering technologies and learning from the community. In 2020, I became a Microsoft Certified Trainer and took on a much stronger role in helping others learn. In between, I spent years developing my expertise, working with students and professionals, building projects, teaching, mentoring, and exploring the constantly changing world of cloud computing. Then, in August 2026, I became a Microsoft MVP.
But the titles are not the most important part of this story. What matters is everything between them: the people I met, the students I trained, the engineers I helped, the technologies I learned, the problems I solved, the mistakes I made, and the lessons that were shared with me along the way.
That is the real journey.
The Journey Continues
Becoming a Microsoft MVP is one of the milestones I am most proud of, but I don't see it as the end of the journey that started in 2014. I see it as another chapter.
Technology will keep changing. Azure will keep evolving. DevOps will keep transforming with platform engineering, cloud-native technologies, and AI. The skills required from engineers will evolve too. That means there will always be something new to learn, and always someone who needs help learning it.
That is what motivates me. More than twelve years after joining the Microsoft community as a student, I still have the same curiosity about technology. The difference is that today I can share it with others.
From a student who wanted to learn, to a trainer who helps others learn, and now to a Microsoft MVP, the direction has remained remarkably consistent:
Learn. Build. Share. Teach. Help others grow.
The MVP award recognizes the road behind me. There is still a long road ahead, and I am looking forward to it.
Mohamed Amine Hlali Microsoft MVP | Microsoft Certified Trainer (MCT) | Azure & DevOps | Cloud Engineer | Technology Trainer & Community Contributor
August 2026
