Akamai Cloud Computing Foundations common mistakes
Akamai Cloud Computing Foundations · Understand the traps and how to avoid them.
Classifying every Akamai Cloud service as IaaS, for example calling Object Storage or LKE a virtual machine service, when answering model-responsibility questions.
The console presents compute, storage, and Kubernetes together, and product names overlap; candidates memorize service names without mapping who manages the OS, runtime, and data.
What to do instead
For each service, write down the managed boundary: Compute Instances are IaaS (you patch the OS); LKE is managed Kubernetes (you manage workloads and nodes); Object Storage is a managed storage API (you manage buckets and data).
Assuming a plan or service is available in every region and choosing a region only for latency.
Region lists look uniform in the UI, but plan families, GPU or High Memory availability, and data-residency requirements vary; candidates reuse an architecture pattern without checking.
What to do instead
Before finalizing, verify the required plan family and service in the target region. Document latency, residency, and failover implications, and choose a region that supports every dependency.
Attaching a Block Storage volume to one Compute Instance and expecting a second instance to mount the same volume read-write as a shared drive.
Block Storage sounds like a network share and the volume appears as a disk; candidates miss that ordinary block devices are not cluster-aware filesystems.
What to do instead
Treat a Block Storage volume as a single-instance block device: attach, partition, format, and mount it. For shared files, use Object Storage for object access or design an application-level or clustered filesystem with correct fencing.
Comparing Compute Instance plans only by vCPU count and price, then running a sustained database or build server on a Shared CPU plan.
Plan tables emphasize vCPU and RAM; shared versus dedicated CPU and burst behavior are easy to overlook, and test workloads are often short.
What to do instead
Match the workload profile: sustained CPU and steady latency need Dedicated CPU; memory-heavy workloads need High Memory; bursty low-duty workloads can use Shared CPU. Check RAM, disk, and transfer too, and load-test before committing.
Creating a NodeBalancer frontend and assuming traffic will flow without validating backend private IPs, backend ports, and the health-check path and protocol.
Frontend configuration succeeds independently of backend reachability; candidates stop when the NodeBalancer is running.
What to do instead
Verify each backend uses the correct private IP and listening port, configure a health check that actually returns 200 on the right path and port, and test from a client while checking backend health status.
Editing A or CNAME records at the domain registrar and expecting Akamai DNS Manager changes to take effect, or lowering TTL only after a cutover.
Registrar and DNS hosting are separate roles; the UI can show records in both places, and TTL changes need propagation time.
What to do instead
Delegate the domain to Akamai nameservers or confirm which provider is authoritative, make records in the authoritative DNS zone, and lower TTL well before migration. Verify with dig against the authoritative nameserver.
Creating one account-wide API token with read-write access and no expiry for scripts, CI, or a teammate's one-off task.
Broad tokens are faster to create and avoid permission errors; candidates underestimate blast radius and rotation needs.
What to do instead
Use scoped tokens with least privilege, expiry, and separate tokens per workload. Prefer users and grants where appropriate, rotate and revoke tokens, and store them in a secret manager rather than in code.
Enabling a Cloud Firewall and then leaving SSH password authentication, default application credentials, and unnecessary public services exposed.
A firewall rule set feels like complete security; candidates equate network filtering with host and application hardening.
What to do instead
Layer controls: deny inbound by default, allow only required ports and CIDRs, use SSH keys, patch hosts, disable default accounts, and place private services on private networking. Test exposure with an external scan.
Powering off a Compute Instance and assuming it stops billing, while leaving attached Block Storage, backups, NodeBalancers, and reserved IPs in place.
The off state looks like decommissioned, and pricing pages emphasize hourly compute; ancillary charges are separate line items.
What to do instead
Build a decommission checklist: delete instances rather than only powering them off, remove volumes, backups, NodeBalancers, and unneeded IPs, review billing by resource, and use tags to find orphaned resources.
Hardcoding Compute Instance IDs, private IPs, or region names into deployment scripts and Terraform so rebuilds and region changes break.
It works in the first environment and IDs are visible in the UI and API; candidates treat infrastructure as static.
What to do instead
Discover resources via API and tags, use variables and modules, reference provider-assigned attributes, and test a destroy-and-recreate cycle. Keep secrets and environment-specific values out of code.