FIT5225: ace the project, not just read the notes
Your complete guide to Monash University's cloud computing and security unit. See where the marks are, work real practice questions, and study with an AI tutor that knows FIT5225.
Sia generates FIT5225 practice questions, walks through introduction to cloud computing and virtualisation step by step, and quizzes you on the material the project that weights most heavily.
Find what is wrong
A FIT5225 group is provisioning their multicloud app's database tier on AWS with Terraform. The Postgres instance lives in a private subnet and only the application servers (which sit in the security group sg-app) should reach it on port 5432. A teammate writes the security group below. Spot the security bug.
resource "aws_security_group" "db" {
name = "db-sg"
vpc_id = aws_vpc.main.id
ingress {
from_port = 5432
to_port = 5432
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}The requirement is least privilege: only the app tier (sg-app) should reach the database on 5432. The rule as written opens 5432 to cidr_blocks 0.0.0.0/0, which is every IP address, so the database accepts connections from anywhere that can route to it.
Option A is false reasoning: even if the subnet has no Internet Gateway today, 0.0.0.0/0 also allows any host inside the VPC (and any future peered or NAT path), so the rule is still over-permissive. Defense-in-depth means the security group should be tight regardless of the routing.
Option C is wrong because AWS security groups are stateful: return traffic for an allowed inbound connection is automatically permitted, so no matching egress rule is needed for the database to answer. Option D is wrong because security groups are Allow-only; numbered Allow-then-Deny ordering describes NACLs (which are stateless), not security groups.
The trap: Assuming a private subnet makes an open 0.0.0.0/0 security group safe, or confusing the stateful Allow-only security group with the stateless, ordered, Allow-and-Deny NACL. The least-privilege fix is to source the rule from the app security group, not an open CIDR. classic slip!
One project decides 40% of your grade. Assesses ULO2 to ULO6; teamwork and IaC/repo hygiene are part of the mark. This whole page is built around that.
Overview
What FIT5225 is, and where it sits
FIT5225 is Monash's postgraduate cloud-computing-and-security unit in the Faculty of IT: you learn the principles of cloud computing, how to design and implement scalable cloud applications, and how to reason about the security and privacy of the cloud services you build on. The spine walks the whole modern cloud stack in order, from the NIST definition and the IaaS, PaaS and SaaS service models, through virtualisation and hypervisors, Docker containers, Kubernetes orchestration, REST and service-oriented architecture, Infrastructure-as-Code, the AWS service catalogue, serverless and Function-as-a-Service, and finally cloud security built around the VPC, IAM, Cognito and the shared-responsibility model.
Unusually for an IT unit, there is no traditional final exam. Seventy per cent of the mark sits in two hands-on build-and-deploy projects: an individual application project called CloudEco built end-to-end on AWS (30%), and a group project (3 to 4 members) implementing and deploying a modern multicloud application across more than one provider with a shared private repository (40%). The remaining 30% is two invigilated quizzes (15% each) that test conceptual recall and applied reasoning across all twelve weeks: the crisp distinctions (VM versus container, IaaS versus PaaS versus SaaS, SOAP versus REST, Security Group versus NACL, User Pool versus Identity Pool), reading architecture diagrams, and reasoning about small config snippets.
It sits as a 6-credit-point postgraduate unit and assumes you can program and are comfortable with basic networking. It pairs naturally with the other Faculty of IT systems and software units, and the AWS-and-architecture fluency it builds (compute, storage, databases, networking, IaC, serverless and the security controls that fence them) is exactly what cloud-engineering and DevOps roles screen for.
Official outline: handbook.monash.edu · FIT5225 outline. Always treat the official outline and the exam timetable as authoritative.
Difficulty & time commitment
Is FIT5225 hard, and how much time does it take?
FIT5225 is manageable if you keep a weekly rhythm and treat the back half as the main event. Across student reviews the pattern is consistent: it starts gently and steepens, and the heaviest assessment is the part that separates grades.
A read across student reviews and course feedback. See what students say ↓
The difficulty curve and the assessment weighting point the same way: the back half is harder and worth more. Front-loading effort there is the highest-return decision in the unit.
Is this unit for you
Who tends to do well, and who tends to struggle
You will likely do well if
- You enjoy building and deploying real systems, because 70% of the mark is two hands-on projects rather than an exam, and you are happy to wrestle with a console, IaC and a real deployment.
- You can turn crisp distinctions into instant recall for the quizzes (VM versus container, IaaS/PaaS/SaaS, SOAP versus REST and the idempotent-safe verb matrix, Security Group versus NACL, User Pool versus Identity Pool, Standard versus FIFO SQS).
- You can read an architecture diagram and a small config snippet (a Dockerfile, a kubectl command, a Terraform or CloudFormation block, an IAM or bucket-policy JSON, a NACL row) and say what it does or what is mismanaged.
- You can coordinate a group of three or four across a multicloud build with shared repository hygiene, and start early enough that the open-ended projects do not eat your whole semester.
You may struggle if
- You leave the projects late: CloudEco and the group multicloud app are open-ended designs that need real build and deploy time, and they cannot be crammed in the final week.
- You only learn the concepts at a slogan level: the quizzes punish hand-wavy answers by asking you to apply a distinction to a diagram or a config snippet, not just name it.
- You expect an exam to rescue a weak project mark; there is no final exam, so a thin CloudEco or a passenger role in the group project directly limits your grade.
- You are shaky on the prerequisite programming and networking the unit assumes (IP ranges, subnets, ports, security groups), because the AWS and VPC weeks move fast on top of it.
- Treat CloudEco as a justification exercise, not just a build: pick each AWS service deliberately (compute, storage, database tier, access control) and write down why, mapped to the catalogue taught in Weeks 6 to 8.
- Build one labelled diagram per pillar and rehearse it: a VPC with public and private subnets plus NAT and a bastion, a Kubernetes control-plane-versus-node layout, the S3-to-Lambda and API-Gateway-to-Lambda-to-DynamoDB flows, and the shared-responsibility stack.
- Make a one-page distinctions sheet of every comparison table (hypervisor types, full versus para, container versus VM, SOAP versus REST, IaC axes, SG versus NACL, User Pool versus Identity Pool, SQS Standard versus FIFO) and drill it for the quizzes.
- In the group project, own a defensible multicloud design and clean IaC plus repo hygiene, and write your individual report so your specific contribution and design reasoning are unmistakable.
Syllabus
The 12 topics, week by week
The exam-weight marker on each topic shows where the marks concentrate. The amber topics carry the highest exam weight.
T1 · Introduction to cloud computing
Buyya, Mastering Cloud Computing Ch1 and Ch3; Above the Clouds (Berkeley View)The NIST definition, the five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service), the IaaS, PaaS and SaaS service models, the public, private, community and hybrid deployment models, and cloud economics (the CapEx to OpEx shift, pay-as-you-go and elasticity).
T2 · Virtualisation
Buyya Ch3; Coulouris Ch7. Cases: Xen, VMware, KVMHypervisors and virtual machines, Type 1 (bare-metal) versus Type 2 (hosted), full versus para-virtualisation, the four features (isolation, encapsulation, portability, interposition), CPU and memory and I/O virtualisation, the x86 problem and binary translation, and cold versus live migration.
T3 · Containers (Docker)
Poulton, Docker Deep DiveContainers versus VMs (OS-level versus hardware-level, boot time, overhead, isolation), the Docker Engine pipeline (client to daemon to containerd to runc plus shim), images as stacked read-only layers and the union filesystem, registries and tags, the Dockerfile as a build audit log, and the container lifecycle commands.
T4 · Container orchestration (Docker Swarm and Kubernetes)
Poulton, The Kubernetes Book; the Raft paper and Raft visualisationsWhy orchestration exists; the Kubernetes control plane (API server, etcd cluster store, controller manager, scheduler) versus worker nodes (kubelet, container runtime, kube-proxy); Pod, Deployment, ReplicaSet and Service; declarative desired-state reconciliation; Docker Swarm; and Raft leader election (terms, RequestVote, majority, heartbeats).
T5 · Web services and service-oriented architecture (SOA)
Coulouris (web services); FastAPI and Flask-RESTfulWeb services and marshalling, XML versus JSON, URI versus URL versus URN, SOAP versus REST (protocol versus architectural style), the HTTP verb idempotent-and-safe matrix (GET, PUT, DELETE, POST), and the monolith versus SOA versus microservices progression.
T6 · Infrastructure-as-Code and AWS (1)
Infrastructure Automation and Code Versioning; AWS Part 1 slidesIaC and infrastructure automation; declarative versus imperative, mutable versus immutable, agent versus agentless, push versus pull and idempotency across CloudFormation, Terraform, Ansible and Pulumi; code versioning (Git); and the AWS global structure (Region to Availability Zone to Edge Location) with IAM and EC2 and S3 introduced.
T7 · AWS (2): compute, storage, database and messaging
AWS docs (compute, RDS, SQS)EC2 (AMI, lifecycle, bootstrapping, and the On-Demand versus Reserved versus Spot pricing models); S3 storage classes and 11-nines durability, EBS, EFS and Glacier; RDS Multi-AZ and read replicas, Aurora, DynamoDB (eventual versus strong consistency) and Redshift; and SQS (Standard at-least-once versus FIFO exactly-once) versus SNS pub/sub.
T8 · AWS (3): scalable architectures, ELB, autoscaling and IAM
RDS docs; Elastic Load Balancing; VPC featuresElastic Load Balancing with Auto Scaling, the Auto Scaling plus ELB plus Multi-AZ RDS plus CloudWatch reference architecture for highly scalable and available designs, the S3-plus-CloudFront delivery pattern, IAM roles for secure EC2 access, and bucket policies versus ACLs for S3 access control.
T9 · Serverless and Function-as-a-Service (FaaS)
Castro et al., The Rise of Serverless Computing (CACM 2019); AWS Lambda and API GatewayServerless and FaaS definitions, the bare-metal to VM to container to function evolution, AWS Lambda (event-driven triggers and the per-request scaling and pricing model), API Gateway as the managed front door, the canonical API Gateway plus Lambda plus DynamoDB and the S3 plus Lambda patterns, and the trade-offs (cold start, statelessness, provider limits, vendor lock-in, cost crossover versus EC2).
T10 · Cloud security 1: AWS VPC, Cognito and security overview
ASD Cloud Computing Security Considerations; Introduction to AWS Security whitepaperThe VPC as a logical data centre, public versus private subnets, Internet Gateway versus NAT Gateway, the bastion host, the Security Group (stateful) versus NACL (stateless) distinction, the CIA triad and the 4 A's (Authentication, Authorization, Access, Audit), the shared-responsibility model, and Cognito (User Pool authentication versus Identity Pool authorization).
T11 · Cloud security 2: data security, IAM, encryption and compliance
Cloud Security deck (data security, encryption, compliance, DR)Encryption at rest and in transit (symmetric versus asymmetric, KMS), defense-in-depth and the AWS Well-Architected security principles (least privilege, traceability, security at all layers), IAM best practice (MFA, temporary credentials, rotation), identity federation, threat modeling, the 3-2-1 backup rule, data remanence and sanitisation, and compliance regimes (HIPAA, PCI-DSS, GDPR).
T12 · Industry talk and unit revision
Revision across all weeks; Oracle industry talk; Cognito labSynthesis across the whole stack (cloud, virtualisation, containers, orchestration, SOA, IaC, AWS, serverless, security), an industry talk, an optional architecture-design case study (present as CIO to a non-technical CEO, emphasising benefits over technical detail), and quiz-style revision. No new content.
How it's assessed
Assessment structure
| Component | Weight | Format & timing |
|---|---|---|
| Assignment 1: Cloud Application Project (CloudEco, individual) | 30% | Individual: design, build and deploy an end-to-end scalable cloud application on AWS, justifying your design choices against the AWS service catalogue. The model file you work from depends on your student ID. Generative AI is permitted if acknowledged, with the prompts appended to your report. Due around Week 8 (semester date set per offering; confirm on the unit Moodle). Assesses ULO2, ULO3, ULO4 and ULO6 (design choices, programming methods, container understanding, security analysis). |
| Assignment 2: Project (group) − implementing and deploying a modern multicloud application | 40% | Group of 3 to 4: implement and deploy a modern application spanning more than one cloud provider (the unit gives access to Nectar/OpenStack, Google Cloud, Oracle Cloud, Azure and AWS), share a private GitHub or Bitbucket repository with the teaching team, and submit a team report plus an individual report. Due near the end of semester (set per offering; confirm on the unit Moodle). Assesses ULO2 to ULO6; teamwork and IaC/repo hygiene are part of the mark. |
| Quiz / Test 1 | 15% | Invigilated quiz: conceptual definitions and distinctions, architecture-diagram reading, and config-snippet recognition across the unit material. Treat as closed-book; check your exam instructions. Scheduled in-semester (confirm on the unit Moodle). Assesses ULO1 to ULO6. |
| Quiz / Test 2 | 15% | Invigilated quiz: the same shape as Quiz 1 (crisp distinctions, diagram reasoning and config-snippet recognition), covering the later weeks. Treat as closed-book; check your exam instructions. Scheduled in-semester (confirm on the unit Moodle). Assesses ULO1 to ULO6. |
- Pass on a weighted average of at least 50%. No single-component hurdle is stated in the unit materials reviewed. There is no traditional final exam: 70% sits in the two projects and 30% in the two invigilated quizzes.
- No final exam. The two invigilated quizzes (15% each) test conceptual definitions and distinctions, architecture-diagram reading, and reasoning about short config snippets (a Dockerfile, a kubectl or docker command, a CloudFormation, Terraform or Ansible block, an IAM or S3 bucket-policy JSON, a NACL rule row) rather than authoring large code under quiz conditions.
- Calculator policy: Not applicable in the usual sense: there is no final exam, and the quizzes are concept-and-reasoning tests rather than calculation papers. Confirm any permitted materials in the quiz instructions.
This is a coursework unit. Coursework carries 100% of the grade and the assignment 2: project (group) - implementing and deploying a modern multicloud application is the single heaviest piece at 40%, so steady work across the semester decides your result more than any one sitting. Assesses ULO2 to ULO6; teamwork and IaC/repo hygiene are part of the mark.
Final exam timing: No final exam. Assessment is two projects (70%) plus two invigilated quizzes (30%); quiz dates are set per offering. Confirm timings on the unit Moodle for S2 2026.. Confirm the exact date and venue on the official exam timetable.
How to actually pass it
A weekly rhythm, two checklists, and the traps to avoid
The unit rewards consistency over cramming, and practice over re-reading. Here is the loop that works, then what to have nailed before each exam.
The weekly loop
Before the mid-semester checklist
- Lock in and start your CloudEco design early: choose compute, storage, the database tier and access control on AWS and write the justification as you go.
- Master the early-weeks distinctions for the first quiz: IaaS/PaaS/SaaS, Type-1 versus Type-2 hypervisor, full versus para-virtualisation, container versus VM, the Docker Engine pipeline and image layers, and the Kubernetes control plane versus worker components.
- Drill the SOA and REST material: SOAP versus REST, XML versus JSON, and the idempotent-and-safe HTTP verb matrix (GET, PUT, DELETE, POST).
- Be able to read a Dockerfile, a kubectl or docker command, and a small Terraform or CloudFormation block and say what each does.
Before the final heaviest topics
- Form your group and lock a defensible multicloud architecture as soon as Assignment 2 opens, then build, deploy and document it with Infrastructure-as-Code and a shared private repository.
- Drill the AWS catalogue for the quiz: match a need to a service (SQS to decouple, ElastiCache to cache, Multi-AZ RDS for DR, Glacier to archive, CloudFront for delivery) and know the S3 storage classes and the EC2 On-Demand versus Reserved versus Spot decision.
- Lock the security pillar: VPC public versus private subnets, Internet Gateway versus NAT Gateway, the bastion host, Security Group (stateful) versus NACL (stateless), the shared-responsibility model, and Cognito User Pool (authentication) versus Identity Pool (authorization).
- Rehearse the serverless flows and trade-offs: the S3-to-Lambda and API-Gateway-to-Lambda-to-DynamoDB patterns, and when serverless beats EC2 (low or spiky load) versus not (steady high utilisation).
- Write a strong individual report for the group project: make your specific contribution and your design reasoning explicit, with prompts appended if you used generative AI.
The mistakes that cost marks
Leaving the projects until the last week. CloudEco and the group multicloud app are 70% of the mark and are open-ended designs that need real build and deploy time. With no exam to rescue you, a rushed project caps your grade. Start CloudEco by Weeks 6 to 8 and the group project the moment it opens.
Learning distinctions at slogan level. Knowing that a Security Group is stateful and a NACL is stateless is not enough; the quizzes ask you to apply the distinction to a diagram or a config snippet. Practise reasoning about a NACL rule table, a bucket-policy JSON and a VPC topology, not just naming the terms.
Confusing Security Groups with NACLs. Security Groups are stateful, instance-level and Allow-only; NACLs are stateless, subnet-level and evaluate numbered Allow-and-Deny rules in order. Mixing them up is the single most common VPC error and it shows up in both the security lab and the quiz.
Coasting as a passenger in the group project. Assignment 2 carries 40% and includes an individual report. Letting teammates carry the multicloud build leaves your individual contribution thin and your design reasoning weak, which the individual report exposes.
Teaching team
Who teaches FIT5225
The bios below are factual. The star ratings are not ours: they are impressions from students who have taken the unit, so you can hear from people who sat in the lectures.
Dr Mohammad Goudarzi
Lecturer in the Faculty of Information Technology, Monash University. Coordinates and lectures FIT5225, covering the cloud, virtualisation, containers, orchestration, web services, IaC, AWS and serverless material.
Jay Zhao
Contributes to FIT5225 in the Faculty of Information Technology, Monash University, leading the cloud-security material (VPC, security groups and NACLs, Cognito and the shared-responsibility model) and the group-project coordination.
Teaching team as listed in the unit materials reviewed. AskSia does not rate lecturers; star ratings are submitted by students who have taken FIT5225.
Formula & concept sheet
The vocabulary and formulas you must own
- NIST five essential characteristics
- On-demand self-service, broad network access, resource pooling (multi-tenancy), rapid elasticity, and measured (metered, pay-per-use) service.
- IaaS vs PaaS vs SaaS
- The responsibility split rises with the layer: IaaS delivers raw virtualised compute and storage (you manage OS upward); PaaS adds the runtime (you manage app and data); SaaS delivers the finished application (you manage only configuration and your data).
- Type 1 vs Type 2 hypervisor
- Type 1 (bare-metal, e.g. ESXi, Xen) runs directly on hardware with higher performance; Type 2 (hosted, e.g. VirtualBox, VMware Workstation) runs on top of a host OS, easier to install but slower.
- Full vs para-virtualisation
- Full virtualisation runs an unmodified guest OS that is unaware it is virtualised (trap-and-emulate or binary translation, broad compatibility, more overhead); paravirtualisation modifies the guest to call the hypervisor via hypercalls (lower overhead, e.g. Xen).
- Container vs VM
- VMs virtualise at the hardware level with their own guest OS each (heavyweight, minutes to boot, full isolation); containers virtualise at the OS level sharing the host kernel (lightweight, seconds to boot, near-native performance, process-level isolation).
- Kubernetes control plane vs worker
- Control plane: API server (all comms via REST on 443), etcd cluster store (desired and current state), controller manager (watch loops), scheduler. Worker node: kubelet (node agent), container runtime (CRI), kube-proxy (per-node networking and load balancing).
- Pod, Deployment, Service
- Pod is the atomic unit of scheduling (one or more tightly coupled containers, mortal, one node). Deployment wraps a Pod to add scaling, rolling updates and rollbacks via desired-state reconciliation. Service gives a stable DNS name, IP and load balancing for a dynamic set of Pods, matched by label selector.
- HTTP verbs: idempotent and safe
- GET is safe and idempotent; PUT and DELETE are idempotent but not safe; POST is neither safe nor idempotent. Idempotent means repeating the call has the same effect; safe means it does not modify server state.
- SOAP vs REST
- SOAP is a protocol (XML-only, WSDL contract, can be stateful, ACID and WS-Security, heavier); REST is an architectural style (resources by URI, uniform HTTP verbs, stateless, cacheable GETs, JSON or XML, lighter and more scalable).
- IaC axes
- Declarative (desired state: Terraform, CloudFormation) vs imperative (steps: Ansible, Chef, Puppet); mutable vs immutable; agent vs agentless; push vs pull. Idempotency means re-applying the same config converges to the same end state.
- Security Group vs NACL
- Security Group is stateful, instance-level and Allow-only (return traffic auto-allowed). NACL is stateless, subnet-level, with numbered Allow-and-Deny rules evaluated in order (lower number first), and inbound and outbound evaluated independently.
- VPC public vs private subnet
- A public subnet has a route to an Internet Gateway (web servers, load balancers, bastion); a private subnet has no inbound internet route (databases, app servers) and reaches the internet outbound only via a NAT Gateway. One subnet maps to one AZ.
- Cognito User Pool vs Identity Pool
- A User Pool handles authentication (a sign-in directory, can federate Google, Facebook, Amazon); an Identity Pool handles authorization (exchanges tokens for temporary AWS credentials to access AWS services).
- SQS Standard vs FIFO
- Standard queues give at-least-once delivery with best-effort ordering and high throughput; FIFO queues give exactly-once processing and strict ordering. SQS is pull-based and decouples components; SNS is push-based pub/sub (topic to subscribers).
- EC2 pricing models
- On-Demand (pay per hour, no commitment, spiky or first use); Reserved (capacity reservation, large discount, steady predictable load, up-front); Spot (spare capacity, deepest discount, for stateless and fault-tolerant flexible workloads).
- Shared responsibility model
- AWS is responsible for security OF the cloud (hardware, networking, virtualisation up to the service boundary); the customer is responsible for security IN the cloud (their data, access control, OS and app depending on whether the service is IaaS, PaaS or SaaS).
- Serverless trade-offs
- Lambda is event-triggered, ephemeral and auto-scaling, priced per request plus duration. Trade-offs: cold-start latency, statelessness (no sticky sessions), provider limits (execution time, memory, package size) and vendor lock-in. It beats EC2 for low or spiky load, not steady high utilisation.
Common acronyms: NIST · IaaS · PaaS · SaaS · VM · VMM · K8s · CRI · SOA · REST · SOAP · WSDL · IaC · HCL · EC2 · S3 · EBS · EFS · RDS · VPC · IGW · NAT · SG · NACL · IAM · ELB · SQS · SNS · FaaS · KMS · CIA · MFA · AZ.
What students say
What students actually say about FIT5225
Recurring themes from student reviews, paraphrased in our own words.
- Read as harder than a typical taught unit because the marks live in two open-ended engineering projects rather than a single exam: a defensible architecture, a real deployment and clear justification are what the grade rewards.
- The breadth is the load: the unit walks the whole cloud stack in twelve weeks (virtualisation, containers, Kubernetes, SOA, IaC, the AWS catalogue, serverless, security), so falling behind compounds.
- Manageable for students comfortable with programming and basic networking; the AWS and VPC weeks move fast on top of that assumed base.
- Students lean on the comparison tables (hypervisor types, container versus VM, SOAP versus REST, the IaC axes, Security Group versus NACL, User Pool versus Identity Pool) as the spine of quiz revision.
- Labelled architecture diagrams (a VPC topology, a Kubernetes cluster, the serverless event flows, the shared-responsibility stack) are what students reach for, because the quizzes test reading and reasoning about them.
- Demand clusters around the high-yield distinctions and config-snippet reading (a Dockerfile, a kubectl command, a Terraform or CloudFormation block, an IAM or bucket-policy JSON, a NACL row) rather than large code authoring.
Recurring student opinions, paraphrased and aggregated, not official course information.
Set texts
The prescribed reading
The syllabus references map straight onto these.
Mastering Cloud Computing
Rajkumar Buyya, Christian Vecchiola and S. Thamarai Selvi.
Docker Deep Dive
Nigel Poulton.
The Kubernetes Book
Nigel Poulton.
Distributed Systems: Concepts and Design
Coulouris, Dollimore, Kindberg and Blair.
Where it fits
Prerequisites, related units & why it matters
A postgraduate Faculty of IT unit in the Master of IT. It assumes you can program and have a basic grasp of networking and operating systems. Check the official Monash handbook entry for the exact enrolment rules, prerequisites and prohibitions for your course.
Your FIT5225 study toolkit
Study the unit with Sia, not just read about it
Each tool already knows FIT5225: your syllabus, your texts, and where the marks are. Grouped by how you study, from first contact to exam week.
FAQ
Frequently asked questions
How is FIT5225 assessed?
There is no final exam. The mark is two hands-on projects worth 70% combined (an individual AWS application project, CloudEco, worth 30%, and a group multicloud implement-and-deploy project worth 40%) plus two invigilated quizzes worth 15% each. You pass on a weighted average of at least 50%, with no single-component hurdle stated in the materials reviewed.
Is there a final exam in FIT5225?
No. Unlike most IT units, FIT5225 has no traditional final exam. The examined component is two invigilated quizzes (15% each), and the bulk of the mark (70%) is the two build-and-deploy projects.
What do the FIT5225 quizzes actually test?
Conceptual recall and applied reasoning across all twelve weeks: crisp distinctions (VM versus container, IaaS versus PaaS versus SaaS, SOAP versus REST, Security Group versus NACL, User Pool versus Identity Pool), reading and reasoning about architecture diagrams (a VPC topology, a Kubernetes cluster, a serverless event flow), and recognising what short config snippets do (a Dockerfile, a kubectl command, a Terraform or CloudFormation block, an IAM or S3 bucket-policy JSON, a NACL rule). They are not large code-writing exams.
What is the CloudEco assignment?
Assignment 1 is an individual project worth 30% in which you design, build and deploy an end-to-end scalable cloud application on AWS and justify your design choices against the AWS service catalogue. The model file you work from is chosen by your student ID. Generative AI is permitted if you acknowledge it and append your prompts to the report.
What does the group multicloud project involve?
Assignment 2 is a group project (3 to 4 members) worth 40%: you implement and deploy a modern application that spans more than one cloud provider (the unit gives access to Nectar/OpenStack, Google Cloud, Oracle Cloud, Azure and AWS), share a private GitHub or Bitbucket repository with the teaching team, and submit both a team report and an individual report. It rewards service selection across providers, deploying with Infrastructure-as-Code, and justifying the multicloud design.
Do I need to know AWS before starting?
No prior AWS experience is assumed. The unit teaches the AWS service catalogue from Week 6 (EC2, S3, EBS, VPC, IAM, RDS, DynamoDB, ELB, autoscaling, CloudWatch, Lambda, API Gateway, Cognito, KMS) and the early weeks use other platforms (Nectar/OpenStack, Google Cloud, Oracle, Azure). It does assume you can program and have basic networking knowledge, so being comfortable in Python and with IP, subnets and ports makes the projects much smoother.
Study FIT5225 with Sia
Work through introduction to cloud computing, virtualisation, containers (docker) and the rest of the unit with a tutor that knows it and quizzes you on the topics the assessments weight most heavily.
Start studying with Sia