Amazon CLF-C02: Cloud Concepts — 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 cloud concepts and the AWS value proposition
Cloud computing shifts capital-intensive, capacity-planning problems to an operational model where compute, storage, and networking are consumed on demand. AWS provides elasticity (auto scaling to match load), global reach (Regions and Availability Zones for locality and fault isolation), and a spectrum of managed services that remove undifferentiated heavy lifting. Architectural concepts such as designing for failure, loose coupling, and immutable infrastructure help teams exploit cloud benefits: faster time to market, pay-for-what-you-use economics, and global scale. Network primitives such as VPCs, subnets, and an Internet Gateway control ingress and egress for workloads, while Direct Connect offers a dedicated high-throughput link to on-premises data centers when predictable bandwidth or lower latency is required. For very large physical migrations or intermittent connectivity, Snowball Edge devices enable secure offline transfer and even edge compute. Common practitioner traps include assuming “lift-and-shift” will automatically cut costs, underestimating network egress fees, and failing to design for multi-AZ resilience. Decision criteria should weigh business availability requirements, data gravity, latency constraints, and long-term operational costs before choosing rehost, replatform, or refactor strategies.
Services, migration patterns, and architectural decisions
Choosing the right AWS service depends on whether you need managed operations, control over OS-level responsibilities, or edge/offline capabilities. Migration patterns include rehost (lift-and-shift), replatform (make small optimizations), and refactor (re-architect for cloud-native). Storage choices reflect access patterns: S3 for object storage and data lakes, EBS for block storage attached to EC2, EFS for POSIX shared file systems, and FSx variants for managed Windows or high-performance file needs. Databases can be run as managed services like Amazon RDS and Amazon DynamoDB, which offload administrative tasks, or self-managed on EC2 where the customer retains OS, patching, backups, and scaling responsibilities. For containers, managed options reduce operational burden while offering different trade-offs:
- Amazon ECS (EC2 launch): managed orchestration but you manage EC2 hosts.
- Amazon ECS / Fargate: serverless containers with no host management.
- Amazon EKS: Kubernetes managed control plane; you may manage nodes or use Fargate. For quick application deployment without handcrafting every resource, AWS Elastic Beanstalk or CloudFormation templates speed delivery while enforcing standard architectures. Practitioner traps include underestimating the operational effort of self-managed databases or container hosts and forgetting to attach IAM instance profiles to EC2 for secure service access.
Cloud economics: pricing models and cost-optimization practices
AWS offers multiple pricing models to match workload predictability and tolerance for interruption. On-Demand is flexible with no commitment, Reserved Instances and Savings Plans provide steep discounts for steady-state usage, Spot Instances are deeply discounted but can be interrupted, and Dedicated Hosts meet regulatory or licensing needs. Cost visibility and control rely on tagging, Cost Explorer, AWS Budgets, and AWS Cost Anomaly Detection; rightsizing tools like AWS Compute Optimizer and Cost Explorer resource recommendations help identify overprovisioned EC2 instances. Trusted Advisor exposes cost and performance optimizations and highlights orphaned resources, while AWS Budgets can trigger SNS alerts when spend exceeds thresholds. Common traps include purchasing Reserved Instances or Savings Plans without analyzing historical utilization, applying Spot Instances to critical, non-interruptible workloads, and failing to implement consistent tagging which undermines chargeback and optimization efforts. Decision criteria should combine workload patterns, tolerance for interruption, and forecasting: use On-Demand for unpredictable loads, Savings Plans or RIs for sustained baselines, and Spot for flexible, fault-tolerant compute.
Security, shared responsibility, and operational best practices
Security in AWS is a shared model: AWS secures the cloud infrastructure (hardware, network, regions, Availability Zones, and foundational services), while customers secure in the cloud—this includes data, access control, application-level encryption, OS and software patching for IaaS, and identity federation. Use IAM roles attached to EC2 instance profiles to grant temporary, least-privilege access to services such as S3; avoid embedding long-lived credentials in instances. Data protection features include S3 versioning and Object Lock for retention, server-side encryption (SSE), and client-side encryption for sensitive records. Monitoring and auditability rely on CloudTrail for API logging, AWS Config for configuration compliance, Amazon Inspector for vulnerability assessments of EC2 workloads, GuardDuty for threat detection, and Amazon Macie for sensitive data discovery in S3. The Well-Architected Framework guides operational, security, reliability, performance, and cost considerations; common practitioner errors include overusing the root account, neglecting automated backups, and not implementing multi-AZ architectures or Disaster Recovery plans. Operational decisions should prioritize automation, least privilege, and centralized logging to reduce human error and accelerate incident response.
Practical Problem: Use-Case Scenario
Scenario: Acme Analytics runs a seasonal data-processing pipeline in a single AWS Region. Their environment includes EC2 instances for compute, an on-premises archive, and an S3 data lake. They need to ingest 50 TB from on-prem each season, ensure high availability during runs, and control costs between seasons.
Challenge: Bulk data transfer of 50 TB with limited bandwidth and a need for durable, auditable ingestion; compute must be highly available for a two-month processing window and cost-efficient when idle.
Recommended Approach:
- Order Amazon Snowball Edge to securely import the 50 TB into Amazon S3, using edge compute if pre-processing is required.
- Store the ingested data in an S3 bucket with versioning enabled and apply S3 Object Lock for retention of source records.
- Run processing on Auto Scaling groups of EC2 instances across multiple Availability Zones or use AWS Batch/ECS Fargate for managed scaling during the two-month window.
- Implement Cost Explorer, AWS Budgets with alerts, and apply Savings Plans or Reserved Instances only for baseline persistent resources; terminate or scale down compute after the season.
Rationale: Snowball Edge minimizes transfer time and network costs for large one-time imports while S3 provides durable, auditable storage. Using Auto Scaling or managed compute during peak months delivers availability and only incurs cost when processing, while cost-management tools prevent unexpected spend.
All domains · AWS Global Infrastructure →
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 →