Free CLF-C02 practice questions

The AWS Cloud value proposition is the core answer to why organizations choose AWS over traditional on-premises IT: on-demand resources with pay-as-you-go pricing instead of owning hardware.

Option a captures both halves of the value proposition: resources are available on demand (no procurement cycle) and billing is pay-as-you-go (costs track usage). Option b describes the opposite of cloud computing, since the whole point is that customers stop buying and racking hardware. Option c is wrong because AWS billing is variable and metered, not a flat unlimited-use fee. Option d confuses a cloud provider with a managed-services staffing arrangement for on-premises gear, which is not what AWS sells.

1. Recall that a value proposition states what the customer gains versus the alternative, which here is traditional on-premises IT.
2. Identify the two defining traits of the AWS model: on-demand consumption and pay-as-you-go pricing.
3. Eliminate any option that involves buying hardware upfront, flat unlimited fees, or managing on-premises equipment.
4. Select the option that pairs on-demand resources with usage-based billing.

Exam tip: AWS value proposition = on-demand resources + pay only for what you use, instead of owning hardware.

The AWS shared responsibility model divides security duties: AWS handles security OF the cloud (the infrastructure running AWS services), while the customer handles security IN the cloud (everything they put on that infrastructure).

The correct answer restates AWS's own six-word summary of the model: security OF the cloud belongs to AWS, security IN the cloud belongs to the customer. The claim that AWS takes over all security after migration is the most dangerous misconception the model exists to correct, because misconfigured customer resources cause most real cloud incidents. The inverted phrasing swaps the two sides, which is a classic exam trap that relies on reading too quickly. The equal-split option fails because the model assigns most controls wholly to one party; only patch management, configuration management, and awareness and training are shared, and each party acts in its own layer rather than splitting work fifty-fifty.

1. Recall the model's summary phrase: OF the cloud = AWS, IN the cloud = customer.
2. Eliminate any option claiming one party owns everything, since the model is a partnership.
3. Eliminate the option that swaps OF and IN, keeping the mapping mechanical.
4. Reject the equal-split idea because sharing applies only to a few named controls, each split by layer.

Exam tip: Memorize the mapping: AWS = security OF the cloud; customer = security IN the cloud.

AWS offers several ways to access its services: the web-based Management Console for humans, the CLI for terminal scripting, SDKs for application code, and infrastructure as code for provisioning environments.

The scenario describes a person who is new to the account and wants a visual, guided experience — the defining use case for the AWS Management Console, which provides browser-based sign-in, wizards, forms, and dashboards with no scripting or coding required. The CLI is wrong because it is a text-only terminal tool aimed at scripted administration. An SDK is wrong because it exists for software, not people, to call AWS from inside application code. CloudFormation is wrong because it is a provisioning service driven by templates, not an interactive exploration tool.

1. Identify the actor: a human, not a script or an application.
2. Identify the need: visual exploration with wizards and dashboards.
3. Match a human doing visual, low-stakes work to the Management Console.
4. Eliminate CLI, SDK, and CloudFormation because each targets scripted, programmatic, or template-driven work.

Exam tip: A person exploring AWS visually or performing one-time tasks uses the AWS Management Console.

On-Demand Instances are the default EC2 pricing model: pay the published rate while the instance runs, with no upfront payment and no long-term contract.

A first-time application with unknown usage is the classic On-Demand trigger. The team cannot forecast a baseline, so committing to a Reserved Instance would risk paying for capacity that is never used, and the workload is customer-facing, so Spot interruption is unacceptable. Dedicated Hosts solve hardware isolation and BYOL licensing problems, not commitment problems, and carry the highest cost. The common AWS pattern is to run new workloads On-Demand first, measure steady-state usage, and only then cover that measured baseline with a commitment.

1. Identify the workload traits: brand new, unpredictable usage, no commitment desired.
2. Eliminate commitment-based options (Reserved Instances) because usage cannot be forecast yet.
3. Eliminate Spot because a customer-facing app cannot tolerate a two-minute interruption.
4. Eliminate Dedicated Hosts because there is no licensing or physical-isolation requirement.
5. Choose On-Demand: full flexibility now, commit later once usage is measured.

Exam tip: Unpredictable, short-term, or first-time workloads point to On-Demand Instances.

Stop guessing capacity is the advantage that removes long-range demand forecasting: instead of overprovisioning or underprovisioning years ahead, you provision for actual demand and adjust at any time.

The stem's signals are multi-year forecasts and idle hardware from overbuying, followed by provisioning to actual demand in AWS. That is the textbook description of stop guessing capacity. Economies of scale is tempting because both relate to cost, but it explains low unit prices from aggregated customer demand, not capacity planning. Go global in minutes involves geographic expansion, which is absent here. Speed and agility would require language about experimentation or time to market, which the scenario never mentions.

1. Identify the pain in the scenario: forecasting demand years ahead and buying hardware that sits idle.
2. Identify the change after AWS: capacity matches current demand and can be adjusted anytime.
3. Map forecasting-and-overprovisioning language to the stop-guessing-capacity advantage.
4. Rule out economies of scale (pricing), global reach (geography), and agility (experimentation speed).

Exam tip: Forecasting demand and overprovisioning or underprovisioning hardware points to stop guessing capacity.