FIT5225 · Cloud Computing And Security
The Complete Exam Bible · S1 2026Cloud Computing and Security
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. 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.
What FIT5225 covers
Seven topics climbing one abstraction ladder → one quiz-ready map. Each links to its free chapter guide.
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 |
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.
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.
