Alibaba ACA Cloud Computing common mistakes
Alibaba ACA Cloud Computing · Understand the traps and how to avoid them.
Treating ECS instance families as interchangeable and picking the cheapest instance type for a workload described as memory-heavy, GPU, or bursty, rather than matching the family (general purpose, compute-optimized, memory-optimized, GPU, shared/burstable) to the stated requirement.
Candidates memorize that ECS is 'elastic compute' and skim the family naming, so they default to a general-purpose or burstable instance without checking the workload profile in the stem.
What to do instead
Before answering any ECS sizing question, write down the workload's dominant resource (CPU, memory, GPU, or spiky low-average CPU) and map it to the corresponding instance family; drill the family naming convention until the mapping is automatic.
Confusing OSS storage classes (Standard, Infrequent Access, Archive, Cold Archive) and assuming any class supports immediate retrieval, or assuming lifecycle rules can transition objects in any direction freely.
All classes look like 'just storage' and the differences are retrieval latency, minimum storage duration, and retrieval fees, which are easy to gloss over when reviewing.
What to do instead
Build a one-page table of OSS classes with retrieval latency, minimum billable duration, and access pattern; then practice lifecycle-rule questions with that table in front of you until the transitions and their cost implications are memorized.
Treating a VPC as a single flat network and forgetting that each VPC has its own CIDR block, route tables, and that cross-VPC connectivity requires peering, a transit hub, or CEN rather than 'it just works'.
Candidates carry over mental models from simpler cloud networks and assume resources in different VPCs can reach each other by default.
What to do instead
Redraw any networking scenario as boxes: VPCs with CIDRs, subnets, route tables, and the explicit connection (peering/CEN/VPN) between them. Answer only after confirming the path exists in the diagram.
Mixing up Security Group and network ACL semantics: treating security groups as stateless or subnet-level, or ACLs as stateful instance-level firewalls.
Both are 'firewalls' and the stateful/stateless and instance/subnet distinctions are the only differentiators, so they blur under exam pressure.
What to do instead
Memorize the two-axis contrast (stateful vs stateless; instance-level allow-only vs subnet-level allow-and-deny) and answer each question by first classifying whether the stem describes instance or subnet scope.
Confusing RAM users, RAM roles, and STS temporary credentials, and granting permissions via AccessKey on the root account or attaching policies to the wrong principal when the scenario calls for role assumption.
The RAM model has several principal types and candidates default to 'create a user with a policy' even when the scenario describes cross-account access or service-to-service access.
What to do instead
For every IAM question, identify the principal (human, application, or Alibaba Cloud service), then choose user vs role vs STS accordingly; practice mapping 'cross-account' and 'service assumes identity' scenarios specifically to roles.
Answering SLB questions without distinguishing CLB (Classic), ALB (Application), and NLB (Network) by OSI layer, protocol support, and typical use case, and assuming any SLB terminates TLS or supports layer-7 routing.
The products share the 'SLB' umbrella and candidates treat them as one product with cosmetic naming differences.
What to do instead
Make a comparison card: layer, protocols, session persistence, health check type, and typical workload for CLB/ALB/NLB; when a stem mentions HTTP routing or UDP/TCP throughput, pick the product by that card rather than by name recognition.
Assuming CDN caches everything indefinitely and ignoring cache-control/TTL, origin pull behavior, and the need to refresh or purge when content changes.
CDN is taught as 'faster delivery' and the caching lifecycle and invalidation mechanics are treated as implementation detail rather than exam material.
What to do instead
Study the request path (edge -> parent -> origin), how TTL and cache headers determine freshness, and when to purge; answer CDN questions by tracing where a request is served from given the stated cache state.
Treating Qwen, Model Studio, and PAI as the same thing, or assuming Model Studio is where you train custom models and PAI is only a chat interface.
The AI portfolio is newer and candidates lump 'AI stuff' together, missing the API/model-service vs platform-for-training distinction.
What to do instead
Define each in one sentence: Qwen as the model family, Model Studio as the managed API/inference service for consuming models, PAI as the platform for building, training, and deploying models. Classify each question by whether it asks to consume a model or to build one.
Confusing the shared responsibility boundary, answering that Alibaba Cloud secures customer data and configurations or that the customer is responsible for physical datacenter security.
Candidates conflate 'the cloud is secure' with 'everything in the cloud is secured by the provider' and don't map each control to a side of the line.
What to do instead
For each security control in a stem, ask 'physical/infrastructure or customer workload/identity/config?' and assign it to provider or customer; practice sorting a list of controls until the boundary is reflexive.
Choosing the highest-tier or most expensive option (multi-zone, dedicated host, max bandwidth) whenever a stem mentions availability or performance, instead of matching the stated requirement and budget constraint.
Exam stems often include a cost or simplicity constraint that candidates skip while pattern-matching on keywords like 'high availability'.
What to do instead
Read the stem twice: first for the requirement, second for the constraint (cost, simplicity, region count). Eliminate options that exceed the constraint before selecting, and note the constraint keywords explicitly in your scratch work.