CLF-C02 sample questions — 25 answered and explained

Go global in minutes means the same application can be deployed to AWS Regions around the world through configuration choices, turning a months-long international buildout into hours of work.

The scenario's signals are a new geography and a very short deadline met by deploying into an existing AWS Region. Because AWS already operates Regions worldwide, a company can expand internationally in minutes or hours instead of building or leasing a foreign data center. Elasticity and stop guessing capacity both concern how much capacity runs, not where it runs, and economies of scale concerns price, not speed.

1. Identify the requirement: infrastructure operating in a new geography within a week.
2. Note the AWS outcome: the existing application was deployed to a South American Region in an afternoon.
3. Match rapid deployment into a new geographic Region with go global in minutes.
4. Eliminate options about demand fluctuation, unit pricing, and capacity forecasting.

Exam tip: New country or continent plus rapid deployment equals go global in minutes.

The AWS global infrastructure gives two headline benefits: global reach (deploy near users for lower latency) and speed of deployment (enter new geographies in minutes rather than months).

Running close to users worldwide and reaching new markets in minutes are the two benefits the exam guide names for global infrastructure: global reach and speed of deployment. Automatic copying between Regions is a common misconception; data stays in its Region unless the customer sets up replication. The Availability Zones of a Region all lie in one geographic area, so a single Region cannot satisfy several countries' residency rules. Services and prices also differ between Regions, which is why the Region choice matters.

1. Recall the two global-infrastructure benefits: global reach and speed of deployment.
2. Match lower latency for worldwide users to global reach.
3. Match entering new geographies quickly to speed of deployment.
4. Reject claimed benefits that assume AWS replicates data across Regions, that one Region spans several countries, or that every Region offers identical services.

Exam tip: Global infrastructure = global reach (low latency near users) + speed of deployment (new geographies in minutes).

Elasticity is scalability made automatic and bidirectional: the system acquires resources as demand rises and, crucially, releases them when demand falls so you stop paying for unneeded capacity.

The stem contains both defining halves of elasticity: automatic acquisition when demand rises and automatic release when demand falls. High availability answers a different question, surviving failure rather than tracking demand, and is the most common swap on the exam. Agility describes how fast people and organizations can move, not how resources scale. Durability belongs to data storage, measuring protection against data loss, and has nothing to do with compute capacity.

1. Underline the two behaviors in the stem: acquire resources automatically on demand increase, release them on demand decrease.
2. Recall that automatic plus bidirectional scaling is the definition of elasticity.
3. Confirm no failure or downtime language exists that would suggest high availability.
4. Select elasticity and discard the people-speed and data-protection terms.

Exam tip: Elasticity = automatic scaling in BOTH directions; the release-when-demand-falls half is the tell.

High availability is the property of staying operational through failures. It is achieved with redundancy, running the workload in more than one place, plus automatic detection and failover.

Continuing to operate with minimal interruption when a component or a whole data center fails is the definition of high availability, achieved by running redundant copies in separate locations such as multiple Availability Zones. Elasticity and horizontal scaling are both about matching capacity to load, not surviving failure; more instances in the same data center still fail together. Agility is the organization's speed of experimentation, not a property of a running system.

1. Identify the event in the stem: a component or data center failure.
2. Identify the desired outcome: the workload keeps running with minimal interruption.
3. Match surviving failure with minimal downtime to high availability.
4. Distinguish it from elasticity, which responds to demand rather than failure.

Exam tip: Failure plus minimal downtime = high availability; demand plus capacity change = elasticity.

Elasticity is the benefit that matches capacity to fluctuating demand automatically and in both directions, so the bill tracks actual usage.

The scenario contains both elasticity triggers: demand that fluctuates, holiday peaks versus quiet nights, and the cost goal of paying only for capacity in use, which requires resources to be released when demand falls. High availability is the perennial look-alike, but nothing in the stem mentions failures or downtime; the system's challenge is demand, not fault tolerance. Agility would need language about experimentation or delivery speed. Global reach would need users in multiple geographies, which the stem does not mention.

1. Spot the demand pattern: large seasonal peaks and near-idle overnight periods.
2. Spot the cost goal: pay only for capacity actually in use.
3. Combine fluctuating demand with bidirectional cost tracking to identify elasticity.
4. Confirm the absence of failure language, ruling out high availability.

Exam tip: Fluctuating traffic + pay only for what is used = elasticity.

Agility is a benefit for people and the business rather than a property of a running system: it is the speed at which an organization can experiment, build, change, and abandon ideas cheaply.

All three facts in the stem are agility outcomes: provisioning in minutes removes waiting, testing ideas in days shortens time to market, and shutting down failures without sunk hardware costs makes experimentation cheap. Scalability and elasticity are system properties about handling load, and no load or traffic pattern appears in the scenario. High availability is about downtime during failures, which is also absent. The distinguishing move is noticing that the subject of every clause is the organization's speed, not the system's behavior.

1. Read what improved: provisioning time, experiment turnaround, and the cost of abandoning failures.
2. Notice these describe organizational speed, not system load handling or uptime.
3. Map faster experiments and cheap failure to agility.
4. Eliminate the system-property terms: scalability, elasticity, and high availability.

Exam tip: When the benefit belongs to the business (experiment faster, fail cheap), the answer is agility.

Some responsibilities shift between services (operating system and platform patching); others never move (data, encryption key and setting choices, and access management stay with the customer; physical infrastructure stays with AWS).

IAM permissions and encryption choices depend on the customer's intent, so they stay with the customer on every service. Services such as Amazon S3 and Amazon DynamoDB now encrypt data at rest by default, but choosing the keys and settings that meet the customer's own requirements is still the customer's decision. Operating system patching is the tempting distractor because it is customer work on EC2, but on Lambda AWS manages the OS, so it does not hold on every service. Physical security and hardware disposal are constant too, but on AWS's side.

1. Test each option against two services at opposite ends: EC2 and Lambda.
2. Keep only duties that are the customer's on both.
3. Remove OS patching, which moves to AWS on Lambda.
4. Remove facilities and hardware, which are always AWS's.

Exam tip: Constant on the customer side: data, encryption choices, IAM. Constant on the AWS side: facilities and hardware.

AWS names three shared controls, where both parties act in their own layer: patch management, configuration management, and awareness and training.

Patch management is shared because each party patches a different layer: AWS the infrastructure, host OS and managed-service software, the customer the guest OS and applications it installs. Data center security and hypervisor updates are AWS's alone, and IAM permissions are the customer's alone, so none of them is shared.

1. Recall the three shared controls.
2. Check whether both parties have a layer of the task to perform.
3. Rule out purely AWS tasks (facilities, hypervisor) and purely customer tasks (IAM).

Exam tip: Shared controls: patch management, configuration management, awareness and training.

Awareness and training is a shared control: each party trains its own workforce.

The control is shared because both organisations have people who can make security mistakes. AWS trains AWS employees; the customer trains its own staff, since AWS cannot stop a customer administrator from falling for a phishing email. The near-twin that lets the customer rely on AWS's program gets the first half right and drops the customer's half.

1. Recall that awareness and training is one of the three shared controls.
2. Ask whose employees each party can actually train.
3. Pick the option where each party trains its own staff.

Exam tip: Awareness and training: AWS trains AWS staff, the customer trains customer staff.

AWS names exactly three shared controls, patch management, configuration management, and awareness and training, distinguishing them from inherited controls (fully AWS) and customer-specific controls (fully customer).

Configuration management and awareness and training both fit the shared pattern: AWS configures its infrastructure and trains its workforce, while the customer configures their resources and trains their staff, so the same control is genuinely performed on both sides at different layers. The distractors each fall into a single-party category. Data classification is customer-specific because only the customer knows which of their data is sensitive and AWS has no equivalent activity to perform. Hypervisor patching sits entirely inside AWS's virtualization layer. Physical and environmental controls are the classic inherited controls: AWS implements them, auditors verify them, and customers simply build on the verified foundation.

1. List the three shared controls from memory: patch management, configuration management, awareness and training.
2. Match the options: configuration management and awareness and training appear on the list.
3. Classify data classification as customer-specific, since AWS performs no counterpart activity.
4. Classify hypervisor patching and physical controls as pure AWS controls that customers inherit rather than share.

Exam tip: Only patch management, configuration management, and awareness and training are shared; everything else belongs wholly to one party.

On Amazon EC2, an infrastructure service, the customer is responsible for the guest operating system, including security updates.

EC2 gives the customer control of the instance's operating system, so the customer patches it, whichever AMI it came from. Shared patch management is the tempting distractor, but the share is by layer: AWS takes the host and hypervisor, the customer takes the guest OS and applications. The hypervisor runs instances; it does not patch them.

1. Identify the service: EC2, an infrastructure service.
2. Identify the layer: the guest operating system inside the instance.
3. Apply the rule: on EC2 the guest OS is the customer's.

Exam tip: On EC2, you patch the guest OS; AWS patches what is under it.

On Amazon RDS, AWS patches the operating system and the database engine; the customer keeps the data, access controls and settings such as the maintenance window.

Moving a database to RDS shifts platform maintenance to AWS, including database engine patching. The customer still chooses when maintenance happens through the maintenance window, which is why the window-based distractor is tempting, but AWS applies the patches. The OS-only split is how a self-managed database on EC2 would look if AWS handled the OS, and on EC2 even the OS is the customer's.

1. Identify the service: RDS, a managed database.
2. Recall that on RDS AWS patches both the OS and the engine.
3. Separate scheduling (the customer's maintenance window) from applying the patches (AWS).

Exam tip: RDS: AWS patches the OS and the engine; you own the data, access and settings.

On AWS Lambda with a managed runtime, AWS manages the infrastructure, operating system and language runtime, while the customer's responsibility shrinks to the function code, its permissions and the data. (With a container image or an OS-only runtime, the customer maintains the runtime it packages.)

With Lambda there is no server, OS, or runtime for the customer to patch: AWS operates and updates the execution environment, including security fixes to the managed language runtime, which is exactly why the shared-responsibility line sits highest on serverless services. The distractors enumerate what remains with the customer even at this level of management: the function code is customer-authored application logic, the IAM execution role encodes the customer's permission choices, and decisions about which data to process are always customer data decisions. The pattern to internalize is that serverless transfers operational work to AWS while code, access, and data stay with the customer.

1. Identify the service: Lambda, a serverless compute service.
2. Apply the Lambda rule: AWS manages everything up through the language runtime.
3. Assign runtime patching to AWS as part of operating the execution environment.
4. Keep code quality, IAM execution roles, and data decisions on the customer's side, since those never transfer.

Exam tip: On Lambda, AWS patches the runtime and everything below it; you own the code, its permissions, and the data.

Moving from EC2 to a managed service like RDS transfers operational security work, OS and database engine patching, to AWS, while data, access, and configuration choices stay with the customer.

On EC2, the customer patched the Linux guest OS and PostgreSQL itself; RDS moves the line up so AWS handles both, which is the defining benefit of the managed service and the precise answer to what transfers. The three distractors name responsibilities that never move. The data remains the customer's on every service, security group rules still encode the customer's decision about which sources may reach the database port, and IAM permissions plus database credentials remain customer access decisions. The exam frames this exact migration to test whether you know that management level shifts operational layers only, never data, access, or configuration ownership.

1. Compare the two columns: on EC2 the customer owns guest OS and database software patching; on RDS, AWS owns both.
2. Identify what changed between the columns: OS and engine patching moved to AWS.
3. Apply the anchors to the distractors: data, network configuration, and IAM never transfer.
4. Conclude that only the operational patching work transfers in an EC2-to-RDS migration.

Exam tip: EC2 to RDS transfers OS and database-engine patching to AWS; never the data, security groups, or IAM.

The exam-level benefits of infrastructure as code with CloudFormation are that environments become repeatable, consistent, less error-prone, and version-controllable.

The two real benefits are the ones the exam guide stresses for infrastructure as code. Templates are plain text, so they can be versioned, reviewed and rolled back like application code. One template deployed many times yields identical environments, removing the drift that manual builds accumulate. The distractors credit CloudFormation with things other features or services do: drift detection only reports manual changes and does not revert them, scaling with demand needs Auto Scaling configuration, and copies in other Regions exist only if you deploy them there.

1. Recall the IaC benefit words: repeatable, consistent, version-controlled, less error-prone.
2. Match version control and rollback to templates being text files.
3. Match consistency to redeploying the same template.
4. Reject claims that CloudFormation automatically reverts changes, scales resources or copies stacks to other Regions.

Exam tip: CloudFormation gives repeatable, consistent, version-controlled infrastructure; it does not revert drift, scale resources or replicate stacks on its own.

Task 3.1 tests the judgment between one-time operations and repeatable processes: one-time manual tasks are legitimately done in the console, while repeated tasks should be captured as code.

The stem stresses every signal of a one-time operation: a single setting, changed once, never again, one account. In that situation the console is not merely acceptable — it is the most efficient answer, because the cost of writing, testing, and maintaining automation would exceed the cost of one careful manual action. The CloudFormation option overengineers a non-repeating task. The SDK option is even heavier, building an application where no application behavior exists. The scheduled CLI script actively contradicts the requirement by making a one-time change recur. The calculus flips only when a task repeats.

1. Classify the task: one-time or repeatable? Here it is explicitly one-time.
2. Recall the rule: one-time tasks may be manual; repeated tasks must be code.
3. Choose the console as the lowest-effort correct tool for a single manual change.
4. Eliminate template, custom app, and scheduled script as automation with no repetition to justify it.

Exam tip: A genuinely one-time task belongs in the console; automation earns its cost only through repetition.

The AWS Cloud Development Kit (CDK) is a code-first path to infrastructure as code: developers write infrastructure definitions in languages like TypeScript or Python, and the CDK generates CloudFormation templates from that code.

The stem asks for infrastructure defined in a familiar programming language rather than hand-written JSON or YAML, which is what the AWS CDK provides. The CDK synthesizes standard CloudFormation templates from that code, so CloudFormation still does the provisioning. CloudFormation on its own is the near-twin: it is infrastructure as code, but authored in exactly the template formats the team wants to avoid. An SDK also uses a programming language, but for runtime service calls from applications, and the CLI runs imperative commands.

1. Spot the requirement: infrastructure as code, authored in a general-purpose language.
2. Recall that plain CloudFormation uses JSON or YAML templates.
3. Identify the CDK as the code-first layer that generates CloudFormation templates.
4. Distinguish the CDK (defines infrastructure) from SDKs (call services at runtime).

Exam tip: The AWS CDK defines infrastructure in real programming languages and generates CloudFormation templates behind the scenes.

CLF-C02 defines three deployment models by where workloads run: cloud (everything on AWS), on-premises or private cloud (everything in your own data center), and hybrid (the two connected together).

A startup with no existing infrastructure that builds entirely on AWS is the textbook cloud deployment: every component lives on AWS, giving the full value proposition of pay-as-you-go pricing, elasticity, and no hardware ownership. Hybrid is wrong because there is no on-premises environment to connect to — hybrid specifically means cloud and on-premises operating together. On-premises is wrong because nothing runs in a company-owned data center. Private cloud is the on-premises model dressed in virtualization tooling, so it fails for the same reason. New applications with no legacy footprint default to the cloud model.

1. Ask where the workloads run: entirely on AWS in this scenario.
2. Match all-on-AWS to the cloud deployment model.
3. Rule out hybrid because there is no on-premises side to connect.
4. Rule out on-premises and private cloud because the company owns no data center.

Exam tip: Everything running on AWS with no on-premises footprint is a cloud deployment.

A hybrid deployment connects cloud-based resources to existing on-premises infrastructure so they operate as one environment, typically over a private link such as a VPN or Direct Connect.

The scenario is the classic hybrid pattern the exam favors: a legacy database staying in the corporate data center while the new tier runs on AWS, with the two connected. The key recognition phrase is connecting existing on-premises infrastructure to AWS. Cloud deployment fails because a significant workload remains on premises. On-premises fails because the web application demonstrably runs on AWS. Multi-cloud is a distractor outside the three CLF-C02 models — it would require a second public cloud provider, and nothing here suggests one; a company data center is not another cloud.

1. Locate each workload: web application on AWS, billing database on premises.
2. Note the connection between the two environments operating together.
3. Match cloud plus connected on-premises to the hybrid model.
4. Eliminate pure cloud, pure on-premises, and the out-of-scope multi-cloud option.

Exam tip: AWS resources connected to workloads in your own data center define a hybrid deployment.

Hybrid deployments arise when something anchors part of the environment on premises; the exam's recurring triggers are legacy applications, data residency or compliance requirements, and gradual migration.

The two correct options are two of the three canonical hybrid triggers. A legacy application that is too expensive or risky to move keeps one foot in the data center while modern workloads run on AWS. Data residency rules that require data to stay in a specific certified facility have the same effect for regulated data. The distractors all describe drivers of a pure cloud model: a startup with no infrastructure has nothing to hybridize, a company racing to close its data centers is executing a full migration, and pay-as-you-go economics is a reason to be in the cloud, not a reason to stay partly out of it.

1. Recall the hybrid triggers: legacy systems, data residency or compliance, gradual migration.
2. Match the immovable legacy application to the first trigger.
3. Match the facility-bound data requirement to the residency trigger.
4. Reject the remaining options as motivations for a pure cloud deployment rather than hybrid.

Exam tip: Hybrid happens when legacy systems, compliance, or phased migration keep part of the environment on premises.

An on-premises deployment runs entirely in an organization's own data center on hardware it owns; when it uses cloud-style virtualization and self-service tooling it is often called a private cloud, but the model is still on-premises.

The location of the workloads decides the model, not the tooling. Everything here runs in a company-owned facility with no public cloud involvement, which is the on-premises model; virtualization plus self-service tooling on owned hardware is what is often called a private cloud. A cloud deployment is tempting because of the cloud-style tools, but those tools do not change where the hardware sits or who owns it. Hybrid needs cloud and on-premises resources connected and working together now, and multi-cloud needs at least one, in fact two, cloud providers.

1. Determine where the workloads run: entirely in a company-owned data center.
2. Recognize virtualization plus self-service on owned hardware as the private cloud description.
3. Classify private cloud under the on-premises deployment model.
4. Reject cloud, hybrid and multi-cloud, because no public cloud resources are in use.

Exam tip: A private cloud is still an on-premises deployment: where the hardware sits decides the model, not the tooling.

AWS Site-to-Site VPN establishes an encrypted tunnel between an on-premises network and AWS over the public internet, offering fast setup and low cost at the price of variable performance.

The stem stacks the Site-to-Site VPN triggers: an encrypted network-to-network connection that is quick to establish and low cost. Because a VPN is configuration on both ends rather than physical installation, it can be running in days, and its IPsec tunnels provide the encryption. Direct Connect fails on setup time and cost because a physical circuit must be provisioned. Client VPN is the near-twin: it is also an AWS VPN, but it connects individual users' devices rather than an entire on-premises network. The bare public internet provides no network-to-network tunnel.

1. List the requirements: network-to-network, encrypted, days-not-weeks setup, low cost.
2. Match an encrypted tunnel over the internet with fast setup to Site-to-Site VPN.
3. Separate Site-to-Site VPN (whole networks) from Client VPN (individual users).
4. Eliminate Direct Connect on provisioning time and cost.

Exam tip: Quick, cheap, and encrypted site connectivity to AWS means a Site-to-Site VPN.

Reserved Instances tie their discount to specific instance attributes, while a Compute Savings Plan ties it to an hourly spend level, so usage can change underneath the commitment.

The company's discount was stranded because Standard RIs cannot change instance family. A Compute Savings Plan avoids this by design: the commitment is a dollar-per-hour spend, and the discount applies to eligible usage in any instance family, size, OS, tenancy or Region, and to Fargate and Lambda. The distractors credit Savings Plans with things they do not do: they reserve no capacity, they have real one- or three-year terms, and their maximum discount is lower than a Standard RI's, not higher.

1. Diagnose the failure: the Standard RI discount was bound to instance attributes, and the migration broke the match.
2. Recall the Compute Savings Plan commitment unit: dollars per hour of compute spend.
3. Conclude the discount would have followed the workload to the new family.
4. Reject capacity, cancellation and bigger-discount claims as false for Savings Plans.

Exam tip: Compute Savings Plans keep their discount through instance-family and Region changes that would strand a Standard RI.

Spot Instances sell AWS's spare EC2 capacity at up to 90 percent off On-Demand, in exchange for the risk that AWS reclaims the instance with a two-minute warning.

The stem states the two facts that make Spot safe and optimal: the job can stop and restart without business impact, and the goal is the lowest possible cost. Spot's up-to-90-percent discount is the deepest AWS offers, beating the up-to-72-percent ceiling of RIs and Savings Plans, so for interruption-tolerant work it is the unambiguous winner. On-Demand pays full price, Dedicated Instances add an isolation premium the scenario does not need, and an RI both discounts less and poorly fits a job that runs only at night.

1. Check interruption tolerance: the job restarts freely, so Spot's reclaim risk is acceptable.
2. Compare discount ceilings: Spot up to 90 percent versus RI and Savings Plans up to 72 percent.
3. Note the nightly schedule fits Spot's flexible capacity model better than an always-on commitment.
4. Eliminate On-Demand (no discount) and Dedicated Instances (isolation premium, irrelevant here).
5. Choose Spot as the cheapest suitable option.

Exam tip: Fault-tolerant, restartable batch work at lowest cost means Spot Instances.

Spot Instances let customers use AWS's spare, unused EC2 capacity at up to 90 percent off On-Demand pricing, with the trade-off that AWS can interrupt them at short notice.

Spot's definition has two halves that travel together: the source of the discount (spare capacity AWS would otherwise leave idle) and the condition attached (AWS reclaims it with a two-minute warning when it needs the capacity). Each distractor describes a different purchasing option: capacity held in one AZ at the On-Demand rate is a Capacity Reservation, a whole server with core visibility is a Dedicated Host, and a one- or three-year term at up to 72 percent belongs to RIs and Savings Plans.

1. Recall Spot's source: spare, unused EC2 capacity.
2. Recall Spot's price: up to 90 percent off On-Demand.
3. Recall Spot's condition: AWS can reclaim the instance when it needs the capacity.
4. Match each distractor to its real owner: Capacity Reservation, Dedicated Host, RIs or Savings Plans.

Exam tip: Spot = spare capacity at up to 90 percent off, reclaimable by AWS with a two-minute warning.