Amazon CLF-C02: Core Compute Services — Study Guide
Part of the AWS Cloud Practitioner CLF-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Core EC2 concepts, purchasing models, and availability patterns
Amazon EC2 is the fundamental IaaS compute offering: you choose instance types for CPU, memory, storage, and networking, run operating systems you control, and optionally attach Elastic Block Store (EBS) volumes for persistent block storage. Designing for availability requires placing workloads across multiple Availability Zones (AZs) and, when appropriate, multiple Regions. For managed relational databases, use Amazon RDS Multi‑AZ for synchronous standby and automated failover; for extreme read scale or cross‑region disaster recovery, consider Amazon Aurora Global Database. Instance purchasing choices drive cost and resilience tradeoffs: On‑Demand gives flexibility with no commitment; Reserved Instances or Compute Savings Plans give the biggest predictable savings for steady-state continuous usage; Spot Instances deliver the lowest price for fault‑tolerant, interruptible workloads. Common traps include relying on a single AZ, embedding long‑lived credentials on instances, and over‑provisioning “just in case.” Use Auto Scaling groups with health checks, lifecycle hooks, and mixed instance policies (On‑Demand + Spot) to balance cost and availability. Decide between Reserved/Savings Plans versus Spot by evaluating required uptime, tolerance for interruptions, and forecasting accuracy; choose Multi‑AZ or multi‑Region based on RTO/RPO requirements and cross‑region latency constraints.
Managed container, batch, and serverless compute: decision criteria
AWS offers multiple managed compute platforms to match architectural goals. AWS Lambda enables event‑driven, serverless functions with automatic scaling and per‑millisecond billing, best for stateless, short‑lived tasks. Amazon ECS provides a managed container orchestration option that integrates with Fargate for serverless container execution or with EC2 for more control. Amazon EKS runs Kubernetes as a managed control plane for teams standardizing on Kubernetes, with worker nodes as EC2 or Fargate. AWS Batch schedules and scales batch compute jobs across EC2 or Spot capacity, optimizing throughput for high‑performance or high‑volume jobs. Elastic Beanstalk is an application platform for deploying web apps without managing the underlying infrastructure; it abstracts EC2, autoscaling, ELB, and RDS setup for faster lift‑and‑shift deployments. Key decision criteria include operational skillset (Kubernetes expertise favors EKS), deployment speed (Beanstalk), cost predictability (Fargate simplifies but may cost more), and workload characteristics (Lambda for short, evented tasks; ECS/EKS for long‑running services). Avoid the trap of selecting the most feature‑rich option when a simpler managed service (Lambda or Fargate) would reduce operational burden and increase agility.
Autoscaling, elasticity, and cost optimization strategies
Elasticity is the ability to scale resources up and down to match demand; autoscaling is the mechanism to achieve it. Use Auto Scaling groups (ASGs) for EC2 to add or remove instances based on target tracking, step, or predictive policies. For containers, use ECS or EKS auto‑scaling for tasks and clusters, and use Lambda’s built‑in concurrency controls for functions. Architect for statelessness and externalize state to managed services such as Amazon RDS, DynamoDB, ElastiCache, or S3 so instances can be ephemeral. Right‑size instances with regular sizing reviews, use monitoring (CloudWatch metrics and alarms), and consider Savings Plans or Reserved Instances for steady baseline usage while placing variable workloads on Spot. Pricing models to weigh:
- On‑Demand: no commitment, pay per hour/second.
- Reserved Instances / Savings Plans: 1 or 3‑year commitment for substantial discounts.
- Spot Instances: deepest discounts for interruptible workloads.
- Dedicated Hosts/Instances: physical isolation for compliance, higher cost.
Popular pitfalls include underestimating warm‑up times for autoscaling, failing to use lifecycle hooks for graceful shutdown, and overusing Spot for stateful critical workloads. Use blue/green or canary deployments for safe releases and lifecycle policies to automate cost control for unused resources.
Security, compliance, and operational tooling for compute
Security and operations are foundational to compute in AWS. Under the shared responsibility model, AWS secures the global infrastructure and managed services, while customers are responsible for guest OS, application configuration, data, and IAM permissions when using IaaS. Avoid embedding long‑lived access keys; instead attach IAM roles to EC2 instances or use IAM Roles for Service Accounts (IRSA) for EKS, and use AWS Secrets Manager or Systems Manager Parameter Store (SecureString) to rotate and centrally manage secrets. For auditing and investigation, enable AWS CloudTrail to capture API activity across the account and use AWS Config to record resource configurations. Use Amazon Macie to discover and classify sensitive data in S3, and IAM Access Analyzer or S3 Access Analyzer to find cross‑account or public resource sharing. For compliance evidence, use AWS Artifact to retrieve audit reports. Operational visibility is improved with VPC Flow Logs for network traffic, the AWS Personal Health Dashboard for account‑specific events, and the Service Health Dashboard for global service status. Common practitioner mistakes include leaving the root account with active keys, failing to enable MFA on the root user, and not centralizing identity with IAM Identity Center (formerly AWS SSO) for SAML‑based single sign‑on to external applications.
Practical Problem: Use-Case Scenario
Scenario: Acme Analytics runs a data‑processing application on EC2 in a single AZ within a production AWS account. They have batch jobs that process large volumes nightly and want lower costs, faster recovery from AZ failure, and secure secret handling.
Challenge: Reduce compute cost while ensuring nightly batch throughput and improving availability across AZs, without rearchitecting the entire application immediately.
Recommended Approach:
- Migrate batch workers to an AWS Batch compute environment using a mixed instance policy (Spot + On‑Demand) to lower cost while maintaining baseline capacity.
- Configure AWS Batch to use multiple AZs and enable Retry/RetryStrategy with job queues spread across AZs for resilience.
- Replace embedded credentials with IAM roles for EC2/Batch jobs and store rotated secrets in AWS Secrets Manager; integrate with IAM for automatic retrieval.
- Implement CloudWatch alarms and Auto Scaling policies on a minimal EC2 fleet for any remaining stateful components and enable Cross‑AZ RDS Multi‑AZ if a DB is in use.
Rationale: Using managed batch + Spot reduces cost and operational overhead, while multi‑AZ distribution and IAM/Secrets Manager improve availability and security—aligning with best practices of elasticity, least privilege, and automated secret rotation.
← AWS Global Infrastructure · All domains · Core Storage Services →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →