Alibaba Cloud Architect Professional common mistakes
Alibaba Cloud Architect Professional · Understand the traps and how to avoid them.
Choosing a single-AZ deployment for a workload described as business-critical, then defending it on cost grounds, instead of proposing a multi-zone or cross-region topology and addressing cost separately.
Candidates optimize for the cheapest option that satisfies the literal wording of the prompt and overlook that Professional-level scenarios test resilience trade-offs, not minimal spend.
What to do instead
Before answering, extract the availability and RTO/RPO requirements from the scenario and map each requirement to a specific redundancy mechanism (multi-zone SLB/ECS, cross-region replication, backup) before discussing cost.
Treating a VPC as a flat network and placing all tiers in one vSwitch, rather than segmenting into separate vSwitches per tier and controlling traffic with security groups and network ACLs.
Candidates conflate VPC-level isolation with subnet-level isolation and assume a single VPC boundary is sufficient segmentation.
What to do instead
State the segmentation explicitly: one vSwitch per tier or environment, security-group rules as the primary east-west control, and route-table design called out for any hybrid or peering connectivity.
Proposing a lift-and-shift of every server as-is without assessing whether stateful components should be replaced by managed services (RDS, OSS, Redis, Message Queue) during the migration.
Lift-and-shift is the easiest path to describe and candidates default to it to avoid committing to a redesign they are unsure of.
What to do instead
For each workload, classify components as rehost, replatform, or refactor, and justify at least the database and object-storage decisions against operational burden and scaling needs.
Describing a migration plan with no cutover sequence, no rollback path, and no validation criteria - only a list of tools such as DTS or SMC.
Candidates memorize product names and assume naming the tool demonstrates the migration design.
What to do instead
Present migration as phases: assessment, pilot, incremental sync, validation checks, cutover window, and rollback trigger. Name the tool only as the mechanism inside a phase.
Sizing ECS or database instances from a single average-load figure instead of analyzing peak-to-average ratio, burst behaviour, and scaling triggers.
Scenarios often supply one utilization number and candidates anchor on it without asking what the peak looks like.
What to do instead
Derive capacity from peak concurrent load plus headroom, and pair the sizing with an auto-scaling policy that names the metric, threshold, and cooldown.
Monitoring only infrastructure metrics (CPU, memory, disk) and omitting application-level and business-level signals, so the proposed operations design cannot detect a failing user journey.
Candidates equate cloud monitoring with host metrics because those are the most familiar CloudMonitor defaults.
What to do instead
Layer the observability design: infrastructure metrics, application traces and logs, and at least one business KPI, with alert routing and escalation defined for each layer.
Granting broad RAM permissions such as AdministratorAccess to application roles or CI/CD pipelines because the scenario does not explicitly forbid it.
Candidates prioritize making the design work over least privilege, and broad policies are the fastest way to guarantee no permission error.
What to do instead
Apply least privilege by default: scope RAM policies to specific actions and resources, use STS temporary credentials for workloads, and state the separation between human and machine identities.
Encrypting data at rest and calling the design compliant, while leaving data in transit, key management, and audit logging unaddressed.
Candidates treat encryption as a single checkbox and stop at the first control that comes to mind.
What to do instead
Cover the full control set explicitly: TLS in transit, KMS-managed keys with rotation, ActionTrail for audit, and log retention aligned to the stated regulatory requirement.
Answering a multi-part scenario question with a design for only the first requirement, ignoring the second and third constraints embedded later in the prompt.
Under time pressure candidates read until they recognize a pattern and start writing before finishing the question.
What to do instead
Before drafting, list every constraint and requirement as a numbered checklist, then verify the final answer addresses each item by number.
Recommending a product by name without stating what problem it solves in this specific architecture, producing answers that would fit any scenario.
Candidates rely on product familiarity and pattern-matching from study material rather than reasoning from the stated requirements.
What to do instead
For each service named, write one sentence linking it to a requirement in the scenario and one sentence on what happens if it is removed. Delete any service that fails both tests.