C-CATODSW common mistakes
C-CATODSW · Understand the traps and how to avoid them.
Choosing the single cheapest storage or compute option whenever a scenario mentions cost savings, without first checking the durability, availability, or access-frequency requirements stated in the scenario.
Candidates memorize a rough price ranking (for example, that archival storage is cheapest) and then pattern-match on the word 'cheap', skipping the qualifying details such as retrieval time, minimum storage duration, or cross-region access that make the cheap tier wrong.
What to do instead
Before selecting a tier, write down the scenario's access frequency, retrieval latency tolerance, and durability requirement, then eliminate any option that violates one of them. Only compare price among the surviving options.
Treating the shared responsibility model as a fixed list and answering that the provider secures 'the cloud' entirely, so customers need not configure encryption, patching of guest OS, or access policies.
The phrase 'security OF the cloud vs. security IN the cloud' is memorized as a slogan, but candidates do not map specific controls (hypervisor, guest OS, application data, IAM) to the correct party under different service models such as IaaS versus managed services.
What to do instead
Build a three-column table (provider, customer, shared) and place each control in it for IaaS, PaaS, and SaaS. Practice classifying controls like OS patching, network ACLs, and data classification until the mapping is automatic.
Confusing identity-based policies with resource-based policies, or assuming a role grants permissions by itself rather than requiring a trust relationship plus attached policies.
The terms 'role', 'policy', 'trust', and 'permission boundary' are learned as vocabulary rather than as a flow. Candidates cannot trace how a request is evaluated, so they pick the option that sounds most secure.
What to do instead
Trace one request end to end: principal authenticates, assumes role via trust policy, then the role's identity policy and any resource policy are evaluated. Draw this flow once and reuse it for every IAM question.
Selecting a multi-region or multi-AZ architecture for every high-availability question, even when the scenario only requires tolerance of a single data-center failure.
Candidates over-index on the word 'highly available' and equate it with the maximum-resilience option, ignoring the cost and complexity constraints also stated in the scenario.
What to do instead
Classify the requirement first: single-AZ failure, regional failure, or global disaster. Match the architecture to the smallest tier that satisfies the stated failure domain, and reject options that exceed it.
Mixing up elasticity, scalability, and agility, and choosing 'scale up' when the scenario describes variable, unpredictable demand that needs automatic capacity adjustment.
The cloud concept definitions overlap in everyday language, so candidates rely on intuition rather than the exam's precise distinction between resizing a resource, adding resources, and responding automatically to load.
What to do instead
Write one-sentence definitions with a concrete example for each term, then label every scenario's demand pattern (steady growth, spiky, one-time) before looking at the answer choices.
Assuming a managed database or service automatically provides backups, encryption at rest, or point-in-time recovery without any configuration.
Marketing language around 'managed' leads candidates to believe all operational tasks are handled, when many durability and encryption features are opt-in settings the customer must enable.
What to do instead
For each managed service you study, list which protections are default-on versus customer-configured. When a question asks how to guarantee recovery, prefer the option that explicitly enables the feature.
Ignoring data-transfer and request charges when estimating total cost, and comparing only the headline compute or storage price.
Candidates focus on the largest line item and forget that egress, inter-region replication, and API call volume can dominate the bill for data-heavy workloads.
What to do instead
For any cost scenario, enumerate all four cost drivers: compute, storage, requests, and data transfer in/out. Add transfer explicitly to the estimate before choosing the cheapest-looking option.
Choosing a pricing model (on-demand, reserved, spot) based on the lowest unit price rather than on the workload's interruption tolerance and commitment horizon.
Spot and reserved pricing are memorized as 'cheaper', but candidates do not connect spot's interruption risk to stateful or latency-sensitive workloads, or reserved commitments to short-lived projects.
What to do instead
Map each pricing model to a workload profile: steady long-term, fault-tolerant batch, or unpredictable short-term. State the workload profile from the scenario before selecting the model.
Misreading network boundary questions and placing resources in a public subnet or opening a security group to the internet when the scenario requires internal-only access.
Candidates conflate security groups with network ACLs and forget that a subnet's route table, not its name, determines whether it is public, so they reason from labels rather than from routing and rules.
What to do instead
For each network question, check three things in order: route to an internet gateway, subnet association, and the rule direction and source. Security groups are stateful and allow-only; ACLs are stateless and allow/deny.
Answering compliance questions by naming a certification the provider holds, rather than identifying the customer's own obligation to configure controls and produce evidence.
Candidates see a regulation name and a provider compliance badge and assume inheritance covers the whole requirement, missing that the customer still owns data classification, access review, and audit logging.
What to do instead
For each compliance scenario, separate 'provider-attested controls' from 'customer-operated controls' and confirm the answer addresses the customer side, such as enabling logging or restricting access.