Cloud & IT Career Foundations · Beginner · ~6 hours
Cloud Computing Fundamentals
Understand cloud service models, core infrastructure and the shared-responsibility approach to security.
Status: Catalogue ready. This lesson version is available in review mode while subject-matter, accessibility and assessment checks are completed.
Shared responsibility and cloud operations
Cloud models and shared responsibility
By the end of this lesson
- Compare infrastructure, platform and software service models at a conceptual level.
- Explain why cloud security responsibilities are shared between provider and customer.
- Create a responsibility map that names assumptions, owners and verification evidence.
Cloud changes the boundary, not the need for decisions
Cloud computing provides on-demand access to computing, storage, networking and managed services. Infrastructure services usually give the customer more responsibility for operating systems, configurations and applications. Platform services abstract more of the underlying infrastructure so teams can focus on code and data. Software services provide a finished application with responsibilities that may be concentrated around user configuration, data, access and appropriate use. The labels vary between providers, so the useful question is always: which layer is being operated by whom? The shared-responsibility model describes this boundary. A provider may be responsible for the physical facilities, core infrastructure and the availability of a managed service. The customer may still be responsible for choosing secure settings, managing identities, protecting data, configuring networks, reviewing logs and using the service lawfully. The exact division depends on the service model and contract. “It is in the cloud” is not a security control and “the provider handles security” is not a complete statement. A responsibility map turns a general idea into a practical review. List the service components, the data involved, the provider responsibility, the customer responsibility, the owner, the evidence and the review date. If a boundary is unclear, record the uncertainty and find the authoritative contract or service documentation. Do not infer a compliance claim from a logo or marketing page. Ask what is covered, what is excluded, which region or service version applies and how customers can verify the control. Cloud also changes how capacity and failure work. Resources may be created quickly, identities may be used by automation and a configuration can be copied across environments. That speed is valuable but can amplify a mistake. Use approved templates, separation of environments, change review and clear ownership. New learners should practise with fictional accounts and diagrams rather than creating resources in a real tenant without permission.
Good cloud choices are evidence-led
A cloud design review should connect business outcomes to technical choices. A team may need a customer portal that is available in several regions, a development environment that contains no real personal data and a reporting service that retains records for a defined period. Each need affects the choice of service, identity, network, storage, logging and recovery. Avoid selecting a technology simply because it is popular. Ask what the organisation can operate, what the supplier contract promises and how the design will be tested. Data classification helps decide where information may be stored, who may access it, how long it should be retained and what should happen when it is no longer needed. Encryption can reduce exposure, but it does not fix an overly broad permission or an incorrect destination. Backups, snapshots and replicas may contain the same sensitive information as the primary system. Their access and retention need the same care. A learner should not paste real candidate, customer or employee information into an unapproved cloud tool. The shared-responsibility model is especially important during an incident. If a provider reports a service issue, the customer still needs to know which of its own configurations, identities, integrations or communication processes could affect the experience. If a customer discovers a permission mistake, it should not wait for the provider to redesign the service. Record the boundary, contain the exposure through approved changes, assess impact and involve the right privacy or security owners. A strong review ends with evidence: a diagram, an approved configuration, a test result, a supplier statement, a log sample or a recovery exercise. Evidence should be current enough for the decision and accessible only to people who need it. This turns cloud understanding into an operational habit rather than a one-time architecture document.
Workplace example
Willow Market uses a managed application platform. The provider operates the underlying hosts, while Willow owns customer-data classification, identities, application permissions, logging choices and recovery tests. The team records each responsibility and the evidence that will be reviewed quarterly.
Try this walkthrough
- 1.Name the cloud service model and the layers it abstracts.
- 2.List provider and customer responsibilities without assuming they are identical across services.
- 3.Add data classification, owner, evidence and review date to the responsibility map.
- 4.Identify one question that must be answered from a contract or authoritative service document.
Watch for these traps
- Treating cloud hosting as a transfer of every security responsibility.
- Assuming a provider marketing claim covers the customer's configuration.
- Forgetting that backups, replicas and snapshots may contain sensitive data.
- Creating real cloud resources or uploading real personal data for practice.
Knowledge check
Choose the response you think is strongest. These checks are practice until the course version has passed subject-matter review; graded attempts will be handled server-side.
For the reviewed pilot, answers are checked on the server. This draft result is not yet added to your official learning record.
Practice studio
Make a decision. Test a response. Leave evidence.
Use the case from this lesson to practise judgement without creating a score or changing your course record.
Scenario decision
Willow Market uses a managed application platform. The provider operates the underlying hosts, while Willow owns customer-data classification, identities, application permission…
Choose a response
Branching roleplay
A colleague asks you to move this situation forward. What do you say next?
Evidence workspace
Draft a short known / assumed / next note from the fictional case. Use fictional details only.
This is a session-only practice draft. It is not saved, graded or added to your learning record. Never enter real personal or confidential information.
Practical assignment
Create a fictional shared-responsibility matrix for a managed customer portal. Include six components, provider and customer duties, data classification, evidence, owners and review dates. Do not use real provider credentials or customer data.
Pass this lesson's knowledge check before recording it as complete.
Portfolio evidence
Practical portfolio project
Interpret a fictional cloud architecture diagram and explain its services, responsibilities, risks and likely business outcomes.
Turn the practical project into a bounded evidence record. Save a draft while you work, then submit it for human review when it is ready.
Sign in to save practical evidence. Sign in