Module 68: Cloud Architecture

Why each option is right or wrong

• “For batch jobs that can restart if interrupted” (Incorrect): That's what spot instances suit best.
• “For running tests in CI that can simply be retried” (Incorrect): Retryable tests are a good fit for spot capacity.
• “For overnight reports that can resume where they stopped” (Incorrect): Resumable work handles interruptions well.
• “For a main API that needs to stay available” is correct.

  Spot instances use spare cloud capacity at a big discount, but the provider can take them back with little warning. That suits batch jobs that can restart, not the API your users depend on every minute.

  • Good for: data processing, test runs, rendering.
  • Main API: on-demand or reserved instances.

📖 Revise: Lesson 1: Compute

Why each option is right or wrong

• “Store it permanently without ever running it” (Incorrect): Storage is a registry's job; Cloud Run runs images.
• “Convert it into a virtual machine you manage yourself” (Incorrect): It runs containers for you without exposing servers.
• “Turn it into a static website with no server code” (Incorrect): It runs your server code inside the container.
• “Run it and scale it with traffic, even to zero” is correct.

  You give the service an image; it starts copies as requests arrive, adds more when busy, and can stop them all when idle, so you pay only while it's working.

  • Cold start: the first request after idle may be slower.
  • Keep a minimum: of one instance if that matters.

📖 Revise: Lesson 1: Compute

Why each option is right or wrong

• “On the app server's own disk, next to the code” (Incorrect): Server disks can be lost on redeploy and aren't shared between servers.
• “In a public bucket so anyone can download them easily” (Incorrect): Public buckets have leaked huge amounts of private data.
• “Inside the database as large text columns” (Incorrect): Big files bloat the database; object storage suits them better.
• “In private object storage buckets” is correct.

  Object storage like S3, Google Cloud Storage or R2 is durable, cheap per gigabyte and shared by every server. Keeping buckets private and giving access through signed URLs or the app protects the files.

  • Backups: a separate bucket, ideally another account or region.
  • Public files: only if they really are public.

📖 Revise: Lesson 2: Storage

Why each option is right or wrong

• “Hackers reading the files stored in the bucket” (Incorrect): Versioning keeps old copies; access control stops reading.
• “Slow downloads during busy periods” (Incorrect): Speed is unrelated to versioning.
• “Running out of storage space” (Incorrect): Versioning uses more space, not less.
• “Accidental overwrites and deletions” is correct.

  With versioning on, overwriting or deleting a file keeps the previous version. If someone, or a buggy script, removes something, you can restore it.

  • Pair with: lifecycle rules to delete old versions after a while.
  • Still need: backups elsewhere for major failures.

📖 Revise: Lesson 2: Storage

Why each option is right or wrong

• “Public, so developers can connect from anywhere” (Incorrect): That exposes it to the whole internet.
• “Public, because private subnets are slower” (Incorrect): Speed is similar; private is safer.
• “Either; subnets make no difference to security” (Incorrect): Subnets decide what can reach the database.
• “Private, reachable only from the app servers” is correct.

  A private subnet has no direct route from the internet. The database can talk to the app servers inside the network, but attackers outside can't even reach its port.

  • Public subnet: for load balancers and things that must face the internet.
  • Admin access: through a bastion host or VPN.

📖 Revise: Lesson 3: Virtual networks

Why each option is right or wrong

• “The database can only hold 5,432 rows” (Incorrect): 5432 is a port number, not a row limit.
• “The app servers can only reach the database 5,432 times a day” (Incorrect): It's a port rule, not a request quota.
• “Everyone can reach the database except the app servers” (Incorrect): It's the opposite: only the app servers are allowed.
• “Only the app servers can reach the database port” is correct.

  A security group is a firewall attached to resources. This rule allows PostgreSQL's port only from machines in the app-servers group, so everything else, including the internet, is blocked.

  • Reference groups: not fixed IPs, so new app servers are allowed automatically.
  • Least privilege: for network access.

📖 Revise: Lesson 3: Virtual networks

Why each option is right or wrong

• “They're the same thing, named differently by each provider” (Incorrect): Zones are parts of a region, not another name for it.
• “A zone is a country; a region is a single server rack” (Incorrect): A region is the bigger area; zones are data centres in it.
• “Regions are for storage; zones are for compute” (Incorrect): Both storage and compute live in regions and zones.
• “A region is an area; zones are separate data centres within it” is correct.

  A region, like Mumbai, contains several availability zones: separate buildings with their own power and networking, close enough for fast links. Spreading across zones protects against one building failing.

  • Region choice: affects speed for users and data rules.
  • Multi-region: for protection against a whole region failing.

📖 Revise: Lesson 4: Regions and availability zones

Why each option is right or wrong

• “It doubles the speed of every request” (Incorrect): It improves availability, not raw speed.
• “It makes backups unnecessary” (Incorrect): Zones protect against outages, not mistakes like deleted data.
• “It halves the monthly bill” (Incorrect): Running in two zones usually costs more.
• “If one data centre fails, the other keeps serving” is correct.

  Failures like power cuts or network problems usually affect one zone. With app servers and a database replica in two zones behind a load balancer, traffic shifts to the healthy zone and users barely notice.

  • Managed databases: often offer multi-zone options.
  • Test it: occasionally, to check failover works.

📖 Revise: Lesson 4: Regions and availability zones

Why each option is right or wrong

• “A bug that appears only once and does not come back” (Incorrect): That's a one-off bug, not a design weakness.
• “The first error shown in a log file” (Incorrect): Log order doesn't define a single point of failure.
• “A server that fails exactly one test” (Incorrect): It's about architecture, not test results.
• “A component whose failure takes the whole system down” is correct.

  If there's one database, one server or one network link with no backup, its failure stops everything. Finding these and deciding which to make redundant is part of designing for availability.

  • Common ones: a single server, one database, one person who knows the system.
  • Not every one needs fixing: weigh the cost against the risk.

📖 Revise: Lesson 5: Availability and cost

Why each option is right or wrong

• “Storing a few gigabytes of backups in object storage” (Incorrect): Storage is cheap per gigabyte; transfer out and idle resources add up faster.
• “Keeping the database in a private subnet” (Incorrect): Network placement improves security and doesn't add a meaningful cost.
• “Using the provider's built-in budget alerts” (Incorrect): Budget alerts help prevent surprise bills rather than cause them.
• “Data transfer out and forgotten idle resources” is correct.

  Sending data out of the cloud often costs per gigabyte, and test servers, disks or IP addresses left running keep charging. Budgets, alerts and regular clean-ups catch them early.

  • Set: a budget alert on day one.
  • Tag resources: so you know what each one is for.

📖 Revise: Lesson 5: Availability and cost