FIT5225 Cloud Computing and Security
The Complete Exam Bible · S1 2026FIT5225 Overview
- Monash University
- S1 2026
- 7 chapters
- Information Technology
Cloud Computing and Security climbs a single ladder of abstraction — physical machine → virtual machine → container → orchestrated container → managed service → function — and at each rung asks who controls and who secures the stack.
- Assessed by A2 — Multicloud app (group) 40% · A1 — CloudEco (individual) 30% · Quiz 1 (invigilated) 15% + 1 more
- Key terms Shared-responsibility model, Container, Orchestration, Idempotent
- How to prepare Treat this as two different games.
- Most asked What do the FIT5225 quizzes actually test?
How FIT5225 is assessed
| Component | Weight | Format |
|---|---|---|
| A2 — Multicloud app (group) | 40% | Build & deploy across more than one cloud · IaC · teamwork + individual report |
| A1 — CloudEco (individual) | 30% | Build a scalable AWS app · justify the design · model file by student-ID |
| Quiz 1 (invigilated) | 15% | Conceptual recall + applied reasoning · treat as closed / no bring-in |
| Quiz 2 (invigilated) | 15% | Conceptual recall + applied reasoning, later weeks · no final exam |
What FIT5225 covers
Seven topics climbing one abstraction ladder → one quiz-ready map. Each links to its free chapter guide.
Cloud Foundations
NIST 5 characteristics · IaaS/PaaS/SaaS · shared responsibility · virtualisation · Type-1 vs Type-2Cloud Foundations pins down what “the cloud” actually is — a precise, published definition rather than a marketing word — and then drops one level to the technology that makes it possible: virtualisation.
- The NIST definition & the five essential characteristics
- Service models: IaaS / PaaS / SaaS — who manages what
- The shared-responsibility model: security OF vs IN the cloud
- Deployment models (public / private / community / hybrid) & cloud economics
- Virtualisation & the hypervisor: Type-1 vs Type-2, full vs para
- Resource virtualisation & live vs cold migration
Containers
Containers vs VMs · Docker engine · images, layers & registries · the Dockerfile · ComposeContainers are the next rung above the virtual machine on the abstraction ladder.
- Containers vs virtual machines — shared kernel, the isolation trade-off
- Docker architecture: client → daemon → containerd → runc
- Images, layers & registries — read-only layers, content-addressed
- The Dockerfile — instructions, layer caching, COPY vs ADD, RUN vs CMD
- Worked example: reasoning through a Dockerfile
- Lifecycle, the CLI & Docker Compose for multi-container apps
Container Orchestration
Swarm vs Kubernetes · Raft · control plane vs nodes · Pod/Deployment/Service · declarative stateOne container is easy; hundreds across many machines is the problem orchestration solves. Container Orchestration automates scheduling, scaling, self-healing and networking for containers across a cluster.
- Why orchestration — from one container to a cluster
- Docker Swarm & Raft consensus — one leader, one agreed truth
- Kubernetes architecture — control plane vs worker nodes
- Kubernetes objects: Pod → ReplicaSet → Deployment → Service
- Declarative desired state & the reconciliation loop
- Scaling: replicas, self-healing and rolling updates
Web Services and SOA
REST vs SOAP · XML vs JSON · safe & idempotent verbs · monolith vs SOA vs microservicesOnce your code runs in containers, it has to talk — this chapter is how services expose and consume each other over the network, and how you structure a system out of them.
- SOAP vs REST — protocol vs architectural style
- HTTP methods & REST constraints — safe, idempotent, stateless
- XML vs JSON, and URL vs URI vs URN
- SOA principles → microservices — the central diagram
- Monolith vs SOA vs Microservices — share-everything to share-nothing
- The API gateway's role
AWS and Infrastructure-as-Code
Declarative vs imperative · Terraform/CloudFormation/Ansible · EC2/S3/VPC/RDS/DynamoDB/ELBThis is the chapter that powers the build projects: how to provision real cloud infrastructure repeatably, and the AWS catalogue you provision.
- Why IaC — repeatable, versioned, reviewable infrastructure
- The four axes: declarative vs imperative (+ idempotency)
- The IaC tool catalogue — Terraform, CloudFormation, Ansible, Pulumi…
- AWS global infrastructure: Regions, Availability Zones, Edge locations
- The AWS catalogue: compute (EC2/ASG/ELB), storage (S3/EBS/EFS), databases & networking (RDS/DynamoDB/VPC)
- A reference architecture — matching services to a need
Serverless Computing
Lambda + API Gateway + DynamoDB · event-driven model · cold start · trade-offs vs EC2Serverless is the top rung of the abstraction ladder: you give up the last of the infrastructure and ship only functions.
- The evolution to serverless — bare metal → VM → container → function
- Serverless vs FaaS — don't conflate the two terms
- The event-driven model — triggers, event sources, ephemeral execution
- AWS Lambda — execution model, cold start, limits, pricing
- The canonical pattern: API Gateway + Lambda + DynamoDB
- Pros, cons & when NOT to use serverless
Cloud Security
CIA & the 4 A's · VPC/SG/NACL · Cognito · encryption · defense-in-depth · complianceSecurity is the thread that runs through every other chapter, pulled together here into the capstone.
- Foundations: the CIA triad & the four A's (authN vs authZ)
- The shared-responsibility line, revisited for security
- VPC networking: Security Groups vs Network ACLs (stateful vs stateless)
- Rule order, NAT gateways, and why peering is not transitive
- Identity: Cognito User Pools vs Identity Pools, IAM least-privilege
- Encryption (in transit / at rest) & defense-in-depth
There is no final exam: your mark is two heavy build/deploy projects (70%) — an individual AWS app and a multicloud group deployment — plus two invigilated, conceptual quizzes (15% + 15%). The quizzes reward distinctions, not memory: tell two technologies apart, read a labelled architecture diagram, and recognise a config snippet.
This guide drills exactly those distinctions and doubles as your architecture / AWS reference for the builds.
Worked example · free
Reading a Dockerfile, line by line — the signature quiz skill
COPY requirements.txt placed before COPY . ., and (c) what is the difference between RUN and CMD? FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "app.py"]- +1FROM / WORKDIR:
FROMsets the base image (a slim Python 3.12 layer);WORKDIRsets and creates the working directory for the following instructions. - +1COPY then RUN:
COPY requirements.txt .brings in just the dependency list, thenRUN pip installinstalls the libraries into a new image layer. - +1COPY . . / EXPOSE / CMD: copy the rest of the source, document the listening port, and set the default process the container runs.
- +2(b) Layer caching: dependencies change rarely, source changes often. Copying
requirements.txtfirst lets Docker cache thepip installlayer and skip re-installing on every code edit — a faster rebuild. - +1(c) RUN vs CMD:
RUNexecutes at build time and bakes its result into a layer;CMDsets the default command run at container start and does not create a layer.
requirements.txt is copied first so the pip install layer is cached across source-only changes; RUN runs during the build, CMD runs when the container starts.Key terms
- Shared-responsibility model
- The split of security duties between provider and customer: the provider secures of the cloud (hardware, virtualisation, global infrastructure), the customer secures in the cloud (data, IAM, OS/network config, app code). The line rises as you move IaaS → PaaS → SaaS but never disappears.
- Container
- An isolated, OS-level package of an application and its dependencies that shares the host kernel — lighter and faster to start than a VM, which virtualises a whole machine including its own guest OS. Built from a layered, read-only image.
- Orchestration
- Automated management of many containers across a cluster — scheduling, scaling, self-healing and networking. Kubernetes runs a control plane that continuously reconciles the running state to a declared desired state; Docker Swarm is the simpler alternative.
- Idempotent
- An operation that has the same effect whether applied once or many times. In REST, GET, PUT and DELETE are idempotent (repeating them does not change the result further) while POST is not; idempotency is also why declarative IaC can safely re-run.
- Infrastructure-as-Code (IaC)
- Provisioning and managing infrastructure with machine-readable definition files rather than manual clicks. Declarative tools (Terraform, CloudFormation) describe the desired end state; imperative tools (Ansible scripts) describe the steps. The benefits are repeatability, versioning and idempotency.
FIT5225 FAQ
Is FIT5225 hard?
It is broad rather than deep: seven topic areas across one semester, two substantial build projects, and two conceptual quizzes. The difficulty is breadth and time management on the projects — start them early — while the quizzes reward crisp distinctions you can drill (VM vs container, SOAP vs REST, SG vs NACL). There is no final exam to backstop a weak piece.
How is FIT5225 assessed?
There is no final exam. Your mark is two build/deploy projects worth about 70% — an individual AWS app (around 30%) and a multicloud group deployment (around 40%) — plus two invigilated, conceptual quizzes worth about 15% each. Each piece stands alone; nothing rescues anything. Confirm this year's exact weights and dates on your own Monash Canvas.
What do the FIT5225 quizzes actually test?
Three things, in order of frequency: (1) concept distinctions — VM vs container, Type-1 vs Type-2, IaaS/PaaS/SaaS, SOAP vs REST, SG vs NACL, User Pool vs Identity Pool; (2) architecture-diagram reading — what each box in a VPC, a Kubernetes cluster or a serverless flow does, and what is mismanaged; (3) config-snippet recognition — a Dockerfile, a kubectl command, an IaC block, an IAM/S3 policy.
You read and reason far more often than you author from scratch.
Do I need to be a strong coder for FIT5225?
You need to be able to build and deploy — package an app, write infrastructure-as-code, and stand it up on AWS (and a second cloud for the group project). The quizzes are conceptual, not code-from-blank exams. Most of the marks reward design judgement and the ability to justify why you chose a service or architecture.
Is using AskSia for FIT5225 cheating?
No. AskSia is a study reference written in our own words to mirror what the unit examines — we host none of your lecturer's files, and Sia teaches you the method and the distinctions; it does not complete or sit your assessments. The build projects must be your own work and any GenAI use must follow the unit's disclosure policy.
Questions students ask in each FIT5225 chapter
- What is the single most common quiz trap in this chapter?
- Confusing two of the five NIST characteristics: resource pooling and rapid elasticity. Resource pooling is about the provider sharing one pool of resources across many tenants (multi-tenancy, location independence). Rapid elasticity is about your allocation growing and shrinking on demand. A question that says 'appears unlimited / scale out' is elasticity; 'serves multiple consumers from a shared pool' is pooling. Chapter 01 · Cloud Foundations
- What is the single line that separates a container from a VM?
- The kernel. A container shares the host operating-system kernel and isolates at the OS-process level; a VM runs its own complete guest OS on top of a hypervisor and isolates at the hardware level. Everything else — containers are lighter, start faster and pack denser; VMs isolate more strongly — follows from that one fact. Chapter 02 · Containers
- Swarm or Kubernetes — how do I answer 'which orchestrator'?
- Match power to need. Docker Swarm is simpler, Docker-native and quick to stand up — good for small or simple deployments. Kubernetes is the more powerful, more complex industry standard with a rich object model, large ecosystem and fine-grained control — the default for serious, scalable, multi-team workloads. The quiz wants the trade-off (simplicity vs power), not a one-size answer. Chapter 03 · Container Orchestration
- Is REST 'better' than SOAP?
- Not better, different. The exam-safe framing is protocol vs style: SOAP is a rigid XML protocol with formal contracts and enterprise features (security, transactions), preferred where strong, machine-readable contracts matter; REST is a lightweight HTTP style with JSON, stateless and cache-friendly, the default for public web and mobile APIs. State the trade-off rather than declaring a winner. Chapter 04 · Web Services and SOA
- How do I tell a declarative IaC tool from an imperative one?
- Ask whether the file describes the end state or the steps. Declarative tools (Terraform, CloudFormation) say 'I want this final infrastructure' and compute the diff to get there, so re-applying is idempotent and safe. Imperative tools (Ansible, shell scripts) say 'do step 1, then step 2'. The quiz wants you to classify a tool you may not have seen by which axis it sits on. Chapter 05 · AWS and Infrastructure-as-Code
- If it's 'serverless', are there really no servers?
- There are servers — you just never see or manage them. The provider runs the infrastructure, scales it up and down (including to zero) and bills you per request or per millisecond of execution. 'Serverless' describes your operational experience (no server management), not the absence of hardware. Conflating the term with 'no servers exist' is a common quiz trap. Chapter 06 · Serverless Computing
- What is the difference between a Security Group and a Network ACL?
- A Security Group is a stateful, instance-level firewall with allow-rules only — its return traffic is automatic. A Network ACL is a stateless, subnet-level firewall that supports explicit deny as well as allow, evaluates rules in number order with first-match-wins, and needs an explicit rule for return traffic. Use the SG for instance access and the NACL for subnet-wide allow/deny; this is one of the most over-tested tables in the unit. Chapter 07 · Cloud Security
How to study for the exam
Treat this as two different games. The 70% in the two build projects is won by starting early — pick services, sketch the architecture, get a deployment working, then iterate; nothing here can be crammed the night before.
The 30% in the two invigilated quizzes is won by drilling distinctions: every “X vs Y” in this guide is a likely question, so learn the row that separates them, not just what each one is. Practise three quiz skills cold — telling adjacent technologies apart, reading a labelled architecture diagram, and recognising a small config snippet (a Dockerfile, a kubectl command, an IAM policy).
Because there is no exam to rescue a weak piece, the safest marks are the comparison tables you can reproduce on demand.
