ACA CCO common mistakes
ACA CCO · Understand the traps and how to avoid them.
Treating Alibaba Cloud's shared responsibility boundary as if the provider secures everything inside a VPC, so the candidate answers that Alibaba Cloud manages guest-OS patching and security-group rules.
Candidates carry over mental models from fully managed PaaS offerings and assume 'cloud' means provider-managed at every layer, blurring IaaS vs PaaS boundaries.
What to do instead
Draw the boundary explicitly for each service tier: for IaaS (ECS) the customer patches the guest OS and configures security groups; for managed services the provider handles the underlying host. Practice classifying ~20 services as customer- vs provider-managed.
Confusing regions with zones and answering that a single ECS instance automatically spans multiple zones for high availability.
Region/zone terminology is abstract and candidates conflate 'region' with 'datacenter' or assume HA is automatic once you pick a region.
What to do instead
Memorize: a region is a geographic area; zones within a region are isolated datacenters with low-latency links. HA requires deliberate multi-zone deployment (e.g., SLB across zones, multi-zone RDS). Map each HA question to the resource that must be replicated.
Choosing a public IP or EIP when the scenario only needs outbound internet access from a private ECS instance, or vice versa assigning a NAT Gateway when inbound connections are required.
Candidates memorize 'NAT for outbound, EIP for inbound' as a slogan but fail to parse the directionality in the scenario wording.
What to do instead
Before answering, write down the traffic direction (inbound/outbound) and whether the source is on the internet. Outbound-only from private instances → NAT Gateway; stable inbound public endpoint → EIP; internal-only → private IP plus security group.
Selecting the wrong ECS instance family (e.g., compute-optimized for a memory-bound in-memory cache) or ignoring burstable-instance CPU credit behavior for sustained workloads.
Instance family names look similar and candidates focus on vCPU count while ignoring the workload profile (compute vs memory vs general purpose) and burstable credit exhaustion.
What to do instead
Build a one-line mapping: general-purpose for balanced web/app tiers, compute-optimized for batch/encoding, memory-optimized for caches/DBs, burstable for low-average spiky dev workloads. For any 'sustained high CPU' scenario, reject burstable families.
Assuming a security group is stateful in the wrong direction or that a single security group rule opens both inbound and outbound for a port.
Candidates mix up stateful vs stateless behavior and assume rules are bidirectional, which is common when they have only used host firewalls.
What to do instead
State the rule: security groups are stateful (return traffic is auto-allowed) and you must author inbound and outbound rules separately. For stateless ACL-style controls, remember return traffic must be explicitly permitted. Practice tracing a request/response pair through both directions.
Granting a RAM user the AdministratorAccess-equivalent policy or using the root account for automation instead of scoping a custom policy to specific resources and actions.
It is faster to attach a broad policy, and candidates underweight least-privilege questions because they focus on 'will it work' rather than 'is it minimal'.
What to do instead
For every IAM/RAM question, ask 'what is the smallest action + resource set?' Prefer custom policies scoped by resource ARN and action; reserve broad policies for explicit admin scenarios. Also default to RAM roles for service-to-service automation, never root credentials.
Mixing up OSS bucket ACLs, bucket policies, and RAM policies, or assuming an object is public because the bucket ACL is private (or vice versa).
Three overlapping access-control layers exist and candidates treat them as interchangeable rather than evaluating their interaction (most-restrictive/deny wins).
What to do instead
Learn the precedence: explicit deny > explicit allow > default deny, evaluated across RAM policy, bucket policy, and ACL. For 'make one object publicly readable' scenarios, prefer a bucket policy scoped to that object prefix rather than flipping bucket ACLs.
Choosing a single-zone RDS instance or a non-replicated disk for a workload the scenario describes as production-grade with a recovery objective.
Candidates optimize for cost or simplicity and skip the availability clause buried in the scenario, or they confuse backups with replication.
What to do instead
Extract the RPO/RTO and availability language first, then map: high availability → multi-zone RDS / replicated storage; point-in-time recovery → automated backups; disaster recovery across regions → cross-region replication. Backups do not equal HA; replication does not equal backup.
Reading a CloudMonitor alarm question as 'how do I get notified' and missing that the scenario asks for automatic remediation, so they configure only a notification contact.
Alarms and actions are taught together, and candidates stop at the first plausible answer (alerting) without checking whether the requirement is notification or automated response.
What to do instead
For monitoring questions, separate three layers: metric/alarm definition, notification (contact groups), and action (auto-scaling rule, function trigger, or remediation script). If the scenario says 'automatically recover' or 'self-heal', the answer must include an action, not just an alert.
Diagnosing an unreachable ECS instance by changing only one layer (e.g., reopening a security group) without checking route tables, SLB health checks, and OS-level firewalls in sequence.
Troubleshooting questions reward systematic elimination, but candidates jump to the most familiar control (security groups) and stop.
What to do instead
Use a fixed checklist: DNS resolution → EIP/NAT path → route table → security group → SLB listener/health check → guest OS firewall/service. Walk the checklist against the scenario and pick the answer that matches the first failing layer described.