IBM Cloud Technical Advocate cheat sheet

Service model decision rule: choose IaaS when the team must control the OS and runtime, PaaS when only application code should be managed, and SaaS when the business process itself is the requirement.

NIST's five essential characteristics are on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service; a hosting model missing these is not cloud.

Shared responsibility: IBM secures the facility, hardware, and hypervisor (security OF the cloud); the customer secures identities, data, configurations, and workloads (security IN the cloud). The split moves with the service model.

Elasticity vs scalability: scalability adds capacity to absorb growth; elasticity adds and removes capacity automatically so cost tracks demand.

TCO comparison: on-premises = hardware + facilities + power + licensing + labor + refresh cost; cloud = consumption charges + migration + ongoing operations. Compare per-transaction unit cost, not headline price.

CapEx to OpEx: cloud converts upfront capital into variable operating spend, so the business case rests on avoided capital, faster time to market, and resilience rather than on lower list price alone.

Resilience is quantified with RTO (time to restore service) and RPO (tolerable data loss); a multi-zone deployment can reach an RTO in minutes where single-site recovery takes days.

Value levers worth quantifying for a client: provisioning cycle time (weeks to minutes), infrastructure utilization rate, cost per hour of unplanned downtime, and developer hours redirected to differentiating work.

Deployment models are public, private, hybrid, and multicloud; hybrid is selected when data residency or latency forces some workloads to stay on-premises while integration remains cloud-native.

Resource hierarchy: IBM Cloud account, then resource group, then service instance or resource. Every IAM-enabled resource belongs to exactly one resource group and lives in one region.

Geography: a region contains zones. Multi-zone regions (MZRs) have three zones with independent power and network; single-zone regions host services that cannot be spread.

VPC compute: Virtual Server Instances (gen2) use profiles such as balanced bx2, compute cx2, and memory mx2 and can be resized; Bare Metal Servers provide single-tenant physical hosts.

Classic infrastructure uses VLANs, subnets, and devices; VPC uses per-zone subnets, security groups, network ACLs, public gateways, and floating IPs. New designs default to VPC.

Container decision rule: IBM Cloud Kubernetes Service for a managed Kubernetes control plane, Red Hat OpenShift on IBM Cloud when OpenShift tooling and cross-cloud portability matter, Code Engine when the workload is event-driven or intermittent and should scale to zero.

IBM Power Virtual Server runs AIX, IBM i, and Linux on Power inside a PowerVS workspace; use it to lift-and-shift Power workloads rather than rewriting them.

IBM Cloud Satellite extends IBM Cloud services into on-premises, edge, or other-cloud locations while the account keeps a single control plane and IAM.

Provisioning paths are the console, the ibmcloud CLI, the REST API, and the IBM Cloud Terraform provider; all IAM-enabled services are listed in the global catalog.

Availability rule: place instances in separate zones of one MZR behind a load balancer; a single-zone deployment has a single-zone failure domain no matter how many instances it runs.

Storage selection: block storage for one server's file system, File Storage (NFS) for shared read/write across servers, Object Storage for large or unstructured data accessed over HTTP API.

VPC block storage profiles are 3, 5, and 10 IOPS/GB plus custom; on fixed tiers IOPS scale with capacity, so choose the profile from the workload's IOPS-per-GB ratio.

Cloud Object Storage resilience options are Cross Region (geographically dispersed), Regional (within an MZR), and Single Data Center; storage classes Standard, Smart Tier, Vault, and Cold Vault trade retrieval cost against latency.

Object Storage is not a shared file system: it has no file locking and overwrites are eventually consistent, so it must not back concurrent writers that expect POSIX semantics.

VPC networking parts: one subnet per zone, security groups (stateful, bound to instances), network ACLs (stateless, bound to subnets), public gateway for outbound-only internet, floating IP for inbound access.

Connectivity rule: site-to-site VPN for fast encrypted links over the internet, Direct Link Dedicated or Connect for predictable private bandwidth, Transit Gateway to route many VPCs and on-premises links through one hub.

Cloud Internet Services provides edge DNS, global CDN, WAF, DDoS protection, and global load balancing in front of a VPC load balancer.

Managed data services include Databases for PostgreSQL, MySQL, MongoDB, Redis, and Elasticsearch/OpenSearch, plus Db2 on Cloud and Db2 Warehouse for relational workloads, Cloudant for JSON documents, Event Streams (Kafka) and MQ for messaging.

Backup is not the same as resilience: multi-zone storage protects against infrastructure failure but not deletion, so use Backup for VPC or IBM Storage Protect for point-in-time recovery.

An IAM policy is subject (user, service ID, access group, trusted profile) plus target (account, resource group, resource, or resource type) plus role. Policies are additive; IBM Cloud IAM has no deny rules.

Platform roles are Viewer, Operator, Editor, and Administrator; service roles are service-specific, for example Reader, Writer, and Manager on Object Storage.

Cloud Foundry org and space roles are separate from IAM and apply only to classic Cloud Foundry resources.

Authentication options: IBMid with MFA for people, App ID for application login via OIDC/OAuth 2.0, API keys for automation, and trusted profiles for federated compute identities.

Encryption: data at rest is encrypted by default with provider-managed keys; customer-managed keys come from Key Protect (multi-tenant, FIPS 140-2 Level 3) or Hyper Protect Crypto Services (single-tenant HSM, Level 4, keep-your-own-key).

Network controls: security groups are stateful allow rules bound to instances; ACLs are stateless allow and deny rules bound to subnets and evaluated in rule-number order; flow logs capture traffic for audit.

Audit and posture: Activity Tracker records account-level API activity, Log Analysis stores and searches logs, and Security and Compliance Center evaluates posture against defined profiles.

Compliance is granted per service and per region, not per provider: check the service's compliance tab in the catalog (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, Financial Services framework) before committing.

Secrets and certificates: Secrets Manager stores credentials and arbitrary secrets, Certificate Manager issues and renews TLS certificates; neither should be replaced by secrets in source control.

Modernization ladder: rehost, replatform, refactor, rearchitect, rebuild, replace. Each step buys more cloud value and costs more change effort, so the choice is made per application, not per estate.

Strangler fig pattern: route traffic through a facade, extract capabilities into new services one at a time, and retire the legacy system only when its last function has moved.

Container platform rule: OpenShift on IBM Cloud when cross-cloud portability and Red Hat tooling matter, IKS for lighter managed Kubernetes, Code Engine for serverless containers and batch jobs.

CI/CD on IBM Cloud: Continuous Delivery toolchains pair Git Repos and Issue Tracking with Tekton pipelines for build, test, scan, and deploy stages.

watsonx is three separate services: watsonx.ai for building with foundation models, watsonx.data for the open lakehouse, and watsonx.governance for AI risk and compliance.

Retrieval-augmented generation: chunk source documents, embed them into a vector store, retrieve top matches at query time, and pass them in the prompt to ground answers and reduce hallucination.

AI governance artifacts: model factsheets, prompt and response logging, drift and fairness monitors, and approval workflows mapped to regulations such as the EU AI Act.

Integration services modernize the seams between systems: API Connect for API lifecycle and gateway, App Connect for connectors, Event Streams for Kafka eventing, and MQ for reliable messaging.

Account types: Lite (free, no time limit, limited services), Pay-As-You-Go, Subscription (committed spend), and Enterprise (account groups under one contract with consolidated billing).

Pricing models: pay-as-you-go hourly or monthly, reserved capacity on one- or three-year terms at a discount, and subscription credit drawdown.

Cost visibility: the Cost and Asset Management service exports usage and cost to a Cloud Object Storage bucket; invoices and usage reports break down by resource group, resource, and tag.

Cost allocation rule: tag every resource at creation (cost_center, owner, environment) and enforce it with provisioning templates; untagged spend cannot be charged back to a business unit.

Budgets set a monthly threshold per account or resource group and send email alerts at percentage marks; budgets warn, they do not stop provisioning.

Governance structure: resource groups isolate environments, access groups hold IAM policies, trusted profiles handle federation, and account settings control MFA and IP address restrictions.

Quotas apply per account, per region, and per resource type, for example vCPU limits for VPC; check them before large deployments and raise them through a support case.

Support plans: Basic (documentation and community, no ticket SLA), Advanced (24x7 technical support with response-time SLAs), Premium (adds a designated Technical Account Manager and proactive guidance).

Cost optimization levers: rightsize profiles from monitoring data, schedule stop/start for non-production, delete unattached floating IPs and orphaned volumes, and apply reserved pricing to steady-state workloads.