Security, Identity and Access Management
RAM (Resource Access Management) governs identity: users, groups, roles, and policies. A candidate must understand that permissions are granted via policies (system or custom), that RAM users are distinct from the Alibaba Cloud account (root), and that STS temporary credentials and roles are the secure way to grant cross-account or service access. Principle of least privilege drives most questions.
Security groups are the primary network control; understand inbound vs outbound, allow-only rules (no explicit deny in security groups), and priority. Certificates (SSL/TLS) are managed centrally and attached to SLB/HTTPS listeners or CDN; know renewal and that an expired certificate breaks HTTPS.
Traps: assuming a RAM user inherits root permissions (it does not); forgetting that a RAM user needs both a policy and, for console access, a login profile; confusing a role (assumed, temporary) with a user (long-term credentials); assuming security groups support deny rules (they do not - use network ACLs or a firewall appliance). Also, access keys should be rotated and never embedded in code.
Rule of thumb: "cross-account access" → create a role in the target account, grant the source account permission to assume it via STS; do not share access keys.
Worked example: A RAM user can list ECS but cannot start instances - the attached policy grants read-only actions; attach a policy allowing the start action.