Cloud Computing

Most people first meet the cloud as a place to put a website, and that framing shrinks it. NIST fixed the term in its 2011 definition with five traits, and each one rules something out. You provision resources yourself, through a console or an API, without asking a person. You reach them over ordinary networks from any kind of device. The provider pools its hardware across many tenants and decides where your share physically sits. Capacity stretches and contracts fast enough to look unlimited from the customer's side. And everything consumed is metered, which is what makes the invoice both fair and hazardous. A rented virtual server you cannot resize yourself in minutes, paid for by the month regardless of use, fails that test however modern it sounds. A company's own virtualised estate can pass it, which is why NIST lists private, community and hybrid deployments next to the public one.

Three things the cloud is not. It is not a cheaper server: a steady workload often costs more there. It is not secure by default: the provider protects buildings, hardware and the virtualisation layer, while identities, network rules and data settings remain yours, and that boundary moves as you choose more managed services. The cloud security topic in our cybersecurity field owns that half. And it is not one product: each platform sells a catalogue so wide that nobody knows all of it, and competence means knowing which small part your problem needs.

Four platforms, one body of knowledge

AWS, Microsoft Azure, Google Cloud and Oracle Cloud Infrastructure sell the same underlying ideas under different labels. A virtual machine, a bucket, a private network, a managed database, a function fired by an event: all four have each of these, and someone fluent on one can read another's documentation within weeks. The differences lie in grain. Azure extends Microsoft's directory and licensing into the data centre; Google Cloud carries the engineering habits of the company where Kubernetes began; Oracle builds around the databases its customers already run; AWS, the longest-running of the four, has the broadest catalogue and the most third-party material. None of that crowns a winner. Employers in your region and the systems already in place decide the question far more often than feature comparisons do.

Twelve topics against the pillars and the exams

The vendors certify in three tiers. Entry papers such as Azure Fundamentals, Cloud Practitioner and OCI Foundations check that you can describe services and pricing. Associate exams, among them Solutions Architect Associate, Azure Administrator and Google's Associate Cloud Engineer, ask you to choose and configure. The top tier, with AZ-305, SAP-C02 and Professional Cloud Architect, hands you an organisation with constraints and asks for a design. Beside the vendor ladders sit the hands-on CKA and the provider-neutral Cloud+. Several doors cost nothing: AWS Cloud Quest, the Cloud Essentials badge, Microsoft's Azure management lab and Oracle's foundations exam itself.

Your first topic depends on the job you hold now, because cloud work is mostly an existing role carried onto rented infrastructure.

• Developers begin with containers, serverless and storage, since those decide how their code is packaged, triggered and fed. Developer Associate tests that ground directly.
• Administrators begin with fundamentals, governance and landing zones, networking and operations, then infrastructure as code, which turns their runbooks into files a colleague can review. Azure Administrator and Associate Cloud Engineer are the matching papers.
• Architects rarely begin as architects. They arrive after years in one of the other two roles and then study architecture and migration, where every answer is a trade-off between the pillars.

Why cost is a discipline here

In a traditional company, spending passes through a purchasing department before any hardware arrives. In the cloud, every engineer with deploy rights is a buyer, and each command that starts a resource signs a small contract. That shift is why the Well-Architected Framework gives cost its own pillar and why the FinOps Foundation built a whole practice around engineers, finance and product owners reading the same figures. We place cost and FinOps beside architecture rather than after it: a design nobody can afford to run is not finished, and the habits that keep a bill honest are learned in the same sprint as the ones that keep a service up.