ACP-Cloud1: From Alibaba Cloud Computing Professional to Cloud Architect

ACP-Cloud1 represents Alibaba Cloud’s retired Cloud Computing Professional certification. Alibaba Cloud ended the old credential in 2025 and replaced it with Cloud Architect (Professional), whose current exam code is CAP-C01. Candidates should use CAP-C01 and Alibaba Cloud’s current certification catalog when checking the professional architect path rather than treating the continued existence of an ACP-Cloud1 URL as evidence that the legacy exam is still available.

The transition is substantial rather than cosmetic. The current professional credential is explicitly centered on the work of an experienced solution architect: designing and implementing scalable, resilient Alibaba Cloud solutions while balancing networking, security, reliability, performance, and cost. The Alibaba Cloud certifications now describes professional certification in role terms instead of the older product-oriented ACP Cloud Computing label.

That change gives legacy candidates a useful way to reorganize their knowledge. Instead of preparing by memorizing individual product facts, treat each service as a design component and practice defending architectural choices under requirements and constraints.

The retirement of ACP-Cloud1 changes what candidates should schedule

Alibaba Cloud retired ACP Cloud Computing Professional on May 13, 2025, after an end-of-sales period and a transition window. A person beginning preparation today should therefore target the live Cloud Architect (Professional) certification rather than search for a way to book ACP-Cloud1. Old exam guides can still explain the technology base, but scheduling, renewal, and blueprint decisions must follow the current program.

This is especially important for candidates returning after a long study break. A cloud platform evolves quickly, and a professional-level architect exam is sensitive to changes in service capabilities and recommended design patterns. Before committing to a study resource, confirm that the material reflects the current professional role and not simply the retired ACP code printed on its cover.

Architecture questions begin with requirements, not products

Professional-level cloud work starts by translating business and technical requirements into architecture. Availability targets, latency, data consistency, recovery objectives, compliance needs, expected growth, and cost constraints should drive the design. Product selection comes afterward. This order prevents a common exam mistake: choosing a familiar service first and then forcing the scenario to fit it.

Practice turning prose into constraints. If a workload must survive a zone failure, identify the failure domain. If a database needs read scalability without weakening consistency guarantees, separate read pressure from write requirements. If an internet-facing service needs protection and global performance, identify the edge, traffic-distribution, and security concerns before naming implementation components.

A professional answer should also state what it deliberately does not optimize. For example, a design may choose managed database features and multi-zone redundancy to reduce operational risk even though a simpler single-zone setup would be cheaper. Another design may accept slower disaster recovery because the application is noncritical. Being explicit about the tradeoff is important because architects rarely maximize availability, performance, security, and cost simultaneously. The role is to choose a balanced design that satisfies the stated priorities.

Compute design requires lifecycle thinking

At the professional level, compute is not just about selecting an ECS instance. Candidates should think about provisioning, configuration consistency, images, scaling, health replacement, patching, and the boundaries between stateful and stateless components. An architecture that performs well on day one may become expensive or fragile if every deployment depends on manual server changes.

Elasticity should follow demand patterns and operational evidence. Auto Scaling, load distribution, and capacity policies work best when the application itself can tolerate horizontal change. Study what happens to sessions, local files, background work, and application configuration when instances are created or removed. Those details often distinguish an architect-level answer from a merely functional one.

Data architecture is a balance of durability, access, and performance

Different data workloads demand different storage models. Object storage is attractive for durable, scalable content and data lakes; block storage serves instance-attached workloads; managed relational databases support structured transactions; caching can reduce repeated database work. The architectural skill is to place each data type where its access pattern, durability, latency, and recovery requirements are met without unnecessary complexity.

Professional scenarios also test failure and growth. Think about backup policies, cross-zone or cross-region strategy, replication, read scaling, retention, lifecycle rules, and the consequences of a restore. Design discussions should include who can access the data and how encryption or key management is handled. Data architecture is inseparable from security and business continuity.

Network topology should make trust boundaries visible

Large cloud environments need intentional network segmentation. A professional candidate should be comfortable designing VPC address spaces, subnet tiers, routing, private service access, internet egress, VPN or dedicated connectivity, and load distribution. Address planning matters because poorly chosen CIDR ranges can become painful when environments expand or connect to existing enterprise networks.

Treat every route and gateway as part of a trust model. Which systems are allowed to initiate connections? Which path carries administrative traffic? Which components should never be publicly reachable? How will hybrid routes be propagated and monitored? Clear answers to those questions reduce both operational surprises and security exposure.

Hybrid and multi-environment design also forces address planning to become a long-term decision. Overlapping CIDR ranges can make later connectivity, mergers, or shared-service designs much harder. Professional candidates should therefore treat IP space, naming, routing domains, and ownership boundaries as architecture, not setup detail. The same principle applies to internet exposure: make public endpoints intentional, document why they exist, and keep internal service paths private when possible.

Security architecture should be layered and auditable

Strong cloud security combines identity, network controls, data protection, and evidence. Resource Access Management policies should grant the smallest practical set of permissions. Network controls should limit exposure. Encryption should protect sensitive data at rest and in transit. Logging should make privileged actions and important changes visible enough to investigate.

Architects also need to think about organizational scale. Human administrators, applications, automation systems, and cross-account or cross-project workflows may require different identity patterns. A design that depends on shared long-lived credentials is difficult to audit and rotate. Prefer role-based access, managed secrets, centralized policy, and repeatable controls wherever the platform supports them.

Auditability is a design quality. Centralized logging, consistent identity, change records, and standardized controls make it possible to answer who changed a resource, which policy allowed the action, and what data was affected. A design that cannot produce that evidence may be operationally functional but still unacceptable for regulated or enterprise workloads. Build security reasoning around both prevention and the ability to investigate exceptions.

Reliability is a system property, not a checkbox

High availability requires more than duplicating one component. The entire request path must tolerate the intended failure: networking, compute, data, dependencies, and operational tooling. A multi-zone application can still fail if its database, configuration store, or deployment process has a single point of failure. Review architectures by deliberately removing one component at a time and asking what breaks.

Disaster recovery extends the same reasoning across larger failure domains. Consider recovery point objectives, recovery time objectives, backup replication, infrastructure recreation, DNS or traffic failover, and the order in which dependent systems must return. A professional architect should be able to explain not only the target design but the recovery sequence.

Cost optimization belongs inside the design process

Cloud cost is shaped by architecture. Instance size, storage tier, data transfer, idle capacity, database configuration, and scaling policies all contribute. The cheapest individual service choice can be expensive at system level if it creates operational work, poor performance, or avoidable transfer. Professional candidates should compare cost with reliability and performance instead of optimizing one metric in isolation.

Use monitoring data to validate assumptions. Rightsizing, lifecycle policies, scheduled capacity changes, and architectural simplification can all reduce cost when they are based on real usage. An architect should also recognize when higher spending is justified—for example, when redundancy materially reduces outage risk for a critical workload.

FinOps-style thinking is useful even when the exam does not use that label. Tagging and account structure can make spending attributable, budgets and alerts can expose drift, and architectural reviews can identify expensive data-transfer paths or idle resources. Cost controls are most effective when they are part of deployment and governance instead of an occasional cleanup exercise. A professional architect should know which costs are structural, which are usage-driven, and which can be reduced safely without weakening the service objective.

Build the modern path from associate foundations to professional judgment

Candidates rebuilding from the retired ACP-Cloud1 curriculum may benefit from reviewing the current associate role first. CEA-C01 Cloud Engineer (Associate) focuses on creating, configuring, and managing cloud resources, while the professional Cloud Architect role expects those building blocks to be combined into robust solutions. The retired ACA-Cloud1 code can provide historical context, but it should not be treated as the live prerequisite.

Use hands-on work to connect the levels. Build a small application, make it highly available, secure it, monitor it, document its recovery process, then revisit the design with growth and cost constraints. That exercise exposes the same cross-service tradeoffs a current professional-level architect must reason about and is far more durable than memorizing an obsolete ACP-Cloud1 question bank.