Cloud engineers in Africa: the skills are here. How do we recognise them?

“Increasingly versatile profiles”

The first observation: new roles are emerging, often as people grow from one job into the next.

Within your community, both on the continent and in the diaspora, what kinds of cloud profiles are you seeing emerge?

I’m seeing more and more versatile profiles: sysadmins who’ve become cloud engineers, DevOps engineers, platform engineers, SREs, cybersecurity specialists. What strikes me is how many African engineers can move comfortably between very different technology environments, often with limited resources. Many of them master Linux, traditional infrastructure, virtualisation, cloud and automation all at once.

We’re also seeing African professionals earn demanding international credentials such as Kubestronaut and Golden Kubestronaut. These journeys are encouraging, but they only show part of the talent on the continent. That’s why I invest my time in local communities connected to global ecosystems. The goal isn’t to import skills that supposedly don’t exist here. It’s to help the talent that’s already here meet, grow, contribute and get noticed.

What the field teaches you

The constraints usually described as handicaps (unstable connectivity, tight budgets, mismatched hardware) actually forge a particular kind of engineer.

What do these engineers master on the ground that never shows up on a CV?

Their ability to adapt. In our environments, a single engineer might have to work on physical hardware, a hypervisor, a Linux system, a network, a Kubernetes platform and several cloud environments. They often have to deal with limited connectivity, tight budgets, equipment shortages or a lack of specialist support.

That versatility builds an essential skill: understanding technical principles beyond specific products and vendors. A great cloud engineer doesn’t just know how to use a platform. They understand the fundamentals of infrastructure: compute, storage, networking, security, automation, resilience and operations.

The question that makes the difference

How does a recruiter tell someone who knows a tool from someone who truly understands the cloud? Lionel Sakiti answers wearing both hats.

How do you check that a candidate really knows the cloud?

As an infrastructure lead, I look at technical and operational mastery. I ask engineers to walk me through an architecture they’ve built, explain their choices, troubleshoot an incident or propose a recovery strategy after an outage. One question I find particularly revealing is: “If tomorrow we switched cloud providers or technologies, which parts of your architecture would still hold, and which would need to change?” I also value reproducible labs, open-source contributions, documentation and post-mortems.

From a CIO’s perspective, I’m looking for the ability to create value. What business problem does this architecture solve? How does it ensure availability and service continuity? What does it cost? How does it protect data and meet regulatory requirements? What vendor lock-in risks does it introduce? A great cloud engineer should be able to explain their choices to an operations team and to the executive committee alike.

His question about switching providers goes well beyond a job interview. It reveals a fundamental requirement: the ability to design interoperable, scalable and reversible architectures, without excessive dependence on any one technology or vendor. For Lionel Sakiti, mastering technology choices and the ability to migrate is a key lever of digital sovereignty and strategic autonomy for organisations.

Certifications: “supporting evidence”

What role do certifications play today?

They matter for the international recognition of skills. They give structure to learning and provide recognised benchmarks. But we need to separate two things. One is mastery of a specific technology or vendor, which a specialist certification can prove. The other is architecture and integration skill: choosing the right technologies, making them work together and evolving them over time. So I see certifications as supporting evidence, never as the only measure of competence.

Are they suited to the realities on the ground in Africa?

They have one fundamental advantage: an African engineer is assessed against international standards. That’s a powerful form of recognition. But several barriers limit access: the cost of training and exams, access to stable connectivity, payment methods, English proficiency and access to hands-on labs.

There can also be a gap with the reality of our infrastructure. Our organisations run physical servers, virtualised environments, private and public clouds and legacy applications all at the same time. They must meet requirements around security, data protection, sovereignty and cost control. A specialist certification is still relevant, but it doesn’t necessarily capture all of that complexity.

The barriers to certification (exam costs, internet quality, payment methods and language) do not necessarily reflect the skill level of African engineers. Above all, they reveal unequal access to international recognition. A professional can have solid technical expertise, built and proven in the field, without the means to get it certified. A missing certificate should never be mistaken for missing skills.

What a certification should assess

In your view, what should a certification evaluate to recognise these real-world skills?

I’d like assessments to give more weight to problem-solving, regardless of the technologies involved. An engineer should be able to show they can:

• design an architecture that fits technical and budget constraints;
• compare several solutions without relying on a single vendor;
• integrate proprietary and open-source technologies;
• troubleshoot an incident and restore a service;
• automate, secure and monitor an infrastructure;
• plan for reversibility, interoperability and lock-in risks;
• document their work and pass on their knowledge.

The idea isn’t to replace existing certifications, but to complement them with concrete proof of skill.

That list describes an assessment very different from a multiple-choice quiz on a tool: real scenarios, budget constraints, more than one valid answer. In other words, judging an engineer the way the field judges them.

Closing thoughts

“Our challenge isn’t just bringing global technologies to Africa. It’s enabling African talent to take part in designing, evolving and governing them. The people are already here. Let’s give them more visibility, more international connections and more opportunities to show what they can do.”

Building Africa gives a voice to the people building the continent’s digital future. Follow the Building Africa page so you don’t miss a story.