Technology & digital skills

Cloud architecture starts with the workload.

Learn to explain why a cloud design fits a real service. The aim is a defensible set of decisions about users, data, access, resilience, operation and cost.

This is a learning-path guide, not a confirmed course intake. Ask about current availability, syllabus, delivery format, entry requirements, fees and assessment before applying.

Ask about training availability

Check the foundations.

A cloud architecture path is easier to follow when you understand basic networking, application components and the difference between an application and its supporting infrastructure. You should be able to describe what a service does and who depends on it.

Choose a platform for practice, then confirm whether the programme includes hands-on access and any associated charges. A training title alone does not include a vendor certification or exam.

Topics to agree in the syllabus.

Use a representative workload to connect architecture decisions. Avoid selecting services before the access, data and recovery requirements are clear.

Workload discovery: users, traffic patterns, dependencies and operational priorities.
Identity and access: roles, service identities and least-privilege decisions.
Networking and data: boundaries, connectivity, storage choices and information flows.
Resilience: failure modes, backup assumptions and recovery objectives.
Observability: the signals an operator needs to recognise a problem.
Cost and change: estimated usage, budgets, trade-offs and a route to alter the design.

A practical project to discuss.

Design a small booking application for a fictional business with a public website and a staff workspace. Identify which parts can be public, which require authentication and where records are stored.

Write a short failure scenario: the application cannot reach its database, a deployment introduces an error or expected traffic rises. Explain the proposed response and which assumptions must be tested. A diagram should show those boundaries, not merely a collection of product icons.

Useful evidence of learning.

The finished work should help a reviewer understand and challenge the design.

A workload brief and a readable architecture diagram.
An access model covering people and application components.
A small set of architecture decision records with alternatives and trade-offs.
A cost estimate with visible assumptions, not a savings promise.
A recovery exercise and an operational handover checklist.

Test the reasoning.

Ask the learner to explain the design to someone who did not build it. Change one requirement, such as access from another office or a longer data-retention need, and examine the effect.

Practical configuration can demonstrate specific skills, but a training lab is not evidence that a business system meets every security or compliance requirement. Assessment should separate what was built, what was tested and what remains an assumption.

Start with your
actual requirement.

Tell us the work, people and outcome you have in mind. We’ll confirm current scope and availability before agreeing the next step.