HCIA-Cloud Service common mistakes
HCIA-Cloud Service · Understand the traps and how to avoid them.
Treating ECS instance families as interchangeable and picking a general-purpose family for every workload, without matching the family to the workload profile (memory-optimized for caches and in-memory databases, disk-intensive for high-IOPS stores, GPU-accelerated for inference/training).
Candidates memorize instance names and vCPU/memory ratios but never build a mapping from workload characteristics to family. Scenario questions describe a workload ('a Redis cache holding 200 GB in memory') and the candidate defaults to the family they saw most often in practice.
What to do instead
Build a one-page table: each ECS family, its ratio/accelerator, and two canonical workloads. Practice reading scenario stems and extracting the deciding signal (memory-to-CPU ratio, IOPS, GPU, burst tolerance) before looking at options.
Confusing ECS scaling policies with AS group configuration: candidates describe adding vCPUs or memory to a single ECS instance when the question asks how to handle traffic spikes, instead of configuring an Auto Scaling group with a scaling policy and a load balancer.
Vertical scaling feels intuitive and is the first thing many administrators do in real life. The exam tests horizontal elasticity via AS, and the wording 'automatic' or 'unpredictable traffic' is the cue candidates miss.
What to do instead
Drill the AS chain end to end: AS group definition (template, min/max/desired, VPC/subnet, ELB association) then scaling policy (scheduled, alarm-based, or periodic). For any 'automatic capacity adjustment' stem, answer with AS plus ELB, not instance resizing.
Confusing IMS (private images) with backup or snapshot services: using a backup to create identical new servers, or expecting an image to roll back a single disk to an earlier point in time.
Both images and backups derive from volumes, so the terms blur. Candidates forget that IMS images are for standardized deployment and replication across regions, while backups/VBS are for point-in-time recovery of existing data.
What to do instead
Memorize the purpose split: image = template for launching new ECS instances (and cross-region/cross-account sharing); backup/snapshot = restore existing data. For 'quickly deploy 50 identical servers', answer IMS image plus AS; for 'recover data after accidental deletion', answer backup.
Choosing OBS for block-level or shared-file use cases, or choosing EVS for data that must be reachable by URL from the internet: candidates pick storage by capacity/price rather than by access protocol and sharing model.
All three are 'storage', and pricing tables make OBS look universally attractive. The exam tests the access-semantics distinction: EVS is block storage attached to one ECS (AZ-bound), SFS is a shared POSIX file system across ECS instances, OBS is HTTP/REST object storage that is region-level and effectively unlimited.
What to do instead
Anchor each service to a question: 'Does an OS mount it as a disk?' EVS. 'Do many servers read/write the same directory concurrently?' SFS. 'Is it accessed by URL/SDK, static website hosting, or backup archive?' OBS. Also note EVS is AZ-scoped while OBS is region-scoped.
Assuming OBS buckets are private by default and that an EIP or VPC rule governs object access: candidates misjudge OBS access control, forgetting bucket policies, IAM permissions, and pre-signed URLs, or thinking an object is public because the bucket policy allows it when account-level policy denies it.
Candidates carry over the VPC/security-group mental model from compute. OBS authorization is a separate layer (bucket policy, bucket ACL, IAM policy, and pre-signed URL), and the exam tests which mechanism fits 'temporary access for an external partner'.
What to do instead
Learn the four OBS access levers and their typical use: IAM policy for internal users, bucket policy for cross-account or anonymous access conditions, ACL for simple object/bucket grants, pre-signed URL for time-limited sharing without credentials. Remember OBS traffic does not traverse your VPC security groups unless accessed through a private endpoint.
Mixing up security groups and network ACLs: applying a security group as a subnet-level control, or expecting a network ACL to be stateful and to reference other security groups.
Both filter traffic with allow/deny rules, so candidates treat them as synonyms. The exam tests scope and statefulness: security groups are instance-level, stateful, allow-only; network ACLs are subnet-level, stateless, and support both allow and deny.
What to do instead
Memorize a two-row comparison table (scope, statefulness, rule types, evaluation order) and practice stems: 'block a specific source IP for the whole subnet' points to a network ACL deny rule; 'allow only port 443 to these instances' points to a security group.
Treating an EIP as automatically required for outbound internet access: candidates attach EIPs to every ECS instance, or claim an instance without an EIP cannot reach the internet, ignoring NAT Gateway and the default route through it.
In small lab setups a single EIP is the usual pattern, so candidates generalize it. The exam tests cost and architecture awareness: many instances should share a NAT Gateway for outbound traffic, reserving EIPs for inbound-facing services.
What to do instead
Draw the outbound path explicitly: subnet route table default route to NAT Gateway, NAT Gateway in a public subnet with an EIP. Then state the rule: EIP for inbound exposure, NAT for shared outbound, and no public IP needed on private instances.
Selecting the wrong ELB type or listener configuration: using a Layer 4 listener for host/path-based routing, or expecting a classic load balancer to terminate TLS with certificate management, instead of choosing the application (Layer 7) load balancer for HTTP/HTTPS features.
Candidates know 'load balancer' as one concept and skip the layer distinction. Exam stems embed cues like 'route by domain name' or 'offload HTTPS certificates', which only the Layer 7 option satisfies.
What to do instead
Build a decision rule: Layer 4 (TCP/UDP) for raw throughput and non-HTTP protocols; Layer 7 (HTTP/HTTPS) for host/path routing, TLS termination, session persistence via cookies, and health checks at the HTTP level. Also confirm the backend server group and health check are configured, since an ELB with unhealthy backends returns errors regardless of listener type.
Conflating IAM, CTS, and CES: describing audit trails as monitoring metrics, or describing alarm-triggered scaling as an audit function, when asked which service records API operations for compliance.
The management family is memorized as a list of acronyms without distinct purposes. Candidates match on vague words like 'track' or 'record' and pick whichever service they saw last.
What to do instead
Fix three one-line definitions: IAM = who can do what (users, groups, policies, agency); CTS = who did what and when (API operation audit trail); CES = how healthy is it (metrics, alarms, dashboards, notifications). For 'compliance audit of console/API actions', answer CTS.
Ignoring region/AZ semantics when designing for availability: placing an AS group or EVS volumes across regions, or assuming a single-AZ deployment survives an AZ failure, and misstating which resources are regional versus AZ-scoped.
Candidates treat 'region' and 'AZ' as synonyms and never learn resource scope. Exam stems about disaster recovery versus high availability hinge on this: multi-AZ for HA within a region, cross-region for DR.
What to do instead
Memorize scope classes: VPC and OBS are region-level; ECS, EVS, and subnets are AZ-level. Then apply the rule: HA = spread instances and AS across multiple AZs in one region behind an ELB; DR = replicate images/backups or OBS data to a second region.