IBM Cloud Technical Advocate common mistakes
IBM Cloud Technical Advocate · Understand the traps and how to avoid them.
Compares on-premises and cloud options using monthly list price only - multiplies the hourly rate by 730, calls it a three-year cost, and then declares a winner on that single number.
Vendor pricing pages and quick mental arithmetic reward the simplest possible comparison. Candidates drop the line items that actually move total cost of ownership: one-time migration and refactoring effort, retraining staff, support-tier uplift charged as a percentage of monthly spend, egress and cross-zone traffic, idle or over-provisioned capacity, and the on-premises costs that genuinely disappear (hardware refresh, data-centre space, power, maintenance contracts).
What to do instead
Write a three-year TCO grid before looking at the answer options: cash cost on both sides, one-time migration, run-rate split into compute, storage, network egress and support, labour in FTE-months, and decommission savings. Then state the business reason cloud wins or loses for this specific scenario - cloud converts capital expense to operating expense and buys elasticity, agility and faster provisioning; it does not automatically reduce cost, and a lift-and-shift of steady-state workloads frequently costs more.
Uses high availability, disaster recovery, scalability and elasticity interchangeably - for example answering that spreading a workload across three availability zones in one region protects it from a regional outage.
The four terms are used loosely in marketing collateral and each describes a different design property with a different mechanism, cost and failure domain. Zone redundancy addresses component and zone failure; regional or multi-region deployment addresses regional failure with defined recovery objectives; scalability means planned capacity headroom; elasticity means automatic matching of capacity to demand. Candidates hear 'resilient' and pick whichever option sounds most redundant.
What to do instead
Before answering, map each term to three things: mechanism, failure domain survived, and recovery objective. Multi-zone deployment buys high availability inside one region with a low RTO but no protection from a regional failure. Cross-region backup and restore, or an active second region, is disaster recovery and must come with stated RTO and RPO. Scale up and scale out are planned capacity; auto-scaling is elasticity. Read the scenario for the failure it actually names, then pick the mechanism that survives exactly that.
Designs a VPC answer in classic infrastructure vocabulary - adding a gateway appliance to give subnets outbound internet access, putting one VPC subnet in two availability zones, or assuming VLANs and security groups perform the same function.
IBM Cloud runs two generations of infrastructure side by side. Classic infrastructure is VLAN- and device-centric, with gateway appliances, hardware firewalls and its own permission model. VPC is a regional construct with zone-bound subnets, stateful security groups, stateless network ACLs, public gateways and floating IPs, all governed by IAM. Candidates who learned either model first keep reaching for its idioms, and mixed designs cannot actually be built.
What to do instead
Hold two mental models and name the one the question is about. Memorise the VPC rules: the VPC is regional; each subnet sits in exactly one zone; you need one public gateway per zone for outbound internet; security groups are stateful and attach to network interfaces; ACLs are stateless and attach to subnets; cross-VPC and on-premises connectivity goes through Transit Gateway or a direct link, not improvised appliances. If an option mentions VLANs or a gateway appliance, check that the scenario is classic infrastructure before choosing it.
Defaults to Kubernetes - recommending managed Kubernetes or OpenShift for every workload, including a nightly batch job, a single stateless API with sporadic traffic, or a straight lift-and-shift of a legacy application.
Kubernetes is the loudest option in the room, and candidates equate 'modern' with 'containers on a cluster'. That ignores the operational burden of running a cluster, paying for worker nodes that sit idle between jobs, and the fact that serverless containers or plain virtual server instances fit many workloads better and more cheaply. The question often states the traffic pattern and the team's size, and those details are the whole answer.
What to do instead
Run a short decision tree instead of pattern-matching: unpredictable, short-lived or event-driven HTTP and batch work goes to a serverless container and functions platform; lift-and-shift, custom operating systems and licence portability go to virtual server instances; sustained high I/O, large databases or core-tied licensing go to bare metal; many interdependent services that need scheduling, service discovery and portability across clouds justify a managed Kubernetes or OpenShift cluster. Say explicitly why the rejected options lose for this workload.
Chooses a storage service or tier on price per gigabyte alone - placing a transactional database on a low-IOPS block tier, or archiving data that is actually read every week in the cheapest cold object tier.
Storage questions hide the decisive detail inside the workload description: IOPS, latency, concurrency, access frequency and retention. Candidates compare the headline cost per gigabyte and ignore the tier's IOPS-to-capacity ratio, minimum billed duration, retrieval charges and restore latency. Cold tiers look free until the scenario reveals frequent reads or a short retention window.
What to do instead
Convert the workload into four numbers first - IOPS, latency, access frequency and retention period - then choose. Block storage for databases and boot volumes, sized by the IOPS-per-gigabyte profile rather than capacity alone; file storage when many clients need shared POSIX access; object storage for unstructured data reached over HTTP. Within object storage, match the class to the access pattern and remember that colder classes trade cheaper storage for retrieval cost, longer minimum retention and higher latency. If the scenario mentions frequent reads, the cold class is a trap.
Writes an IAM policy at account scope for a service ID that only needs one resource group, or grants a user IAM platform roles and expects them to manage classic infrastructure devices and VLANs.
IAM looks like ordinary role-based access, but it is really subject plus role plus resource, evaluated deny by default, with several scoping layers: account, resource group, and individual resource instance, plus service-specific roles on top. Classic infrastructure permissions live in a completely separate model, so an IAM policy alone grants no device or VLAN access, and classic rights grant no VPC access. Candidates collapse the layers and over-grant or under-grant without noticing.
What to do instead
Practise the three-part sentence every time: subject (user, service ID, or access group) needs this role on this resource, inside this scope. Reach for an access group when the same policy applies to many identities, a service ID for applications rather than humans, and the narrowest scope that still lets the job be done. When the scenario involves classic infrastructure, state that the corresponding classic permissions must be granted separately - and for fleet-wide access reviews, note that account-level policies should be the exception, justified and documented.
States that because a managed service encrypts data at rest, the provider also owns the customer's data, keys and security duties - or answers that the customer has no security responsibilities once a managed database or AI service is in use.
Encryption on by default reads as 'the provider handles it', and managed services blur the boundary between platform and consumer duties. Candidates miss that the customer still owns identity governance and access review, data classification, key custody in bring-your-own-key or keep-your-own-key arrangements, network policy, and the security and compliance of their own workloads and prompts.
What to do instead
Split the duties explicitly in every security scenario. The provider secures physical facilities, the hypervisor, and the managed service's own platform and patching. The customer secures identities and entitlements, data classification, key control when using customer-managed keys in a key management service, network configuration such as security groups, ACLs and gateways, logging and monitoring, and the compliance posture of what they build on top. Name the key model in play - platform-managed keys versus customer-managed or customer-held keys - because that single phrase usually separates the right option from the near-miss.
Answers a migration question with 'rewrite the monolith as microservices' as the first move, without naming the business driver, the portfolio assessment, or a lower-risk option such as rehosting first and replatforming later.
Modernisation narratives are container-and-microservices stories, so candidates pattern-match to the most advanced option regardless of the risk tolerance, timeline, budget and skills stated in the scenario. They also skip the disposition step - the six Rs of rehost, replatform, refactor, repurchase, retain and retire - which is what the question is usually really testing.
What to do instead
Sequence the answer instead of jumping: inventory and assess the portfolio against business value and technical debt; assign each application a disposition from the six Rs; start with low-risk rehost and replatform moves to build cloud operating experience and a migration factory; use the strangler pattern to peel capabilities off the monolith behind an API facade rather than attempting a big-bang rewrite. Finish by tying the recommendation back to the driver the scenario states - cost, release velocity, resilience, or exiting a data centre.
Treats the AI portfolio as interchangeable - proposing a data lakehouse product to serve foundation models, or asserting that customer prompts and fine-tuning data are used to train the provider's shared foundation models.
The product names in the AI portfolio sound alike and the portfolio changes quickly, so candidates answer from impression rather than function. Data-use assumptions are carried over from consumer AI products, where defaults differ, instead of from enterprise terms of service and contractual data-protection commitments.
What to do instead
Keep a three-line map: model building, tuning and prompt-based inference with foundation models (studio, runtime, governed model catalogue); the data layer that manages and queries open-format data in a lakehouse for training and retrieval; and governance that tracks risk, lifecycle and compliance evidence across models and applications. On data use, state that enterprise terms govern prompts, tuning data and outputs, that customer content is not used to train shared foundation models, and point to the contractual and technical controls behind that rather than asserting it. If you cannot state the control, flag the item for review instead of guessing.
Assumes powering off an instance stops all related charges, and selects a support plan by price alone without knowing what each tier includes.
Compute is the visible line item, so candidates treat it as the whole bill. Attached block and file storage, snapshots, floating and reserved IPs, load balancers and provisioned services keep billing after an instance is stopped. Support is priced as a percentage of monthly consumption rather than a flat fee, so candidates misjudge both its cost and the response-time commitments it buys.
What to do instead
For cost questions, enumerate what survives a shutdown: block, file and object storage and their snapshots, floating and reserved IPs, load balancers, provisioned databases and software licences. For support, know the ladder - a free basic tier included with the account, then paid advanced and premium tiers priced as a percentage of monthly spend, each buying shorter response targets, severity-one coverage and named contacts. Choose the tier from the criticality the scenario states, and use account governance tools - resource groups, budgets and spending notifications, tagging - as the answer to 'how do we prevent this', not as a substitute for understanding the bill.