IBM Full Stack Software Developer study materials
IBM Full Stack Software Developer study resources

IBM Full Stack Software Developer: Cloud

IBM Full Stack Software Developer · Work through your exam, one topic at a time.

All guide sections

Cloud

What this domain tests

Cloud covers service and deployment models, scaling, cloud-native design and the 12-factor principles that keep an application portable across providers, plus the shared-responsibility model and managed services on IBM Cloud.

Core rules and concepts

  • Service models: IaaS gives virtual machines and networks; PaaS gives a runtime and lets you push code; SaaS gives a finished application. Deployment models: public, private, hybrid.
  • Scale up (a bigger machine, with a ceiling) versus scale out (more instances, which requires statelessness).
  • A region contains several availability zones - isolated datacentres with independent power and networking. Spreading replicas across zones is how you survive a zone outage.
  • 12-factor highlights: config in environment variables, stateless processes, logs as event streams, dev/prod parity, disposability, declarative setup.
  • Microservices split a system into independently deployable services with their own data; a monolith is simpler until independent scaling and team autonomy matter.
  • Shared responsibility: the provider secures physical infrastructure and the managed service; you secure identity, data, configuration and application code.

Worked example

An app keeps logged-in users in an in-memory dictionary and runs as one instance. You scale to three instances behind a load balancer, and users are randomly logged out. Reasoning: each instance has its own memory, and the balancer may send the next request to a process that has never seen that session. The fix is to externalise state - sessions in Redis or a database, or stateless signed tokens - so any instance can serve any request. That is the 12-factor stateless-process rule and the precondition for horizontal scaling.

Traps that cost marks

  • Treating region and availability zone as the same thing.
  • Calling a lift-and-shift migration cloud native; it keeps the operational habits of the datacentre.
  • Assuming the provider backs up or classifies your data for you.
  • Ignoring egress and per-request pricing when choosing a design.