Huawei HCIP-Cloud Service Solutions Architect common mistakes
Huawei HCIP-Cloud Service Solutions Architect · Understand the traps and how to avoid them.
Starting the answer at the product-selection step: listing ECS/ELB/RDS/OBS before writing down availability target, RTO/RPO, compliance scope and traffic profile, then justifying the products by 'we usually use these'.
The exam scenarios are deliberately under-specified on the surface but carry hidden constraints (data residency, peak concurrency, regulated data, 99.99% target). Candidates who answer by pattern-matching to familiar services ignore the one constraint that changes the correct architecture, and lose the 'best design' marks even when the technologies named are valid.
What to do instead
Before choosing services, write a five-line constraint block in the scratchpad: availability target, RTO/RPO, data residency/compliance, peak vs average load, and budget posture. Then eliminate options that violate a constraint before comparing the survivors on cost or convenience.
Configuring an Auto Scaling group with min = max (or with no scaling policy at all) and judging the design 'highly available'; also leaving the default cooldown/health-check grace period untouched so newly launched instances are killed before they finish booting.
Candidates conflate 'instance count is fixed' with 'stable', because fixed counts feel safe and remove the fear of the group shrinking under load. In practice a fixed group has no elasticity benefit, and mis-set grace periods cause flapping that looks like an application fault in the scenario description.
What to do instead
State explicitly: min = normal baseline, max = peak headroom, and a policy (scheduled/periodic or metric-based) plus a cooldown long enough for boot + registration. Set the health-check grace period longer than the application start time and bind the group to the ELB health check, not just the ECS status check.
Choosing a plain EVS data disk and attaching it to several ECS instances in a web/app cluster so the nodes 'share the same data', or choosing OBS for a low-latency database data directory.
The words 'block storage' and 'shared' get separated in candidates' heads: EVS is the default disk they have used, so they reuse it for a multi-node requirement without checking the access model or the filesystem type the scenario implies.
What to do instead
Apply the protocol test: single-instance low-latency block device (EVS, or a shared EVS volume only with a cluster-aware filesystem and a declared multi-attach limit), shared POSIX file access for multiple instances (SFS/SFS Turbo), shared object access over HTTP (OBS), and archival of cold data (OBS infrequent/archive tiers, watching minimum storage duration and restore latency).
Drawing a hub VPC that peers with branch VPCs and then treating the peered VPCs as able to reach each other 'through' the hub; or showing a single Direct Connect connection as the only on-premises path and labelling the design redundant.
Peering is mentally modelled as ordinary routing, and a single physical circuit is mentally modelled as a 'direct, therefore reliable' link. Both assumptions are invisible in a neat topology diagram, so they survive review until the failover question is asked.
What to do instead
Remember peering is strictly pairwise and non-transitive: for hub-and-spoke traffic use a transit-style design (a router/firewall VPC with the appropriate appliance or enterprise router capability) or explicit spoke-to-spoke peerings. For hybrid paths, pair two Direct Connect connections from different locations/carriers, or combine Direct Connect with a VPN over the internet as the backup path, and name the failover mechanism.
Specifying 'an ELB' without stating layer 4 vs layer 7, shared vs dedicated, listener protocol, health-check method/port, or that backends sit in multiple AZs - and putting the health check on a port that is not the one the application actually serves.
ELB is treated as a generic checkbox for 'load balancing'. The scenario's differentiators (sticky sessions, TLS offload, WebSocket, cross-AZ traffic cost, dedicated instance for high throughput) are only visible if the layer and type are chosen deliberately.
What to do instead
Decide from the traffic: TCP/UDP or non-HTTP protocols -> layer 4 listener; HTTP/HTTPS features (host/path routing, TLS termination, session affinity) -> layer 7. Choose dedicated ELB when the scenario needs guaranteed capacity or isolation; otherwise shared ELB is sufficient. Always state cross-AZ backend distribution and a health check that reflects real application readiness.
Granting workloads account-level AK/SK and broad policies such as an administrator policy 'to avoid permission errors', and placing all resources in one IAM project or ignoring that some services are administered at a different scope than others.
During practice labs the fastest way to make an error message disappear is to widen permissions or paste a long-lived key; that habit transfers straight into exam answers, where 'least privilege' and 'temporary credentials' are exactly the discriminators.
What to do instead
Design with IAM users/groups and role-based policies scoped to the specific resources and actions, use agencies (or temporary credentials obtained via the security token service) for ECS/CCE workloads that call OBS or other services, and rotate/eliminate long-term keys. Check whether each service in the answer is administered at account, region or project level before writing the permission statement.
Using WAF, cloud firewall and host security as interchangeable words for 'the security layer' - for example placing a host-security agent in front of a public web application, or using a cloud firewall to stop SQL injection in HTTP requests.
All three products appear in security sections of study material and all sound like HTTP protection. The candidates who fail cannot separate the layer (application request vs network flow vs operating system) from the control.
What to do instead
Map by layer: WAF for inbound HTTP/HTTPS request inspection and web attack signatures in front of the ELB/EIP; cloud firewall for north-south and east-west network traffic control at VPC boundaries; host security for OS-level hardening, vulnerability and intrusion detection on ECS/BMS. Separately keep security groups (stateful, instance-level) distinct from network ACLs (stateless, subnet-level) when asked about traffic filtering.
Answering every persistent-data requirement with a single RDS instance, even when the scenario states tens of thousands of concurrent transactions with a sharding key, or heavy columnar aggregation reporting over large history tables.
RDS is the most familiar managed database, so it becomes the default answer; candidates do not check whether the scenario needs horizontal sharding (which a single RDS primary cannot provide) or analytical scanning (which a row-store primary serves badly).
What to do instead
Classify the workload first: standard OLTP within one instance -> RDS; OLTP needing horizontal sharding with a sharding key -> distributed database middleware such as DDM over RDS/MySQL; large-scale analytical aggregation and reporting -> columnar MPP warehouse such as DWS; caching/session and volatile high-QPS reads -> DCS. If the answer keeps RDS, state the read replica, backup and failover design that backs the availability claim.
Presenting scheduled backups or cross-region object replication as the disaster recovery plan and claiming Tier-3/Tier-4-class recovery, without ever stating an RPO or RTO, and without asking whether the standby region has pre-provisioned capacity and DNS/traffic cutover.
Backup and DR both produce 'a copy of the data', so they collapse into one idea. The tell on the exam is a scenario giving an aggressive recovery objective; a backup-restore answer can never meet it because restore time is proportional to data volume.
What to do instead
Start from the numbers: near-zero RPO and minutes of RTO require synchronous or near-synchronous replication with warm standby resources (active-active or active-standby across AZs/regions); moderate RPO with hours of RTO allows pilot-light or backup-and-restore. Always add the cutover mechanism (DNS, global traffic distribution, ELB switch) and verify that capacity exists in the DR site.
Recommending prepaid/yearly commitments for a spiky or seasonal workload because the unit price looks lower, and closing the cost answer without mentioning resources that keep billing after the ECS is deleted (unbound EIPs, unattached EVS volumes, retained snapshots/backups, idle load balancers).
Cost questions invite a single 'cheapest per hour' comparison, and resource-deletion side effects are not shown on any console screenshot, so they are never noticed during lab practice.
What to do instead
Match billing model to the load curve: pay-per-use for short or unpredictable peaks, prepaid commitments only for steady-state baselines, and scheduled shutdown/scaling for predictable idle windows. Add a housekeeping section to the answer: release unbound EIPs, delete or re-purpose unattached EVS, set snapshot/backup retention, and enable cost monitoring with budget or threshold alarms so drift is detected rather than discovered on the bill.