Sample questions
Cloud Architecture ScalingDifficulty 1
What is the core difference between IaaS, PaaS, and SaaS cloud service models?
- aIaaS and PaaS provide the exact same abstraction level; the only real difference between them is the pricing model, not what is managed for you
- bA team using PaaS is still responsible for patching the operating system and planning server capacity themselves, just like with IaaS
- cSaaS is the best fit for a team that wants to build a brand-new application from scratch, since it gives them full, direct, low-level control over every layer of the underlying infrastructure stack
- dIaaS provides raw infrastructure (VMs, network, storage); PaaS adds a managed runtime and scaling; SaaS delivers the finished application as a ready service✓
Explanation:The three models differ by how much operational responsibility the provider takes on: IaaS gives you raw compute/network/storage and you manage the OS and runtime yourself; PaaS also manages the runtime, patching, and scaling so you only ship code; SaaS hands you a finished application with no infrastructure management at all. Option b is wrong because PaaS explicitly takes OS patching off the team's plate — that is the point of PaaS. Option c is wrong because SaaS gives you no infrastructure control at all; a team building a custom app needs IaaS or PaaS, not SaaS.
Cloud Architecture ScalingDifficulty 2
A small startup team is building an internal admin tool and wants to focus purely on writing application code, without managing servers, operating systems, or runtimes. Which service model fits this need best?
- aIaaS, since raw virtual machines always give the fastest path to shipping a simple internal tool
- bSaaS, since they should just buy an off-the-shelf CRM product instead of building anything themselves
- cPaaS, since the platform manages the runtime, OS patching, and scaling for them, letting the team focus only on application code✓
- dOn-premises hosting, since internal tools should always be self-hosted for security reasons regardless of the team's goals
Explanation:PaaS is designed exactly for this case: you push code and the platform handles runtime provisioning, OS-level maintenance, and scaling. Option a is wrong because IaaS still requires the team to manage the OS and runtime themselves. Option d is a common but incorrect generalization — security concerns don't automatically require on-premises hosting, and the scenario doesn't mention any such requirement.
Cloud Architecture ScalingDifficulty 1
What is the basic relationship between a cloud region and an availability zone (AZ)?
- aA region is a broad area containing multiple availability zones, typically physically isolated but linked by low-latency connections✓
- bAn availability zone is just another marketing name for a region; providers use both terms interchangeably with no real distinction
- cA region refers to a single data center building, while an availability zone is the much larger geographic grouping that spans multiple separate regions
- dAvailability zones and regions describe the exact same infrastructure boundary; the choice of term depends only on which provider you use
Explanation:A region groups multiple availability zones together; each AZ is meant to be an independent failure domain (its own power, cooling, and often its own building) while still being close enough to other AZs in the same region for low-latency communication. Options c and d reverse or collapse this hierarchy, which is a common junior misunderstanding when first reading cloud architecture diagrams.
Cloud Architecture ScalingDifficulty 2
A team runs its entire application in a single availability zone. During an incident, that AZ becomes unreachable due to a power outage, causing full downtime. What is the best architectural fix going forward?
- aIncrease the instance size within the same AZ, since a bigger instance recovers faster after a power outage
- bAdd more replicas, but keep all of them within that same single AZ to simplify networking and configuration
- cSwitch to a completely different cloud provider, since staying with the same provider guarantees the same outage will happen again
- dDeploy the application across multiple availability zones within the region, so traffic can still be served from a healthy AZ if one AZ fails✓
Explanation:A single-AZ deployment means the whole AZ is a single point of failure — no amount of resizing or adding replicas within that same AZ protects against the AZ itself going down. Spreading instances across multiple AZs, combined with a load balancer that routes around unhealthy zones, is the standard way to achieve high availability at the infrastructure level. Option a addresses capacity, not availability, and is unrelated to the actual failure mode described.
Cloud Architecture ScalingDifficulty 1
What is the difference between horizontal scaling and vertical scaling?
- aHorizontal scaling means increasing the CPU and RAM of a single server, while vertical scaling means adding entirely new servers
- bHorizontal scaling adds more servers/instances sharing the workload (scale out); vertical scaling grows an existing server's resources (scale up)✓
- cThe two terms describe the exact same concept in cloud architecture; different providers simply use different marketing names for identical behavior
- dVertical scaling only applies to database and storage systems, while horizontal scaling only applies to stateless web or application servers
Explanation:Horizontal scaling (scale out/in) adds or removes instances to distribute load across more machines; vertical scaling (scale up/down) grows or shrinks the resources of a single machine. Option a swaps the definitions, and option d imposes an artificial restriction that doesn't reflect real usage — both approaches apply broadly across compute and data workloads.
Cloud Architecture ScalingDifficulty 2
A stateless web application starts slowing down under increasing traffic. What is the most appropriate first step to scale it?
- aApply rate limiting to reduce traffic, since limiting the number of users is the standard first response to any slowdown
- bKeep increasing the CPU and RAM of the single instance, since stateless applications can only be scaled vertically
- cConvert the application from stateless to stateful and keep session data inside each instance to reduce request handling overhead
- dRun multiple instances/replicas of the same application behind a load balancer to distribute traffic across them (horizontal scaling)✓
Explanation:Because a stateless application doesn't keep session data tied to a specific instance, any instance can handle any request, which makes it a natural fit for horizontal scaling behind a load balancer. Option b is a common misconception — stateless apps are actually the easiest to scale horizontally, not restricted to vertical scaling. Option c moves in the wrong direction: adding state makes horizontal scaling harder, not easier.