Alibaba ACP Cloud Computing common mistakes
Alibaba ACP Cloud Computing · Understand the traps and how to avoid them.
Treating SLB as a single-instance appliance and expecting it to keep serving traffic if its backend ECS instances in one zone fail, without configuring a multi-zone or primary/backup deployment.
Candidates conflate SLB with a hardware load balancer or with the ECS instances behind it, and overlook that SLB itself is a regional, multi-zone-capable managed service whose resilience depends on how zones and backend server groups are configured.
What to do instead
Study SLB's zone model: a multi-zone SLB instance distributes traffic across zones, while a single-zone instance plus backend instances in one zone is a single point of failure. Practice mapping a stated availability requirement to a specific SLB deployment (multi-zone instance, backend servers spread across zones, health checks tuned).
Choosing between OSS storage classes (Standard, IA, Archive, Cold Archive) by price alone, ignoring retrieval fees, minimum storage duration, and retrieval latency.
Candidates memorize that Archive is cheapest per GB and stop there, missing that early deletion, per-GB retrieval charges, and hours-long restore times can make the cheapest class the most expensive or unusable choice for a given workload.
What to do instead
Build a decision table: access frequency, retrieval latency tolerance, minimum storage duration, and retrieval cost per class. For scenario questions, first identify how often data is read and how fast it must be available, then select the class and state the trade-off.
Assuming a RAM user with full permissions on a resource can always access it, without checking whether an explicit Deny in a policy, an SCP-style restriction, or a bucket/instance-level policy overrides the Allow.
Candidates learn 'Allow grants access' and forget Alibaba Cloud's explicit-deny-wins evaluation order and the layering of RAM policies, resource policies, and STS temporary credentials.
What to do instead
Memorize the evaluation order (explicit Deny > explicit Allow > implicit Deny) and the difference between identity-based RAM policies and resource-based policies (e.g., OSS bucket policies, RAM roles assumed via STS). Practice tracing a request through each layer.
Designing a VPC with a single vSwitch per zone and then being unable to place ECS, RDS, and SLB resources where required, or assuming vSwitches span zones.
Candidates treat a vSwitch like a VLAN that can stretch across availability zones, or they size one vSwitch for everything, then hit CIDR exhaustion or zone-affinity errors.
What to do instead
Learn that a vSwitch is bound to exactly one zone and one VPC, and that CIDR blocks cannot overlap within a VPC. Practice planning one vSwitch per zone per tier (web, app, data) with non-overlapping CIDRs sized for growth.
Configuring an Auto Scaling group with a scaling rule but no health check or cooldown, then expecting it to replace unhealthy ECS instances immediately and to not oscillate.
Candidates focus on the scaling trigger (e.g., CPU > 70%) and forget that Auto Scaling replaces instances only when health checks mark them unhealthy, and that cooldown and warm-up periods prevent thrashing.
What to do instead
Study the ASG lifecycle: health check type (ECS vs SLB), cooldown period, scaling rule types (simple, step, target tracking), and how scaling activities are triggered. For scenario questions, verify the health check source and cooldown before predicting behavior.
Assuming RDS read replicas are automatically used for read traffic and that failover is instant, without configuring a read/write splitting endpoint or a primary/standby (high-availability) edition.
Candidates conflate read replicas (for scaling reads, manually addressed) with the primary/standby HA architecture (for failover), and expect automatic routing that RDS does not provide by default.
What to do instead
Distinguish RDS editions and topologies: primary/standby HA for failover, read-only instances for read scaling, and the database proxy/read-write splitting endpoint for automatic routing. Match each to the stated read/write ratio and RTO requirement.
Placing ECS instances in a VPC but forgetting to configure a security group rule and a route/NAT gateway, then concluding the instance has no internet access because it lacks a public IP.
Candidates equate 'no public IP' with 'no internet access' and forget that a NAT gateway plus a route table entry and a security group egress rule are all required for outbound access.
What to do instead
Trace the full path: security group egress rule, route table entry pointing to the NAT gateway, NAT gateway in a vSwitch with an EIP, and the instance's private IP in the correct vSwitch. Practice diagnosing 'instance cannot reach the internet' step by step.
Interpreting a CloudMonitor alarm as proof the resource is healthy or unhealthy without checking metric granularity, aggregation period, and whether the alarm rule covers the right resource group.
Candidates treat monitoring as a binary and overlook that alarms fire on aggregated metrics over a period, that missing data can suppress alarms, and that resource-group scoping determines which instances are evaluated.
What to do instead
Learn CloudMonitor concepts: metric, period, statistics, threshold, and the difference between event alarms and metric alarms. For troubleshooting questions, verify the alarm rule's resource scope and the metric's aggregation period before drawing conclusions.
Estimating cost by multiplying instance hourly price by hours and ignoring data transfer, EIP bandwidth billing mode, snapshot storage, and OSS request/retrieval charges.
Candidates anchor on compute price and forget that networking (EIP bandwidth vs pay-by-traffic), storage (snapshots, OSS requests), and cross-region or internet egress are separately billed and often dominate the bill.
What to do instead
Build a cost checklist per architecture: compute (subscription vs pay-as-you-go), storage (disk, snapshot, OSS class and requests), network (EIP bandwidth mode, NAT gateway, cross-region traffic), and database. Practice comparing subscription vs pay-as-you-go break-even points.
Assuming Security Center, WAF, and Anti-DDoS are interchangeable protections, and selecting the wrong one for a given attack (e.g., using WAF for a volumetric DDoS flood or Anti-DDoS for an SQL injection).
Candidates group all security products as 'security' and do not map each product to its layer: host/vulnerability/baseline (Security Center), application-layer HTTP attacks (WAF), and network-layer volumetric attacks (Anti-DDoS).
What to do instead
Memorize the layer for each: Security Center for host asset inventory, vulnerabilities, and baselines; WAF for HTTP/HTTPS application attacks (SQLi, XSS, CC); Anti-DDoS for volumetric and protocol floods. For scenario questions, identify the attack layer first, then pick the product.