CLF-C02 Cheat Sheet

AWS's canonical list names six benefits: trade fixed (CapEx) expense for variable expense, benefit from massive economies of scale, stop guessing capacity, increase speed and agility, stop spending money running and maintaining data centers, and go global in minutes. CLF Domain 1.1 tests these in business wording, so map a scenario's pain point to the matching advantage rather than memorizing the order.

Cloud replaces heavy up-front data-center and server purchases with pay-as-you-go consumption: you pay only when you consume resources and only for how much you consume. This is the advantage to pick when a stem describes avoiding hardware investment before demand is known, or shifting CapEx to OpEx.

Trap Choosing economies of scale when the stem is about avoiding up-front hardware spend. That benefit is about lower per-unit price from aggregated demand, whereas shifting CapEx to OpEx is the variable-expense advantage.

Because AWS aggregates usage from hundreds of thousands of customers, it reaches a lower variable cost than any single organization could on its own and passes the saving on as lower pay-as-you-go prices. This is why cloud unit costs can beat self-run infrastructure, and it is the benefit a stem about lower per-unit cost from scale is pointing to.

Trap Picking the variable-expense advantage when the stem stresses a lower per-unit price driven by AWS's aggregated demand. That lower unit cost is economies of scale, not merely the CapEx-to-OpEx shift.

Provisioning physical capacity ahead of demand leaves you either sitting on expensive idle resources or hitting shortfalls when traffic exceeds the guess. Cloud removes the guess: you access as much or as little capacity as you need and scale up or down with only a few minutes' notice.

Scalability is the ability to grow capacity to meet rising load; elasticity adds the ability to shrink capacity back down automatically as demand falls, so supply tracks demand in both directions and you pay only for what you use. A stem about spiky or seasonal traffic that must avoid both over-provisioning and outages is testing elasticity, not mere scalability.

Trap Treating scalability and elasticity as the same thing. Scaling up alone leaves idle, paid-for capacity when the spike passes; elasticity is what releases it.

Agility is the speed-and-innovation benefit: new IT resources are a click away, cutting provisioning from weeks to minutes and dramatically lowering the cost and time of experimentation. A stem stressing faster time-to-market, rapid prototyping, or innovating quickly maps to agility, a time benefit, not a cost benefit.

Trap Mapping a 'faster time-to-market' or 'experiment quickly' stem to a cost-savings benefit when agility is a speed-and-innovation benefit, not a cost one.

You can deploy an application across multiple Regions worldwide with just a few clicks, giving customers lower latency and a better experience at minimal cost. A stem about serving users in new countries or cutting latency for geographically distant users points to global reach.

Trap Reading 'deploy worldwide for lower latency' as high availability when it is global reach. Surviving a facility failure is the availability benefit delivered by multiple AZs, not by going global.

A single instance is a single point of failure no matter how large, so vertically scaling to one bigger server does not deliver resilience. High availability comes from distributing the workload across multiple Availability Zones so the failure of one facility does not take the application down.

Trap Choosing one larger instance for resilience. A bigger box is still one box, and one AZ; HA needs redundancy across AZs.

The cost benefit is converting capital expense into pay-as-you-go variable expense, not eliminating spend. You still pay for what you consume. Scaling, automation, and reserved commitments reduce and smooth the bill, but they never make compute free.

Trap Picking an answer that says the cloud makes compute free or removes all spending. The benefit is variable cost, not zero cost.

Offloading the undifferentiated heavy lifting of racking, stacking, and powering servers lets teams focus on projects that differentiate the business instead of on infrastructure. A stem about reducing infrastructure maintenance effort, or freeing staff from data-center upkeep, maps to this benefit.

Trap Mapping a 'free staff from racking and powering servers' stem to the CapEx-to-OpEx cost benefit when it is the stop-maintaining-data-centers advantage about offloading operational heavy lifting.

Serving users in many countries with low latency is global reach, achieved by deploying in more Regions or using CloudFront edge locations. Surviving a facility failure within one Region is high availability, achieved with multiple Availability Zones. The exam expects you to pick the right one per scenario rather than conflate them.

Trap Answering a 'survive a data-center failure' stem with more Regions (a reach/latency fix) instead of multiple AZs (the availability fix).

Amazon EC2 Auto Scaling continuously monitors instance health and, when an in-service instance is found unhealthy, terminates and replaces it to keep the group at its desired capacity with no manual intervention. Configured across multiple Availability Zones, if one AZ becomes unavailable it launches instances in another to compensate, which is how a self-healing fleet delivers high availability.

Trap Assuming Auto Scaling only adds capacity for rising load. It also self-heals by terminating and replacing unhealthy instances to hold desired capacity, even when total load is flat.

Dynamic scaling reacts to live CloudWatch metrics. AWS strongly recommends target tracking (hold a metric like average CPU at a target); step and simple scaling are the other two dynamic types. Predictive scaling analyzes historical load to forecast and add capacity ahead of recurring daily or weekly patterns, and scheduled scaling changes capacity at known dates and times. Choose reactive (dynamic) for unpredictable spikes and proactive (predictive or scheduled) for known recurring patterns.

Trap Reaching for scheduled scaling to handle unpredictable spikes. Scheduled fires at fixed times; only dynamic scaling reacts to live demand.

Amazon CloudFront is a content delivery network that caches content at a worldwide network of edge locations (Points of Presence), routing each viewer request to the edge location with the lowest latency, typically the nearest. A globally dispersed audience gets fast delivery without you deploying origin infrastructure in multiple Regions, since only the cached copies live at the edge.

Trap Answering a 'cut latency for a global audience' stem by deploying origin infrastructure into more Regions when CloudFront edge caching delivers the same latency win without standing up origins everywhere.

Amazon S3 Standard (and most other classes) automatically stores each object redundantly across a minimum of three Availability Zones in a Region, with no manual replication. This built-in redundancy delivers 99.999999999% (11 nines) durability and is designed to sustain the loss of an entire Availability Zone. The exception is S3 One Zone-IA, which keeps data in a single AZ and so cannot survive that AZ's loss.

Trap Assuming One Zone-IA matches Standard's resilience. One Zone-IA stores in a single AZ and loses data if that AZ is destroyed.

The cloud consumption model charges only for the resources you actually use, with no minimum and no long-term commitment by default. AWS frames it as "pay only when you consume computing resources, and pay only for how much you consume." This trades a large fixed CapEx outlay for a variable expense that scales with demand.

Trap Treating a fixed monthly fee charged regardless of usage as pay-as-you-go. A flat recurring charge is the opposite of the consumption model.

On-premises total cost spans far more than the server purchase price: power, cooling, physical floor space, hardware refresh cycles, and the staff time spent racking, stacking, and maintaining servers. Moving to the cloud lets you "stop spending money running and maintaining data centers" and redirect that effort to the business.

Trap Costing on-premises only at the server purchase price and ignoring power, cooling, space, refresh cycles, and staff labor, which understates the true total cost of ownership the cloud displaces.

AWS absorbs the data-center heavy lifting (racking, stacking, and powering servers) and managed services remove the burden of patching operating systems and applications. This Cost Optimization design principle frees you to redirect spend and staff from infrastructure toward customer-facing, revenue-generating projects rather than IT plumbing.

Trap Assuming the racking, powering, and patching work simply shifts onto your own staff in the cloud, when AWS and its managed services absorb it so your people can move to revenue-generating work.

Bring Your Own License (BYOL) lets you apply existing software licenses you already paid for (Windows Server, SQL Server, Oracle) to AWS resources instead of buying them again. You keep your own vendor support relationship and re-purpose your existing license inventory, avoiding a second purchase.

Trap Picking license-included pricing when you already own reusable Windows Server, SQL Server, or Oracle licenses, paying a second time for software you can bring with you under BYOL.

License-included pricing folds the third-party software license cost into the hourly instance rate, so you don't buy the license separately; AWS holds it. Choose it when you have no existing license and want simple pay-as-you-go; pick BYOL instead when you already own a reusable license.

Trap Reaching for BYOL when you have no existing license, which forces a fresh purchase, when license-included already bundles the software cost into the hourly rate for true pay-as-you-go.

EC2 Dedicated Hosts give you a physical server fully dedicated to your use and provide visibility into the number of sockets and physical cores. That visibility is why they support per-socket, per-core, and per-VM BYOL licenses (Windows Server, SQL Server, SUSE, RHEL) which are bound to the underlying hardware and need host affinity to stay compliant.

Trap Reaching for Dedicated Instances when the license is bound to physical sockets or cores. Dedicated Instances give dedicated hardware but no visibility of sockets/cores, so they only partially support BYOL.

Rightsizing continuously matches provisioned capacity to actual demand, so you stop paying for idle over-provisioned resources while still avoiding the performance risk of under-provisioning. It is the main source of ongoing cost savings once a workload is in the cloud, because cloud resources can be resized on demand rather than bought ahead.

Trap Treating Reserved Instance or Savings Plans commitments as rightsizing, when commitments only discount the rate and rightsizing is matching the instance size and count to actual demand.

AWS Compute Optimizer analyzes configuration and CloudWatch utilization metrics (14-day default lookback) and recommends rightsizing across EC2 instances, Auto Scaling groups, EBS volumes, and Lambda functions to cut cost and improve performance. When a question asks which service recommends a cheaper or better-fit instance size, this is the answer.

Trap Naming Cost Explorer or Trusted Advisor as the dedicated machine-learning rightsizing engine across EC2, Auto Scaling, EBS, and Lambda, which is Compute Optimizer's specific role.

Automating operations reduces manual labor and human error, and scheduling idle dev/test resources to stop outside work hours can save up to ~75%. AWS's own example runs them 40 of the 168 weekly hours instead of all of them. The savings come from not paying for capacity that nobody is using.

The Well-Architected Cost Optimization pillar has five design principles: implement cloud financial management, adopt a consumption model, measure overall efficiency, stop spending money on undifferentiated heavy lifting, and analyze and attribute expenditure. Together they steer you toward paying only for value delivered rather than for raw infrastructure.

The cloud makes it easy to identify the cost and usage of each workload and attribute it transparently to revenue streams and individual workload owners. That attribution is what enables ROI measurement and underpins cost-allocation tagging, chargeback, and accountability for spend.

Migrating an oversized fleet unchanged can cost as much as, or more than, running it on-premises, because the savings come from rightsizing and shutting down idle resources, not from the move itself. Realized cloud savings depend on optimizing after migration, not on lift-and-shift alone.

Trap Assuming a lift-and-shift migration saves money by itself, when an oversized fleet moved unchanged can cost the same or more until you rightsize and shut down idle resources.

AWS Cost Explorer provides interactive graphs and tables to analyze cost and usage, filtering and grouping by dimensions such as service, linked account, Region, and cost-allocation tag to surface cost drivers. It shows up to the last 13 months of history and forecasts roughly the next 18 months from past patterns, and it generates rightsizing and Reserved Instance / Savings Plans purchase recommendations from your prior On-Demand usage.

Trap Choosing AWS Budgets to visualize, group, and analyze historical cost drivers, when Budgets sets thresholds and alerts and Cost Explorer is the tool for interactive analysis and forecasting.

AWS Budgets can alert on actual spend (after it accrues) or on forecasted spend (before it accrues). A forecasted alert fires when current patterns are projected to cross your threshold, giving you time to act proactively instead of finding out after the overspend. Forecasting needs some usage history before AWS can project a trend.

Trap Expecting a forecasted alert to fire on a brand-new account with no usage history, when forecasting needs enough prior usage before AWS can project a trend.

AWS Budgets actions turn an alert into enforcement: when a budget threshold is crossed they can apply an IAM policy that denies provisioning of new resources, attach a service control policy (SCP), or stop targeted EC2 or RDS instances. Each action runs either automatically or only after your manual approval, so a budget alert becomes real, enforced cost control.

Trap Assuming a budget alert by itself stops spending, when only a configured Budgets action enforces control by denying provisioning, attaching an SCP, or stopping EC2 or RDS instances.

AWS Pricing Calculator is a free public web tool (at calculator.aws) that needs no AWS account or cloud experience, letting you model and price a solution before building it. Estimates include upfront, monthly, and annual costs but exclude any taxes, and you can sort them into groups that mirror your architecture and export them as CSV/PDF or a shareable saved link for stakeholders.

Trap Reaching for AWS Pricing Calculator to analyze what you have already spent, when it only estimates a solution before you build it and Cost Explorer reports actual historical cost.

On-Demand carries no commitment and suits new, spiky, or unpredictable workloads. For steady, predictable usage, Reserved Instances and Savings Plans give large discounts (up to ~72%) in exchange for a 1- or 3-year commitment, with longer terms and All Upfront payment maximizing the discount. Standard RIs give the deepest discount but are fixed; Convertible RIs trade some discount for the ability to exchange instance attributes; EC2 Instance Savings Plans commit to an instance family in a Region while keeping size, AZ, and OS flexibility. A zonal (AZ-scoped) RI additionally reserves capacity in that Availability Zone, whereas a regional RI does not.

Trap Putting an unpredictable, spiky workload on a 3-year All Upfront commitment to chase the headline discount. You pay for reserved capacity that often sits idle, wiping out the savings.

AWS License Manager centrally tracks software-license consumption across AWS and on-premises (via Systems Manager inventory) from a single dashboard, and enforces rule-based hard or soft limits so usage stays within your purchased agreements; it is the governance tool for BYOL. It reduces the risk of overages and audit penalties, and lets software vendors (ISVs) issue and distribute licenses to their customers.

Trap Naming AWS Systems Manager as the tool that enforces license limits and tracks consumption, when Systems Manager supplies inventory but License Manager is the governance tool that enforces the rules.

AWS Systems Manager centrally automates repetitive operational work across a large fleet without logging into servers: applying OS patches (Patch Manager), running one command on many nodes (Run Command), executing multi-step runbooks (Automation), and collecting software and configuration inventory. Replacing manual per-instance work at scale cuts operational effort and labor cost.

Trap Reaching for Systems Manager to track license entitlements or recommend cheaper instance sizes, when those are License Manager and Compute Optimizer, while Systems Manager automates patching, commands, and runbooks.

Security "OF the cloud" is always AWS's: the global infrastructure that runs every AWS service. The hardware, the host operating system and hypervisor/virtualization layer, the managed network, and the physical data-center facilities. This boundary never moves regardless of which service you pick; the customer only ever owns what they layer on top.

Trap Treating the guest OS on an EC2 instance as part of AWS's "OF the cloud" scope. AWS owns the host and hypervisor, but the guest OS is the customer's.

Security "IN the cloud" is the customer's: everything configured and placed on top of AWS. The exact scope is determined by the services chosen: the more you manage yourself (e.g. EC2), the wider it gets; the more managed the service, the narrower. It always includes the customer's data, IAM permissions, and encryption choices.

Physical data-center security, environmental controls, and the decommissioning of storage media are AWS "inherited controls" the customer fully inherits and never configures. When a drive reaches end of life AWS destroys it per NIST 800-88; the customer cannot touch or shift this layer.

Trap Assuming the customer can request or perform physical media destruction in an AWS data center, when media decommissioning is an inherited control AWS handles entirely.

Customer data is the one responsibility that never shifts to AWS regardless of service. The customer owns it, classifies it, and decides how it's protected. Even with fully abstracted services where AWS runs everything else, ownership and classification of the data stay with the customer.

Trap Assuming a fully managed or serverless service hands data protection to AWS. Managed services shrink the customer's scope but never absorb the data itself.

Identity and access management is always a customer responsibility: AWS supplies IAM, but the customer creates the users, groups, and roles and applies least-privilege permissions deciding who can access what. This holds across every service, including abstracted ones where IAM is most of what the customer configures.

Trap Expecting AWS to enforce least privilege by default. IAM starts deny-by-default, but scoping access to actual need is entirely the customer's to design.

Encryption is a customer responsibility: AWS provides the tools (client-side and server-side options, KMS keys), but the customer chooses whether to encrypt and turns the options on. AWS never assumes liability for an unencrypted data store the customer left in the clear.

Trap Assuming AWS encrypts all customer data at rest automatically, when enabling encryption and selecting the keys is the customer's choice to make.

Network traffic protection at the customer layer is the customer's: configuring security groups and firewall rules to control what reaches the workload. On EC2 specifically, configuring the AWS-provided firewall (the security group) on each instance is explicitly the customer's responsibility.

Trap Treating the security group as something AWS manages because AWS provides it, when configuring its rules is the customer's responsibility.

Customer responsibility tracks the abstraction level: it is widest on infrastructure services (IaaS like EC2, where you own the guest OS), narrows on managed/container services (like RDS, where AWS takes the OS and engine), and is narrowest on abstracted services (like S3 and DynamoDB, where AWS runs the infrastructure and OS). Responsibility shifts toward AWS as you move up that spectrum.

Trap Assuming the customer's responsibility grows as a service becomes more managed, when it actually shrinks as more of the stack moves to AWS.

Amazon EC2 is IaaS, so the customer manages the guest operating system (including updates and security patches) plus any installed application software and the security-group configuration. AWS only secures the underlying host, hypervisor, and hardware beneath the instance.

Trap Assuming AWS auto-patches an EC2 instance's guest OS the way it patches managed services. On IaaS that patching is the customer's job.

With managed Amazon RDS, AWS owns operating-system and database-engine patching, software installation, automated backups, scaling, and high availability; the customer is left with the data, access control (IAM), encryption choices, and query tuning. It's the canonical "managed service shrinks your share" example versus running your own database on EC2.

Trap Assuming the customer still patches the database engine and OS on RDS the way they would on a self-managed database, when RDS hands both to AWS.

With serverless AWS Lambda, the customer is responsible only for their function code. AWS manages the servers, operating-system maintenance, capacity provisioning, automatic scaling, and logging. The customer still owns the function's IAM permissions and the data it touches, but carries zero OS or server responsibility.

Trap Assuming serverless Lambda also relieves the customer of IAM and data responsibility, when those stay with the customer even though the OS and servers do not.

Patch management is a named shared control: AWS patches and fixes flaws in the infrastructure (and in managed-service software), while the customer patches the guest OS and the applications it runs. The split follows the service: on EC2 the OS patching falls to the customer; on RDS or Lambda it shifts to AWS.

Configuration management is a named shared control: AWS maintains the configuration of its infrastructure devices, while the customer configures its own guest operating systems, databases, and applications. Both sides configure, but each only its own layer.

Trap Assuming AWS configures the customer's guest OS, databases, and applications because it configures its own infrastructure devices, when each party configures only its own layer.

Awareness and training is a named shared control: AWS trains AWS employees, and the customer must train its own employees. Each party is accountable only for educating its own staff, not the other's.

For abstracted services like Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and the platform; the customer accesses endpoints and is responsible for managing the data (including encryption options), classifying assets, and using IAM to apply the right permissions. It is the narrowest customer footprint of any service category.

Trap Assuming an abstracted service like S3 or DynamoDB leaves the customer with nothing to secure, when the customer still owns the data, its classification, encryption options, and IAM permissions.

AWS Identity and Access Management (IAM) controls who is authenticated and authorized in an account, and it's a feature of your AWS account offered at no additional charge. You pay only for the other services your identities then use. It's global, not Regional, so a user, group, role, or policy you create works the same in every AWS Region rather than being scoped to one.

Trap Assuming an IAM user or policy must be re-created per Region or that IAM carries a separate charge. IAM is global and free, unlike most AWS services.

The account root user signs in with the email address used to create the account and has complete access to every AWS service and resource. That access is effectively unlimited, which is why AWS strongly recommends not using it for everyday work and instead creating a separate administrative identity.

Securing the root user means enabling MFA on it, not creating (or deleting any existing) root access keys, and doing daily work from a separate administrative identity. AWS now mandates root MFA and requires it to be registered within 35 days of the first console sign-in; the exam rewards answers that lock the root user away rather than hand it programmatic keys.

Trap Creating root access keys so automation can run as the root user. Workloads should use an IAM role, and root should hold no access keys at all.

A short list of actions can be performed only by signing in as the root user, including changing the account's root email or password, closing the AWS account, restoring access after an IAM administrator locks themselves out, registering as a Reserved Instance Marketplace seller, and enabling S3 MFA Delete. For everything else, use an IAM or Identity Center administrative identity.

Trap Assuming routine admin work such as creating users or editing IAM policies needs the root user. Those are everyday IAM tasks, not the narrow root-only list.

Least privilege means granting only the permissions an identity needs for its task and nothing more, narrowing what a compromised or mistaken credential can touch. On the exam, an option that attaches full administrator or * permissions for convenience is almost always the wrong choice.

Trap Attaching AdministratorAccess or a wildcard * policy 'to keep things simple'. Convenience over least privilege is the classic distractor.

An IAM user group is a collection of users that share the policies attached to the group, so adding a user to the group grants them its permissions in one step. Groups can't be nested (they hold only users, not other groups) and a group is not itself a principal you can authenticate or name in a policy's Principal.

Trap Treating a group as something you can sign in as or reference as a Principal in a resource policy. Groups relate to permissions, not authentication.

An IAM role has no long-term password or access keys; when a principal assumes it, AWS STS issues short-lived credentials for that session that rotate automatically. Roles are the recommended way to grant access to AWS compute (Amazon EC2, AWS Lambda), to federated users, and across accounts.

Trap Picking an IAM user with long-term access keys to grant an EC2 instance or Lambda function permissions. A role with auto-rotating temporary credentials is the recommended choice.

For workloads on AWS compute such as Amazon EC2 or AWS Lambda, attach an IAM role rather than embedding an IAM user's access keys. AWS delivers and rotates the role's temporary credentials to the resource automatically, so there are no long-lived secrets to distribute or leak.

Trap Storing an IAM user's access keys on an EC2 instance or in a Lambda environment variable. Embedded long-term keys are exactly what an attached role removes.

AWS managed policies are standalone policies written and updated by AWS for common use cases; customer managed policies are ones you create and tune for your specific needs. AWS advises starting from a managed policy (often by copying one) and tightening toward least privilege, since a broad managed policy rarely matches your exact requirement.

Trap Assuming you can edit an AWS managed policy to fit your needs. AWS owns and updates those, so you copy one into a customer managed policy to customize it.

Multi-factor authentication requires something you have (a passkey or FIDO security key, a virtual authenticator app, or a hardware TOTP token) in addition to the password, so a stolen password alone can't sign in. AWS recommends enabling MFA for the root user and all privileged IAM users, and now ends support for SMS-based MFA.

Trap Treating a strong or rotated password as multi-factor authentication. MFA requires a second, separate factor such as a security key or authenticator app, not just a better password.

An IAM account password policy sets minimum length, required character types, expiration, and reuse rules for IAM user console passwords. It governs only IAM user passwords (not the root user password, not access keys, and not federated or role-based sign-in) and it can't enforce a lockout after failed attempts.

Trap Expecting the IAM password policy to govern the root user's password or lock accounts after failed logins. It applies only to IAM user passwords and has no failed-attempt lockout.

AWS Secrets Manager encrypts secrets with AWS KMS and can rotate them automatically on a schedule, with managed (no-Lambda) rotation for Amazon RDS, Amazon Aurora, Amazon Redshift, and Amazon DocumentDB credentials. Pick it over Parameter Store when you need built-in scheduled rotation of database or API credentials.

Trap Reaching for Systems Manager Parameter Store when the requirement is automatic credential rotation. Parameter Store stores secrets but does not rotate them.

AWS Systems Manager Parameter Store holds configuration values and secrets, encrypting SecureString parameters with AWS KMS, and its standard tier carries no additional charge. Choose it for simple, low-cost storage when you don't need automatic rotation. AWS itself points you to Secrets Manager for rotating credentials.

Trap Choosing Parameter Store when the requirement calls for built-in automatic rotation. That scheduled rotation is Secrets Manager's job, not Parameter Store's.

Database passwords, API keys, and tokens belong in AWS Secrets Manager or AWS Systems Manager Parameter Store, not in source code or config files where anyone who can read the app can extract them. The application fetches the secret at runtime, so credentials never live in the codebase.

Trap Treating an encrypted source file or a 'private' repository as a safe place to store credentials. Anyone who can read the app can extract embedded secrets, so they belong in Secrets Manager or Parameter Store.

AWS IAM Identity Center (renamed from AWS Single Sign-On in 2022) gives employees one sign-in and one portal to all the AWS accounts and applications they're assigned, and can connect to an existing identity provider. It's the answer for centralized workforce access across many accounts, instead of creating duplicate IAM users in each one.

Trap Creating duplicate IAM users in every account for centralized employee access. IAM Identity Center provides one sign-in across all accounts and is the intended answer.

In AWS IAM Identity Center you define a permission set (a reusable template of IAM policies) then assign a group to an account with it; Identity Center provisions a matching IAM role in that account and lets the users assume it. Sessions are temporary, defaulting to a one-hour AWS account session (up to 12 hours).

Identity federation lets users authenticate with an external identity provider (a corporate directory or a SAML 2.0 / OIDC provider) and then assume an IAM role for temporary AWS access. No new AWS password is created and access stays managed in the existing directory, so there are no long-term AWS credentials to distribute.

Trap Creating a matching IAM user for each employee already in the corporate directory. Federation lets them assume a role with their existing login instead of issuing new AWS credentials.

To let one account's principals work in another account you own, create an IAM role in the target account whose trust policy names the source account, then grant those principals permission to call STS AssumeRole. This delegates access without creating and maintaining duplicate IAM users in every account.

Trap Creating a second IAM user with its own access keys in the other account for cross-account access. A role assumed via STS delegates access without duplicate users or long-term keys.

IAM and AWS IAM Identity Center govern your workforce's access to AWS accounts and resources. Signing in the end users of your own web or mobile app is a separate customer-identity concern handled by Amazon Cognito, not by these workforce services.

Trap Choosing IAM Identity Center to authenticate the customers of your public app. That's Amazon Cognito's job; Identity Center is for your workforce.

FIDO security keys are physical devices that use public-key cryptography for strong, phishing-resistant authentication that TOTP codes can't match. They need no batteries, and a single key can back multiple root and IAM users, which makes them AWS's recommended MFA type for highly privileged accounts.

Trap Picking an SMS text-message or TOTP authenticator code as the phishing-resistant MFA option. Only FIDO security keys use public-key cryptography that resists phishing.

Identity-based policies are JSON documents attached to IAM users, groups, or roles to define what they can do. An inline policy is embedded in a single identity in a strict one-to-one relationship and is deleted with it; a managed policy is preferred when more than one identity needs it. A role's trust policy names which principals may assume the role, and a service-linked role is predefined and owned by an AWS service, so administrators can view but not edit its permissions.

The AWS Management Console, AWS CLI, and AWS SDKs are all clients that ultimately call the same public service APIs: the API is the single control plane beneath all of them. Picking a method is a workflow choice (clicking vs. scripting vs. embedding in app code), not a capability choice, since none of them can do anything the API can't.

Trap Assuming the CLI or SDK can perform some action the Console can't (or vice versa), when all four are just clients of the same underlying API and share its capabilities.

AWS commits that all IaaS administration, management, and access functions available in the Management Console are also available through the API and AWS CLI; new IaaS features reach full Console parity through the API and CLI at launch or within 180 days of launch. So "the Console can do it but the CLI can't" is essentially never the right reasoning for an IaaS task.

Trap Treating an IaaS task as Console-only because it looks click-driven, when AWS guarantees the same functions through the API and CLI within 180 days of a feature's launch.

The AWS Management Console is a browser-based, point-and-click interface, best for one-time setup, learning, visual exploration, and dashboards. Its weakness is repeatability: clicks leave no reusable artifact, so the same setup done twice can drift apart.

The AWS CLI is a single command-line tool that gives direct access to the public service APIs from your shell, with commands roughly equivalent to the Console's actions. That makes tasks scriptable, repeatable, and automatable: the answer when a scenario says "automate," "from a script," or "from the terminal."

Trap Choosing the SDK for a shell-driven automation task, when 'from a script' or 'from the terminal' points at the CLI rather than embedding calls in application code.

AWS SDKs are language-specific libraries (Python, JavaScript, Java, .NET, Go, and more) for calling AWS services programmatically from within your own application. The cue is "from my application" or a named language: an app integrating S3 or DynamoDB uses the SDK, not the CLI.

Trap Reaching for the CLI when the scenario says 'from my application' or names a programming language, where calling AWS in-process is the SDK's job, not the shell's.

Service APIs are the common foundation beneath the Console, CLI, and SDKs: each of those is just a different front end onto the same HTTPS API calls. Understanding this explains why a permission, a quota, or an action behaves identically no matter which interface you used.

Manual Console clicks suit a one-time task, but repeating them by hand invites configuration drift and inconsistency between environments. When a scenario stresses consistent, repeatable provisioning across accounts or Regions, the answer shifts to scripting (CLI/SDK) or Infrastructure as Code (CloudFormation).

Trap Reaching for the Console to stand up identical environments repeatedly, where manual clicks guarantee drift instead of a reproducible result.

AWS CloudFormation is AWS's Infrastructure as Code service: you describe resources in a declarative JSON or YAML template, and it provisions and configures the whole collection together as a single unit called a stack, handling dependency ordering for you. It's the AWS-native answer whenever a scenario wants resources modeled as code and deployed predictably.

Infrastructure as Code defines resources in a text template, so environments can be reproduced identically, committed to version control, peer-reviewed, and torn down on demand: the same revision discipline developers apply to source code. It's the right answer when a scenario stresses consistency, repeatability, or change tracking.

There is no additional charge for AWS CloudFormation when it provisions AWS resource types (the AWS::* namespace): you pay only for the underlying resources it creates, exactly as if you'd made them by hand. (Third-party/registry resource types and Hooks are the narrow exception, billed per handler operation.)

Trap Assuming CloudFormation adds a service fee on top of the resources it provisions, when AWS resource types carry no extra CloudFormation charge.

AWS CloudFormation manages a stack as one unit: if a create or update fails, it automatically rolls the resources back to their previous working state rather than leaving a half-built stack. With StackSets, a single template can also deploy and manage resources across many accounts and Regions at once.

A deployment model is chosen by where the workload runs: cloud (fully in AWS), hybrid (cloud resources connected to existing on-premises infrastructure), or on-premises (your own data center, sometimes called private cloud). Match it to latency, data-residency, and migration constraints rather than treating cloud as automatically correct.

A cloud (all-in) deployment runs every part of the application in AWS, whether built there natively or migrated in, giving elasticity, global reach, and pay-as-you-go pricing with no hardware to own. It's the default for cloud-native apps with no on-premises tie.

A hybrid deployment connects existing on-premises infrastructure with cloud resources, extending the data center into AWS rather than replacing it. The usual drivers are phased migration, low-latency local processing, data-residency rules, and protecting prior on-premises investment.

AWS Outposts is a fully managed service that places AWS-designed hardware in your own data center and runs it using the same APIs, tools, and management as an AWS Region: AWS operates it as an extension of a Region. It's the go-to for a consistent hybrid experience when low-latency or local-data needs require AWS infrastructure on-site.

Trap Picking a plain Site-to-Site VPN or Direct Connect link when the requirement is actually AWS compute and storage physically on-premises, which only Outposts provides.

An on-premises (private cloud) deployment runs entirely in your own data center using virtualization and resource-management tools, with no public-cloud component, forgoing most cloud benefits in exchange for dedicated, fully local resources. It's chosen when strict isolation or full physical control is mandatory.

Map the scenario's wording to the interface: "point-and-click / new to AWS / visual" → Console; "script / terminal / automate" → CLI; "from my application code / a named language" → SDK; "repeatable / consistent / template / Infrastructure as Code" → CloudFormation. The keyword is usually the whole signal.

CloudFormation gives three core stack controls: drift detection flags resources whose live configuration no longer matches the template (e.g., someone edited them in the console); change sets preview exactly which resources an update will add, modify, or delete before you execute it; and deleting the stack removes all its provisioned resources together in one coordinated operation.

Trap Confusing change sets with drift detection, when change sets preview an update before you run it and drift detection reports out-of-band edits after they happen.

Amazon EC2 provides resizable virtual servers where you own the OS and stay responsible for patching, scaling, and capacity, so it trades maximum control for maximum operational work. Pick it for legacy or licensed apps, a specific operating system, or long-running stateful workloads that need low-level access.

Trap Reaching for EC2 when the scenario's real goal is to minimize operational overhead. That points at a managed or serverless service instead.

AWS Lambda runs event-driven code in response to triggers like S3 uploads, API calls, and schedules, with no servers to provision and billing only while your code executes. It is the answer whenever a scenario says "run code without managing servers" and scales automatically with the request rate.

Trap Choosing Amazon EC2 for a short event-driven task whose requirement is explicitly "no servers to manage."

AWS Lambda caps one invocation at 15 minutes, so anything longer-running belongs on Amazon EC2, AWS Fargate, or AWS Batch. The 15-minute ceiling is the single most-tested Lambda limit, so match the workload's runtime against it before answering.

Trap Pointing a job that needs more than 15 minutes at Lambda. It will time out, not stretch.

AWS Fargate is a serverless, pay-as-you-go compute engine that runs Amazon ECS or Amazon EKS tasks without you provisioning, patching, or scaling EC2 hosts. Pick it for "run containers but don't manage the underlying servers," paying only for the resources each task uses.

Trap Selecting the EC2 launch type for containers when the scenario explicitly says the team should not manage the underlying instances.

Amazon ECS is AWS's own container orchestrator, while Amazon EKS is managed, conformant Kubernetes for teams already standardized on Kubernetes tooling. Choose EKS when the scenario stresses existing Kubernetes skills or portability; choose ECS for a generic "run containers on AWS" with less Kubernetes overhead.

Trap Picking Amazon EKS when no Kubernetes requirement exists. It adds Kubernetes complexity that plain Amazon ECS avoids.

Amazon Elastic Container Registry (ECR) is a managed registry that stores, versions, and shares the container images that Amazon ECS, Amazon EKS, and AWS Lambda pull at deploy time. It supports private repositories with IAM-based access control.

Trap Confusing Amazon ECR, which stores the container images, with Amazon ECS, which runs them: the registry holds images while the orchestrator schedules the running containers.

Amazon EC2 Auto Scaling launches instances when demand rises and terminates them when it falls, keeping capacity matched to load between a minimum, desired, and maximum size. This automatic add-and-remove behavior is the exam-level definition of cloud elasticity.

Trap Equating elasticity with high availability. Spreading across Availability Zones is the HA mechanism, while elasticity is scaling capacity to demand.

Elastic Load Balancing (ELB) automatically distributes incoming traffic across multiple targets in one or more Availability Zones, runs health checks, and routes only to healthy targets so one failed instance doesn't take the app down. It also scales its own capacity as traffic changes.

Trap Confusing Elastic Load Balancing with Amazon Route 53 for spreading traffic: ELB balances requests across targets within and across Availability Zones, while Route 53 does routing at the DNS level.

Pairing Amazon EC2 Auto Scaling with Elastic Load Balancing keeps the right number of healthy instances running and spreads traffic across them and across Availability Zones: the canonical AWS pattern for high availability and cost-efficiency under changing load. Auto Scaling adjusts the count; ELB distributes the traffic.

Trap Assuming a load balancer alone adds capacity. ELB only distributes traffic; Amazon EC2 Auto Scaling is what changes the instance count.

Amazon EC2 instance families target resource profiles: general purpose (balanced), compute optimized (CPU-bound batch and HPC), memory optimized (large in-memory data), storage optimized (high local-disk IOPS), and accelerated computing (GPUs for ML and graphics). The exam describes a bottleneck and asks which family fits it.

Compute-optimized Amazon EC2 instances offer a high CPU-to-memory ratio for compute-bound workloads such as batch processing, high-performance computing, media transcoding, high-performance web servers, and machine-learning inference. Reach for this family when raw processing power, not RAM, is the constraint.

Trap Choosing compute optimized for a large in-memory dataset. That RAM-bound profile wants the memory-optimized family instead.

Memory-optimized Amazon EC2 instances provide a large amount of RAM per instance for workloads that process big data sets in memory, such as in-memory and high-performance databases, in-memory caches, and real-time big-data analytics. Reach for this family when memory, not CPU, is the constraint.

Trap Picking memory optimized for a CPU-bound batch or HPC job. That compute-bound profile wants compute optimized instead.

Accelerated-computing Amazon EC2 instances add hardware accelerators such as GPUs to handle floating-point math, graphics processing, and pattern matching far faster than CPUs alone, fitting machine-learning training and inference, graphics rendering, and scientific simulation. The hardware accelerator is the distinguishing feature.

Trap Provisioning GPU-backed accelerated instances for a general-purpose web or CPU workload. You pay for accelerators the app never uses.

Amazon Lightsail bundles a virtual server, storage, and networking into a plan at a low, predictable monthly price: the simplest choice for a small website, blog, or simple app versus assembling raw Amazon EC2 and VPC pieces yourself.

Trap Reaching for Amazon Lightsail when the workload needs fine-grained Amazon EC2 instance choice, advanced networking, or large-scale auto scaling.

AWS Elastic Beanstalk takes uploaded application code and automatically provisions the EC2 instances, load balancing, auto scaling, and health monitoring to run it, while you keep full access to and control of the underlying AWS resources. It is the PaaS-style "just deploy my app" answer.

Trap Assuming Elastic Beanstalk hides or locks the underlying resources. You retain full access to the EC2 instances and other AWS resources it creates.

AWS Batch runs large numbers of batch computing jobs and automatically provisions the right quantity and type of compute (across Amazon EC2, Spot, and AWS Fargate) based on the jobs submitted. It is the answer for "run many batch jobs at scale" rather than standing up servers yourself.

Trap Standing up a single Amazon EC2 server to grind through a large batch-job fleet instead of letting AWS Batch provision and scale the compute.

Moving from Amazon EC2 toward containers and then serverless (AWS Fargate, AWS Lambda) hands more of the stack to AWS and cuts operational overhead, but gives up low-level runtime control. The exam frames this as "reduce operational overhead" versus "need full control over the environment."

Trap Choosing Amazon EC2 to "reduce operational overhead". It maximizes control but also maximizes the management you own.

AWS compute pricing trades commitment for savings: On-Demand carries no commitment and the highest hourly rate, while Reserved Instances and Savings Plans cut up to ~72% off On-Demand for a 1- or 3-year term. Within those terms, the 3-year length and a larger upfront payment (All Upfront > Partial Upfront > No Upfront) each yield a deeper discount.

Trap Assuming a No Upfront commitment earns no discount, when it still delivers the term savings just below the All Upfront and Partial Upfront tiers.

On-Demand bills the published per-second/per-hour rate with no upfront cost and no contract. It fits new, spiky, short-term, or unpredictable workloads where a 1- or 3-year commitment would risk paying for capacity you don't use.

Trap Putting a steady, always-on production workload on On-Demand and paying full rate when a Savings Plan or Reserved Instance would cut the bill up to ~72%.

A Reserved Instance is a billing discount applied to matching On-Demand usage, not a physical instance you hold. The discount attaches automatically to running instances that match its attributes: instance type, Region, tenancy, and platform/OS.

Trap Treating a Reserved Instance as a launched/provisioned server you must start, rather than a billing benefit applied to matching On-Demand usage.

Standard Reserved Instances give the largest discount but can only be modified, never exchanged. Convertible Reserved Instances discount less but can be exchanged for another Convertible RI with different attributes, the right choice when future instance needs may change.

Trap Choosing a Standard RI when the instance family or size may change later. Standard RIs can't be exchanged, only Convertible ones can.

A regional Reserved Instance does not reserve capacity, but its discount carries Availability Zone flexibility (any AZ in the Region) plus instance size flexibility within the same family, the latter only on Linux/Unix with default tenancy. Reach for it when you want the discount to float across AZs and sizes rather than guarantee a launch.

Trap Assuming a regional RI guarantees capacity in an AZ. It provides a discount and flexibility, but a zonal RI is what reserves capacity.

A zonal Reserved Instance reserves capacity in one specified Availability Zone, but it has no AZ flexibility and no instance size flexibility: the discount applies only to the exact instance type and size in that AZ. Use it when a launch must be guaranteed in a particular zone.

Trap Expecting a zonal RI's discount to float across Availability Zones like a regional RI, when it is pinned to the one AZ and exact instance size you specified.

A Savings Plan commits you to a consistent compute spend in dollars per hour for a 1- or 3-year term, and AWS applies the discount automatically to matching usage. Unlike a Reserved Instance pinned to specific instance attributes, the commitment is just a spend rate, making it the more flexible way to save up to ~72% on compute.

Trap Thinking a Savings Plan locks you to a specific instance type or configuration like a Reserved Instance, when the commitment is only an hourly dollar spend.

Compute Savings Plans apply the discount to EC2 usage regardless of instance family, size, AZ, Region, OS, or tenancy, and they also cover AWS Fargate and AWS Lambda. AWS recommends Savings Plans over Reserved Instances as the default, easiest way to save (up to ~72%) on compute.

Trap Reaching for an EC2 Instance Savings Plan as the most flexible choice because it discounts more, when only the Compute Savings Plan floats across families, Regions, Fargate, and Lambda.

EC2 Instance Savings Plans give a larger discount than Compute Savings Plans but lock you to one instance family in a chosen Region. Within that family and Region you can still vary size, OS, AZ, and tenancy, so pick it when the family and Region are stable but the discount edge matters.

Trap Buying an EC2 Instance Savings Plan when you may shift instance families or Regions. It locks to one family in one Region; a Compute Savings Plan floats across both.

Reserved Instances and EC2 Instance Savings Plans apply to EC2 only. When savings must also span AWS Fargate or AWS Lambda, the Compute Savings Plan is the one option that covers all three.

Trap Buying Reserved Instances expecting them to discount Fargate or Lambda. Only a Compute Savings Plan covers those services.

Spot Instances run on spare EC2 capacity at up to ~90% off On-Demand, but AWS can reclaim them with only a two-minute interruption notice when it needs the capacity back. They suit fault-tolerant, stateless, or batch work, never a steady production database that can't survive sudden termination.

Trap Running a steady-state production database on Spot. A two-minute reclaim notice can terminate it mid-write.

Spot Instances fit interruption-tolerant work: batch processing, big-data analytics, CI/CD, rendering, and containerized jobs that can resume after a node is reclaimed. The common thread: a lost instance just reruns, so the up-to-90% discount comes at no real cost.

A Dedicated Host is a whole physical server dedicated to you, with visibility into its sockets and physical cores, enabling per-socket/per-core bring-your-own-license reuse and host affinity. A Dedicated Instance also runs on single-tenant hardware for your account but bills per instance and gives no socket/core or host-level visibility.

Trap Choosing a Dedicated Instance for per-socket/per-core BYOL. Only a Dedicated Host exposes socket and core counts for that licensing.

An On-Demand Capacity Reservation reserves EC2 capacity in a specific Availability Zone for any duration but carries no pricing discount on its own: it bills at On-Demand rates. Combine it with a Savings Plan or a regional Reserved Instance to get both the guaranteed capacity and a discount.

Trap Buying an On-Demand Capacity Reservation expecting a price cut. It guarantees capacity at On-Demand rates; pair it with a Savings Plan or regional RI for the discount.

With AWS Organizations consolidated billing, unused Reserved Instance and Savings Plan discounts are shared across all member accounts by default, so a reservation bought in one account benefits matching usage elsewhere. The management account can deactivate this sharing per account from Billing preferences.

Trap Assuming an RI or Savings Plan discount only benefits the account that bought it, when consolidated billing shares unused discounts across the whole Organization by default.

Inbound data transfer from the internet into AWS is free. Outbound data transfer to the internet is charged per GB above a 100 GB/month free allowance (aggregated across services and Regions), which makes reducing egress a primary cost-optimization lever.

Trap Budgeting for inbound data transfer charges, when transfer from the internet into AWS is free and only egress to the internet is billed.

Data transfer between AWS Regions is charged, and data transfer between Availability Zones in the same Region is charged in both directions (typically ~$0.01/GB each way). Traffic that stays within a single AZ over private IP is generally free.

Trap Assuming cross-AZ traffic is free like same-AZ traffic. Moving data between AZs in a Region is billed in both directions.

Lower S3 storage cost means accepting slower or rarer access. For millisecond access: S3 Standard (frequent), Standard-IA (about monthly), and Glacier Instant Retrieval (about quarterly, lowest-cost still-instant tier). One Zone-IA undercuts Standard-IA by storing in a single AZ, safe only for re-creatable or secondary copies. For archives that tolerate delay: Glacier Flexible Retrieval (minutes to hours; Standard ~3-5 h) and Glacier Deep Archive (Standard within 12 h, Bulk within 48 h; the lowest-cost class overall). Use Intelligent-Tiering for unknown or changing patterns: it moves objects between tiers automatically with no retrieval fees.

Trap Putting an irreplaceable primary copy in One Zone-IA to save money. Its single AZ isn't resilient to that AZ's loss; use Standard-IA for the only copy.

AWS charges no data-transfer fee for data moving between services in the same Region, for example S3-to-EC2 or copying between two same-Region S3 buckets (request and storage charges still apply). Data pulled from an AWS origin such as S3, an ALB, or EC2 into Amazon CloudFront is also free. Charges hit data going OUT to the internet and data crossing Regions or Availability Zones.

Trap Expecting a data-transfer charge when CloudFront pulls from an S3 or EC2 origin, when transfer from an AWS origin into CloudFront and between same-Region services is free.