SAE-C01 (Alibaba Cloud Certifications) common mistakes
SAE-C01 · Understand the traps and how to avoid them.
Treating the shared responsibility model as a single split line, so the candidate says the provider secures 'the cloud' and the customer secures 'everything in it' without separating managed service layers (IaaS vs PaaS vs SaaS) per control area.
Study material often presents one diagram; candidates memorize it as a binary and then misattribute controls like patching of a managed database engine or guest OS hardening.
What to do instead
For each service model, write out who owns data, identity, network controls, host/guest OS, runtime, and physical security, then practice classifying controls for a managed database, a container service, and a serverless function.
Choosing the most restrictive or most permissive IAM policy in scenario questions instead of the least-privilege policy that still satisfies the stated task, and ignoring explicit deny precedence.
Candidates equate 'secure' with 'deny everything' or default to admin for convenience, and they forget that an explicit deny overrides any allow.
What to do instead
Practice evaluating policy sets step by step: explicit deny first, then allow evaluation, then implicit deny; for each scenario, name the exact actions and resources needed and reject policies granting more.
Confusing encryption states (at rest vs in transit vs in use) and key management responsibilities, asserting that enabling storage encryption also protects data on the network.
Vendors bundle 'encryption' features, and candidates collapse them into one concept without mapping each to the threat it mitigates.
What to do instead
Build a matrix of data states against controls (TLS, disk/KMS encryption, confidential computing) and, for each scenario, identify the state and the specific control that addresses it before selecting an answer.
Designing for availability by adding redundancy in a single availability zone, or assuming multi-region failover is automatic, without matching the recovery objective (RTO/RPO) to the architecture.
Candidates conflate 'highly available' with 'backed up' and 'multi-AZ' with 'multi-region', and skip reading the stated RTO/RPO in the prompt.
What to do instead
For each design question, extract RTO and RPO first, then choose the minimum architecture (single-AZ redundancy, multi-AZ, multi-region active-passive/active-active) that meets them, and state the tradeoff in cost and complexity.
Ignoring cost and elasticity implications when selecting instance types, storage classes, or scaling policies, picking the technically capable but economically wrong option.
Candidates focus on whether an option 'works' rather than whether it is the right fit for a variable or steady workload, and they overlook lifecycle and reserved-capacity options.
What to do instead
Classify each workload as steady, spiky, or batch, then map to reserved/savings plans, on-demand, or spot; for storage, match access frequency and retrieval latency to the storage tier before answering.
Assuming network connectivity works by default across VPCs, accounts, or subnets, and forgetting route tables, security groups, and NACLs must all permit traffic.
Diagrams show logical links without the layered packet path, so candidates stop at 'the peering exists' and never check routes or stateful vs stateless filtering.
What to do instead
Trace every scenario as a packet path: source subnet route table, target route table, security group (stateful, allow-only), NACL (stateless, ordered allow/deny), then DNS resolution; identify the first layer that blocks.
Mixing public and private subnet placement for resources that must not have direct internet exposure, or misconfiguring NAT vs internet gateway for outbound-only access.
Candidates equate 'has a route to the internet' with 'is public' and forget that private-subnet egress requires a NAT device while inbound requires an internet gateway or load balancer.
What to do instead
For each resource, decide inbound vs outbound need, then place it in a subnet whose route table and gateway configuration matches that need; verify with an explicit inbound/outbound table.
Treating backups and snapshots as a complete disaster-recovery or compliance strategy without testing restoration, retention, immutability, or cross-region copies.
Snapshots are easy to create and appear in the console, so candidates assume recoverability without validating restore time or protection against deletion.
What to do instead
For each data-protection question, specify restore testing cadence, retention and lifecycle rules, immutability/object lock where required, and cross-region or cross-account copies aligned to RPO.
Reading monitoring questions as 'which metric is interesting' rather than 'which signal detects the failure described', and omitting alarms, thresholds, and notification routing.
Candidates learn metric names in isolation and never connect a metric to an alarm action, so they pick a plausible metric that would not fire on the described condition.
What to do instead
For each failure scenario, state the observable symptom, the metric or log event that captures it, the threshold, and the action (alarm, auto-remediation, escalation); reject options lacking an actionable path.
Diagnosing a failure by guessing a single cause instead of working a layered hypothesis (identity/permissions, networking, configuration, resource limits, application) and checking logs for the actual error code.
Time pressure and familiarity bias push candidates to the first plausible cause, and they skip reading the error message or the relevant log stream.
What to do instead
Adopt a fixed triage order: read the error code, check identity and authorization, then network reachability, then configuration and quotas, then application logs; practice naming the evidence that would confirm or eliminate each layer.