AWS CRI study materials
AWS CRI study resources

AWS Certified Cloud Practitioner (CRI series): Cloud Technology and Services: Compute, Storage, and Networking Choices

AWS CRI · Work through your exam, one topic at a time.

All guide sections

Cloud Technology and Services: Compute, Storage, and Networking Choices

Choosing compute

Questions rarely ask for a definition; they ask which option fits a constraint. Map constraints to service families: virtual servers for full control, containers for portability and packaging, serverless functions for event-driven short tasks, and managed platform runtimes for web apps where you want to avoid server administration. A trap is treating serverless as universally cheaper; for steady, high-volume, long-running workloads, provisioned compute often wins. Another trap is assuming containers require cluster management; managed container offerings exist at several levels of abstraction.

Choosing storage

Separate the three questions: is it file, block, or object; how often is it accessed; and does it need to be shared. Object storage is effectively unlimited and accessed over HTTP, block storage attaches to a single instance as a volume, and file storage is shared across many clients. Within object storage, storage classes trade retrieval cost and latency against storage price, and lifecycle rules move data automatically. Traps include assuming a storage class change is instantaneous, forgetting minimum storage duration charges, and using block volumes as a shared file system across instances.

Networking and decoupling

Know the building blocks: a virtual private network boundary, subnets that map to a single AZ, route tables, gateways, and security controls. Security groups are stateful and allow-only; network ACLs are stateless and support allow and deny. A frequent trap is placing a public-facing resource in a private subnet without a load balancer or similar entry point. Also understand decoupling: queues buffer work, topics fan out notifications, and these patterns improve resilience more than simply adding larger instances.

Worked example

A workload stores images accessed heavily for a week, then almost never. Rule of thumb: keep them in a hot object storage class, then use a lifecycle rule to transition to a colder class after the access window and expire them when no longer needed. If a question proposes resizing block volumes for archival images, it is testing whether you recognize object storage as the correct fit.