Alibaba CSA-C01 common mistakes
Alibaba CSA-C01 · Understand the traps and how to avoid them.
Treating Alibaba Cloud RAM (Resource Access Management) as if it were an OS-level user or a VPC-level concept, e.g. answering that RAM controls network access between subnets or that it is used to log into ECS instances.
The acronym 'RAM' collides with the familiar 'random access memory' and with 'roles' in other clouds, so candidates pattern-match to memory or to instance login instead of to identity federation and policy-based authorization.
What to do instead
Anchor RAM as 'Alibaba Cloud IAM': it governs who (users, groups, roles) can call which Alibaba Cloud OpenAPI actions on which resources, via policies. Drill the distinction: RAM = authorization to cloud APIs; ECS instance login = SSH/RDP or Session Manager; network segmentation = security groups and VPC.
Assuming a single ECS instance's inbound traffic is filtered only by a security group and forgetting that a VPC network ACL also applies at the subnet level, or vice versa-answering that one of them is stateless/stateful incorrectly.
Candidates memorize 'security group = firewall' from other clouds and never build the two-layer mental model, and they mix up which layer is stateful (security groups track connections; network ACLs are evaluated per packet).
What to do instead
Memorize the layered model: security group is instance-level and stateful (return traffic auto-allowed); network ACL is subnet-level and stateless (must allow both directions explicitly). When a scenario shows traffic blocked despite a permissive security group, check the network ACL and route table next.
Choosing the wrong storage product for a scenario-e.g. recommending OSS for a POSIX-mounted shared filesystem, NAS for static website hosting with public HTTP access, or ESSD for archival cold data-instead of matching access pattern, protocol, and cost.
Candidates learn product names without the access-protocol axis (block vs file vs object) and the performance/cost tiers, so they pick by brand familiarity rather than by requirements.
What to do instead
Build a decision table keyed on three questions: (1) access protocol-block (cloud disk/ESSD), file (NAS, NFS/SMB), object (OSS, HTTP/S3-style API); (2) performance tier and IOPS needs; (3) lifecycle/cost (OSS storage classes, lifecycle rules). Answer from the table, not from memory of product names.
Confusing SLB (Server Load Balancer) listener/backend configuration with DNS or CDN behavior-e.g. saying SLB terminates TLS for a global audience, or that CDN can route to a private VPC backend without origin configuration.
All three sit in the 'networking' bucket and all 'distribute traffic,' so candidates collapse them. The exam tests whether you know each layer: DNS resolves names, CDN caches at edge, SLB balances within a region.
What to do instead
Separate by layer and scope: DNS = name resolution (and can do global traffic management); CDN = edge caching for cacheable content, origin pull; SLB = regional L4/L7 distribution across backend servers with health checks. For global low-latency static content, chain CDN in front of SLB/OSS; for private backends, configure the origin correctly.
Answering billing questions by picking 'the cheapest option' without considering commitment models-e.g. recommending pay-as-you-go for a steady 24/7 production workload, or subscription for a short-lived test.
Candidates equate 'cost optimization' with 'lowest list price' and ignore utilization profile, which is exactly what the exam probes (reserved/subscription vs pay-as-you-go vs spot/preemptible).
What to do instead
Match pricing model to workload lifetime and predictability: subscription/reserved for steady long-running workloads; pay-as-you-go for spiky or short-lived; spot/preemptible for fault-tolerant batch. Also remember data transfer out and storage request charges are separate line items.
Designing a 'highly available' architecture that places all ECS instances in one zone, or one that uses a single-AZ database, while claiming multi-AZ resilience.
Candidates focus on 'multiple instances' as the HA signal and forget the fault-domain hierarchy (region > zone > instance), so they satisfy instance redundancy but not zone redundancy.
What to do instead
State the fault domain explicitly in every HA answer: distribute instances across multiple zones in a region, put SLB in front with health checks, and use a multi-zone-capable database (e.g. RDS with multi-zone deployment). If the scenario says 'survive a zone failure,' single-zone answers are wrong regardless of instance count.
Treating CloudMonitor as only dashboards, and missing that it drives alerting and auto-scaling actions-or conversely, configuring auto-scaling without a trigger metric and health check.
Monitoring and operations are studied as separate topics, so candidates don't connect 'metric → alarm → action (scale/notify)' as one pipeline, which the exam tests in operational scenarios.
What to do instead
Model the loop: CloudMonitor collects metrics and logs → alarm rules fire on thresholds → alarm actions notify or trigger Auto Scaling. In any scaling question, verify the trigger metric, cooldown, and health-check type (ECS vs SLB) are all specified.
Assuming an ECS instance is reachable from the internet by default, or that assigning a public IP is the only way to expose a service-ignoring EIP, NAT Gateway, and SLB as separate design choices.
Candidates conflate 'instance exists' with 'instance is internet-facing,' and they don't distinguish inbound exposure (EIP/SLB public) from outbound-only access (NAT Gateway).
What to do instead
Learn the exposure menu: public IP/EIP for direct inbound; SLB for balanced inbound; NAT Gateway for outbound-only from private instances; no public IP for fully private. In a scenario, ask 'who initiates the connection?' to choose the right component.
Answering security scenarios with a single control (e.g. 'use a security group') when the scenario requires defense in depth-missing RAM least-privilege, key management, and audit logging as complementary layers.
Candidates reduce security to network firewalling and overlook identity, encryption, and audit as separate control planes that the exam expects to be combined.
What to do instead
Answer security questions in layers: identity (RAM least-privilege, MFA), network (security groups, network ACLs), data (encryption at rest with KMS, TLS in transit), and audit (ActionTrail logging of OpenAPI calls). If a scenario mentions 'who did what,' the answer involves ActionTrail; 'who can do what' involves RAM.
Misreading scenario questions that hinge on a single constraint word (e.g. 'lowest latency for global users,' 'must survive zone failure,' 'must be POSIX-compatible') and answering with a generally good architecture that violates that constraint.
Under time pressure candidates recognize a familiar pattern and answer from template rather than extracting the binding requirement, which is precisely what distinguishes the 'best' option.
What to do instead
Before choosing, underline the binding constraint and the fault/performance domain it implies, then eliminate any option that violates it-even if the option is otherwise well-architected. Verify the surviving option satisfies every stated requirement, not just the most salient one.