Exoscale Certified Cloud Professional common mistakes
Exoscale Certified Cloud Professional · Understand the traps and how to avoid them.
Treating Exoscale compute instances as if they were stateless ephemeral VMs and assuming local disk survives a stop/start or a live migration, then losing data placed directly on the instance's root volume without attaching and mounting a separate block storage volume.
Candidates carry over habits from hyperscalers where instance store is clearly flagged or where the root disk is a managed network volume. On Exoscale the instance's local disk is tied to the host, and the durable pattern is a separately attached block storage volume; the distinction is easy to gloss over when reading the compute documentation quickly.
What to do instead
Learn the rule explicitly: anything that must persist belongs on an attached block storage volume (or object storage), not on the instance's own disk. In practice questions, whenever a scenario mentions data surviving a stop/start, resize, or migration, answer with an attached volume, and be able to describe the attach and mount steps at a high level.
Choosing the wrong compute instance family for a workload because the candidate maps generic 'general purpose / compute optimized / memory optimized' labels onto Exoscale's actual family names and sizes without checking which families offer local NVMe versus network storage, or which sizes are available in the target zone.
Every cloud uses different family naming, and candidates assume the mapping is obvious. Exoscale's families (standard, CPU-heavy, memory-heavy, GPU, storage-optimized) have specific characteristics, and availability differs by zone and by whether the offering is a standard instance or part of a newer generation. Exam scenarios often hinge on one distinguishing attribute such as local NVMe or GPU.
What to do instead
Build a small comparison table from the official product documentation for each family: intended workload, vCPU-to-memory ratio, whether local NVMe is included, and which zones carry it. When a scenario mentions a database needing high memory per core or an analytics job needing local scratch disk, match on that attribute rather than on the generic label.
Configuring block storage volumes as if resize and snapshot were interchangeable, or assuming a volume can be shrunk or moved between zones freely. Candidates answer that you can reduce a volume's size, or that a snapshot restores directly into a different zone, without checking.
Storage semantics differ across providers and candidates generalize from one they know. The important Exoscale specifics (grow-only resize, snapshots being zone-scoped, and the need to create a volume from a snapshot in the same zone) are stated in the storage documentation but are easy to skip because they read like boilerplate.
What to do instead
Memorize the constraints as a short list: volumes can be grown but not shrunk; snapshots and volumes are tied to a zone; restoring elsewhere means exporting or copying through object storage or recreating in the target zone. Practice restating the correct recovery procedure end to end for a 'volume lost in zone A' scenario.
Treating Exoscale object storage (SOS) as a full S3 clone and assuming every AWS S3 feature, ACL behaviour, or bucket-policy syntax works identically, or conversely assuming SOS is only reachable from inside the platform.
SOS is S3-compatible, and compatibility is partial: the core API works, but some advanced features, headers, and semantics differ, and the endpoint and credential model are Exoscale-specific. Candidates who have memorized S3 deeply tend to answer from S3 memory rather than from the Exoscale compatibility notes.
What to do instead
Study the published S3 compatibility matrix and note explicitly which operations are supported and which are not. Remember that SOS is reachable over the public internet with Exoscale API credentials scoped by IAM keys, and that bucket naming and region/zone concepts follow Exoscale's model. For scenario questions, verify the specific operation against the matrix rather than assuming S3 parity.
Assuming a managed DBaaS service is a drop-in replacement for a self-managed database and that the candidate retains superuser access, control over the parameter file, or the ability to install arbitrary extensions. Candidates then pick a DBaaS plan for a workload that needs a custom extension or replication topology the service does not expose.
Managed database services deliberately restrict administrative surface, and the exact restrictions differ by engine and by provider. Candidates who know PostgreSQL or MySQL well assume their usual administrative toolkit carries over, and they under-read the service's limitations section.
What to do instead
For each managed engine offered (PostgreSQL, MySQL, Kafka, OpenSearch, Redis, and others as offered), list what the provider manages versus what the customer controls: which extensions are permitted, whether superuser is available, how backups and point-in-time recovery work, and which replication or clustering options exist. Then answer scenario questions by matching the workload's hard requirements against that list.
Designing a private network with overlapping CIDRs across zones or across peered networks, or assuming that a private network automatically routes to the internet. Candidates then propose a design where instances in a private network can reach the internet without a gateway or NAT, or where two private networks with the same CIDR can be peered.
Private networking in Exoscale is zone-scoped and behaves like a layer-2 segment; routing to the internet requires explicit egress configuration, and peering requires non-overlapping address space. Candidates who conflate 'private network' with 'VPC with implicit NAT' from another provider produce designs that cannot work.
What to do instead
Draw the topology explicitly: private network per zone, instances attached, and the egress path named (whether via a public IP on the instance, a managed gateway, or another mechanism the platform offers). State the non-overlap rule for peering as a design constraint, and rehearse a 'two teams, same 10.0.0.0/8' scenario and how you would renumber or use a different scheme.
Explaining load balancing and security group behaviour by analogy to another provider rather than by Exoscale's actual model, for example assuming security groups are stateful in a particular way, that a load balancer terminates TLS by default, or that health checks probe the instance's public interface.
Networking and security primitives look similar across clouds but differ in statefulness, default rules, and where health checks originate. Because the names are familiar, candidates answer from memory of a different product and never check the Exoscale documentation on security group defaults and load balancer health check source addresses.
What to do instead
Write down, from the official docs, the default security group rules, whether they are stateful, how rules are attached to instances, and how load balancer health checks source their traffic so the backend security group must allow them. Then walk through a concrete 'load balancer shows backends unhealthy' troubleshooting sequence using those facts.
Treating IAM as a single global admin key and ignoring the distinction between the account-level API key and scoped IAM keys with policies. Candidates answer that any API key can do anything, or that a leaked key can only be revoked by deleting the whole account's access.
The API key model is the part of the platform candidates touch first (CLI setup) and therefore stop reading about. The existence of IAM roles, key scoping, and policy-based restriction is documented separately, so candidates who learned the CLI from a quickstart never encounter it.
What to do instead
Learn the key hierarchy: the initial account key, how IAM keys are created and scoped, and how policies restrict actions and resources. Be able to describe a least-privilege setup for a CI pipeline (a scoped key limited to the needed API operations on the needed resources) and the revocation procedure for a leaked key, distinguishing key revocation from account-level changes.
Answering data residency questions by pointing at the country of the company's headquarters or at the location of the control plane, rather than at the zone where the data actually resides, and failing to account for which services are zone-scoped versus global.
Residency is the domain where candidates most often reason from marketing language ('Swiss cloud') instead of architecture. The concrete facts that matter, that zones are in specific countries and that storage and database resources are created in a chosen zone, get blurred with broader claims about the provider.
What to do instead
Anchor every residency answer in the zone: name the zone, name its country, and state which resources are created there. Note explicitly that some control-plane or account-level functions are not data-bearing, and that a design spanning zones spans jurisdictions. Practice a scenario where a customer requires data to stay in one country and identify every resource that must be pinned to a zone in that country.
Treating the Concrete AI domain as generic AI theory and answering with model architecture or training concepts instead of the platform's concrete offerings, such as which managed AI services exist, what they run, and how they are consumed through the API.
The domain name invites abstraction, and candidates who are strong on machine learning answer from ML knowledge. The exam instead tests concrete platform capabilities: managed inference or model services, GPU instance families, and how those integrate with the rest of the platform's networking and storage.
What to do instead
Study the concrete AI product pages and note for each: what the service does, which models or frameworks it exposes, how it is reached (API endpoint, private network), what it stores, and which instance families back it. Answer scenario questions by naming the specific Exoscale service and its integration points rather than describing model internals.