Alibaba SysOps Administrator common mistakes
Alibaba SysOps Administrator · Understand the traps and how to avoid them.
Treating a security group as stateful in only one direction and writing separate inbound and outbound rules for return traffic of an allowed connection.
Candidates carry over habits from stateless ACLs or on-premises firewalls and forget that Alibaba Cloud security groups are stateful, so reply traffic is automatically permitted.
What to do instead
For any connection you allow inbound, do not author a matching outbound rule for the response; instead reason about which side initiates the connection and only open the initiating direction. Verify by testing that an allowed inbound SSH session returns traffic without an explicit outbound rule.
Choosing between RAM users, RAM roles, and STS temporary credentials by guessing, then assigning AccessKey pairs directly to ECS instances for application access to OSS.
The exam tests least-privilege identity design, and candidates default to long-lived AccessKeys because that is the familiar pattern from other clouds or from local development.
What to do instead
Attach a RAM role to the ECS instance and let the application obtain STS tokens from the instance metadata service; reserve RAM users with AccessKeys for human or external-system access, and always scope policies to specific resources and actions.
Assuming a snapshot alone restores an ECS instance, or assuming an OSS bucket protects data without versioning or cross-region replication configured.
Candidates conflate disk snapshots (block-level disk images) with full-instance backup and assume object storage is inherently versioned and replicated.
What to do instead
State explicitly that a snapshot restores a disk (and must be used to create a disk or image before it can back an instance), that OSS versioning must be enabled to recover overwritten or deleted objects, and that cross-region replication or lifecycle rules are separate opt-ins for durability and cost control.
Designing an SLB-backed tier without verifying that backend ECS instances are in the correct VPC and zone, or without a health check path that the application actually serves.
Candidates focus on the listener configuration and forget the placement and health-check prerequisites that determine whether traffic ever reaches backends.
What to do instead
Before finalizing a design, confirm SLB and backends share the VPC, that backends span multiple zones for availability, and that the health check protocol, port, and path match a real endpoint on the application; treat an unhealthy backend as a configuration bug to diagnose, not a capacity problem.
Answering scaling questions by adding more ECS instances manually instead of using Auto Scaling groups with scaling rules tied to CloudMonitor metrics, and ignoring cooldown periods.
Candidates default to vertical scaling or manual horizontal scaling because it is conceptually simpler, and they overlook that elasticity requires automated rules and stabilization windows.
What to do instead
For variable-load scenarios, specify an Auto Scaling group with a scaling configuration (image, instance type, SLB attachment), metric-based scaling rules, and a cooldown period to prevent thrashing; reserve manual resizing for steady-state capacity changes.
Assuming CloudMonitor alarms act on their own, or setting an alarm without configuring an action (notification, Auto Scaling trigger, or Cloud Assistant command).
Candidates describe the metric threshold correctly but stop there, forgetting that an alarm is only a trigger and requires an explicit action and contact group to have operational effect.
What to do instead
When asked how to detect and respond to a condition, state the metric and threshold, the alarm rule, the notification contact group or action, and the escalation path; verify the contact group exists and the alarm state transitions are tested.
Using Log Service as a passive log sink and never configuring Logtail collection, indexes, or alerts, then claiming logs are 'monitored'.
Candidates equate 'logs are written somewhere' with observability and skip the collection agent, index configuration, and query-based alerting that make logs searchable and actionable.
What to do instead
Describe the full pipeline: install and configure Logtail on the instance (via Cloud Assistant for fleet-wide rollout), define the Logstore and indexes needed for the queries, and create alerts on saved searches; mention that unindexed logs cannot be efficiently queried.
Designing a multi-zone or cross-region DR plan without distinguishing RTO/RPO requirements, and without accounting for the fact that some resources (such as certain instance types or images) are region- or zone-scoped.
Candidates treat 'multi-AZ' and 'cross-region' as interchangeable resilience buzzwords and do not map the requirement to the specific replication and failover mechanism.
What to do instead
Match the requirement to the mechanism: multi-zone deployment with SLB for availability within a region; snapshots copied to another region, OSS cross-region replication, or a standby environment for region-level DR. State the expected RTO and RPO for each and verify that dependent resources (images, custom images, RAM policies) exist in the target region.
Troubleshooting connectivity by changing security groups repeatedly without a structured check of VPC route tables, NAT gateway or EIP configuration, and DNS resolution.
Candidates jump to the most visible control (security groups) and skip the layered diagnosis that the exam expects, so they miss the actual cause such as a missing route or an instance without a public IP.
What to do instead
Follow a layered checklist: is the instance in the expected VPC and vSwitch; does it have a public IP or a route to a NAT gateway; do route table entries cover the destination; are security group rules correct in the initiating direction; does DNS resolve to the intended address; then test with ping/telnet from a known-good source.
Describing infrastructure automation as 'use the console' or 'write a script', rather than naming ROS templates, Cloud Assistant commands, and API/CLI operations with their scope and idempotency characteristics.
Candidates know the concepts but cannot map them to the specific Alibaba Cloud services, and they overlook that Cloud Assistant is for in-instance command execution while ROS is for resource orchestration.
What to do instead
For repeatable environment provisioning, specify a ROS template with parameters and stack updates; for in-guest operations across a fleet, specify Cloud Assistant commands with the target instance set; for integration, specify API or CLI calls with RAM-scoped credentials. Distinguish one-time scripts from declarative, idempotent templates.