Free CLF-C02 practice questions

The AWS Cloud value proposition is why organizations choose AWS over traditional on-premises IT: resources are available on demand and billed pay-as-you-go, instead of being bought and operated by the customer.

Using resources on demand and paying only for what is consumed captures both halves of the value proposition: no procurement cycle, and costs that follow usage. Buying AWS-designed servers upfront is tempting because it mentions AWS, but it keeps the capital purchase and self-run facility the cloud removes. A fixed annual subscription sounds predictable, yet AWS bills by metered usage rather than a flat bundle. Handing servers to AWS staff describes outsourced hosting of customer-owned gear, which is a different business from the AWS Cloud.

1. Recall that a value proposition states what the customer gains compared with the alternative, here on-premises IT.
2. Identify the two defining traits of the AWS model: on-demand consumption and pay-as-you-go pricing.
3. Eliminate anything that keeps upfront hardware purchases, flat fees regardless of use, or customer-owned servers.
4. Select the statement 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 that runs AWS services), and the customer handles security IN the cloud (what it puts on that infrastructure).

The key restates AWS's summary of the model: security OF the cloud belongs to AWS, security IN the cloud belongs to the customer. The swapped version is the classic trap for a rushed reader. The option that gives AWS the customer's data as well treats migration as outsourcing security, which the model exists to correct. The managed-versus-EC2 option confuses the model with its nuance: how much AWS manages does shift by service, but both parties have duties on every service.

1. Recall the summary phrase: OF the cloud = AWS, IN the cloud = customer.
2. Reject the option that swaps OF and IN.
3. Reject any option that hands customer data to AWS, since data is always the customer's.
4. Reject a split drawn by service type; both parties have duties on every service.

Exam tip: 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, which is the defining use case for the AWS Management Console: browser sign-in, wizards, forms and dashboards with no commands or code. CloudShell is the tempting distractor because it also opens in a browser, but it is a terminal for typing CLI commands, not a graphical interface. The CDK defines infrastructure in program code, and CloudFormation provisions resources from templates; neither is a way for a person to explore an account interactively.

1. Identify the actor: a person, not a script or an application.
2. Identify the need: visual exploration with wizards and dashboards.
3. Separate 'runs in a browser' (CloudShell is a browser terminal) from 'graphical interface'.
4. Match a person doing visual, exploratory work to the Management Console.

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.