Cloud computing means renting IT resources (servers, storage, databases, networking, software) from a provider like Azure over the internet, instead of buying and running your own hardware. You pay for what you use and scale up or down as needed.
This is a favourite exam theme.
Azure uses a consumption-based (pay-as-you-go) pricing model: you are billed only for the resources you actually consume, and you can stop paying at any time by turning resources off. This differs from a fixed subscription or licence-based model where cost is set regardless of usage.
Because Microsoft buys hardware and runs data centres at massive scale across the world, the per-unit cost is lower than any single business could achieve alone. These savings are passed on to customers.
When a question describes 'no upfront cost, pay only for what you use', that is OpEx / consumption-based pricing. When it describes 'automatically adding servers during a traffic spike then removing them afterwards', that is elasticity.
Azure offers several compute models, each suited to a different level of control vs convenience.
A common exam trap is matching the scenario to the right service: 'quick one-off container, no orchestration' equals ACI, not AKS; 'run code in response to an event, minimal management' equals Functions.
Azure Storage accounts provide four core services: Blob (unstructured object data), Files (managed SMB/NFS file shares), Queue (messaging between app components), and Table (NoSQL key-value data).
Blob storage has three access tiers, each a different cost/access trade-off:
Redundancy options protect against data loss:
A common mistake is assuming Archive tier gives instant access, or forgetting that GRS replication to the secondary region is asynchronous, so very recent writes could be lost in a regional outage.
This area is about who can sign in (identity), what they are allowed to do (access management) and how you keep the whole tenant organised, compliant and cost-controlled (governance).
At the centre sits Microsoft Entra ID (formerly Azure Active Directory) — Microsoft's cloud-based identity and access management service.
Entra ID is a separate service from Azure Resource Manager subscriptions but every subscription trusts exactly one Entra ID tenant.
One tenant can be linked to multiple subscriptions, but a subscription only ever belongs to one tenant at a time.
Entra ID provides single sign-on (SSO), multi-factor authentication (MFA) and supports external identities so guest users from other organisations can be invited in (B2B collaboration).
Entra ID Free, Premium P1 and Premium P2 are the tiers — P2 adds Identity Protection and Privileged Identity Management (PIM).
Authentication proves who you are (sign-in, MFA, passwordless).
Authorisation decides what you can do once signed in — this is handled by Azure role-based access control (RBAC).
RBAC uses role assignments made up of three parts: a security principal (user, group, service principal or managed identity), a role definition (what actions are allowed, e.g. Owner, Contributor, Reader) and a scope (management group, subscription, resource group or individual resource).
Roles are inherited downward — a role assigned at management group level flows down to every subscription, resource group and resource beneath it.
Owner = full access including granting access to others; Contributor = full access except granting access; Reader = view only.
RBAC is additive only — you cannot explicitly deny with a role assignment (that is what Azure Policy deny effects are for).
Management groups sit above subscriptions for organising multiple subscriptions under one set of policies — up to 10,000 management groups and a hierarchy depth of six levels.
Azure Policy enforces rules and effects (deny, audit, append) on resource properties, e.g. 'only allow UK South region'.
Initiatives group multiple policies together.
Resource Locks (CanNotDelete, ReadOnly) prevent accidental changes and apply regardless of RBAC permissions.
Tags are key-value pairs for organising resources for cost tracking and reporting — they do not control access.
Mixing up Entra ID (identity/authentication) with RBAC (authorisation) — Entra ID proves who you are, RBAC decides what you can do.
Forgetting resource locks override RBAC — even an Owner cannot delete a CanNotDelete-locked resource without removing the lock first.
Assuming tags affect access — they never do, they are purely for organisation and cost reporting.
Azure and the customer split security duties. For IaaS (VMs) you manage the OS, apps, and data; Azure manages the physical hosts, network and datacentre.
For PaaS Azure takes on more (runtime, OS patching); for SaaS Azure manages almost everything except data, devices and identity.
One thing never moves to Azure, whatever the model: you always own your data, endpoints, accounts and access management.
Security is built in layers, working outward to inward: physical security, identity and access, perimeter, network, compute, application, and data.
The idea is that if one layer fails, another still protects the asset - never rely on a single control.
Microsoft's guiding principle for modern security, based on three ideas: verify explicitly, use least privilege access, and assume breach.
Instead of trusting anything inside a corporate network by default, every request is authenticated and authorised as if it came from an open network.
A unified tool for security posture management and workload protection across Azure, on-premises and multicloud resources.
It gives a Secure Score (a percentage showing how well you follow recommendations) and offers two tiers: the free Foundational CSPM plan, and paid Defender plans that add advanced threat protection for specific resource types (servers, storage, SQL, containers, etc).
Azure Key Vault centrally stores and manages secrets, encryption keys and certificates, so they never sit in application code. Supports hardware security module (HSM)-backed keys for extra protection.
Use the Pricing Calculator to estimate monthly costs for a set of Azure services before you deploy anything. Use the Total Cost of Ownership (TCO) Calculator to compare the cost of running your current on-premises infrastructure against running the same workload in Azure - it factors in things like power, cooling, hardware refresh and staff time, not just compute.
An SLA is a formal Microsoft commitment describing the expected uptime/connectivity for a paid service, expressed as a percentage (e.g. 99.9%, 99.95%, 99.99%). Higher availability commitments usually need extra configuration, such as deploying across two or more Availability Zones or using multiple VM instances in an Availability Set. Free-tier services generally have NO SLA. If Microsoft misses the committed percentage, customers can claim service credits - the SLA is not a guarantee nothing will ever fail, it is a compensation promise.
When an application uses several chained services, the overall (composite) SLA is the multiplication of the individual SLAs, so it is always lower than any single component's SLA. For example, two services each rated 99.9% combine to roughly 99.8% overall - a common exam trap is assuming the composite SLA equals the highest individual figure.