Exercise: Troubleshooting Across Platform Types

Build the mental model

Cloud & Deployment's troubleshooting exercise walked through one linear diagnostic flow: build failure, then runtime, then DNS, then HTTPS, then errors, then database, then API. That flow assumed a single deployment target underneath.

Once you are choosing between a major cloud, a PaaS, and a BaaS, the same starting symptom can point toward completely different first checks, because each platform type hides or exposes a different layer of the stack.

Right instinct, wrong platform

'Check the security group' is the right instinct on a major cloud, but meaningless on a BaaS project with no VPC concept. Conversely, 'check the API key type' is a first-class BaaS diagnostic step that barely applies on a raw virtual machine.

Problem Type	What Differs By Platform Type
Database connection	Major Cloud - you control the network/VPC yourself; PaaS - the platform's connection config and add-on link; BaaS - key type and Row-Level Security.
Environment variable	Major Cloud - where the variable was set and whether a redeploy/restart is needed; PaaS - the platform dashboard's variable list; BaaS - whether it's client-bundle or server-only.
Deployed but errors	Major Cloud - the compute instance's application logs; PaaS - the dashboard's build/runtime logs; BaaS - function/API logs and client SDK keys.

The skill practiced here is recognizing platform type before reaching for a fix, not memorizing a longer flowchart.

text

SAME PROBLEM, DIFFERENT FIRST CHECK
-----------------------------------
App can't connect to the database
                |
   +------------+----------------+
   |                             |
MAJOR CLOUD      PaaS                BaaS
(AWS/GCP/Azure) (Railway/Render) (Supabase/Firebase)
   |                |                |
Check VPC /      Check platform's  Check API key
security group   env vars + confirm  type (anon vs
+ DB connection  DB add-on is       service) + RLS
settings         linked to service  rules blocking it

Connect it to a real scenario

The firstDiagnosticStep function below packages the reasoning above into a lookup table you can actually run. It takes a problemType and a platformType, then returns the recommended first check for that exact combination.

For db-connection and major-cloud it returns a networking and connection-settings check, because the database is a separate managed resource behind its own network rules. The same problem on a baas returns a completely different answer about API key type and Row-Level Security, because there is no network layer to inspect at all.

For the environment-variable case, a PaaS check starts with the dashboard's variable list, while a BaaS check starts with whether the variable belongs to the client bundle or the server side, since BaaS projects mix both freely.

What the function doesn't do

The function never claims to fix the problem. It only points you toward the fastest first check for the platform type in front of you - which is the actual skill being practiced.

The same symptom (can't connect to DB, env var not applied, deployed but errors) can have a different likely root cause depending on platform type.
Major clouds put networking and IAM in your hands; PaaS abstracts networking but exposes env vars/add-ons; BaaS removes servers entirely so keys and access rules dominate.
Identify the platform type first, then pick the diagnostic entry point that matches it, rather than reusing a fixed checklist everywhere.

Try the working example

javascript

function firstDiagnosticStep(problemType, platformType) {
  const table = {
    "db-connection": {
      "major-cloud": "Check VPC/security group rules and the managed database's connection settings (host, port, SSL mode).",
      "paas": "Check the platform's environment variable / connection string config and confirm the database add-on is linked to the service.",
      "baas": "Check whether you're using the correct API key type (anon/public vs service/secret) and whether Row-Level Security rules are blocking the query."
    },
    "env-var-not-applied": {
      "major-cloud": "Check whether the variable was set in the right place (task definition, launch config, or instance user-data) and whether a redeploy/restart is needed to pick it up.",
      "paas": "Check the platform dashboard's environment variable list for typos and confirm you triggered a redeploy after adding it.",
      "baas": "Check whether the variable belongs to the client bundle (must be prefixed for the framework) or is server-only, since BaaS projects often mix both."
    },
    "deployed-but-errors": {
      "major-cloud": "Check the compute instance's application logs (CloudWatch, Cloud Logging, or equivalent) for a stack trace.",
      "paas": "Check the platform's build and runtime logs in its dashboard for the first error line.",
      "baas": "Check the BaaS dashboard's function/API logs and confirm the client SDK is initialized with the correct project keys."
    }
  };

  const step = table[problemType] && table[problemType][platformType];
  return step || "Unknown combination - check the problem type and platform type spelling.";
}

console.log(firstDiagnosticStep("db-connection", "major-cloud"));
console.log(firstDiagnosticStep("db-connection", "baas"));
console.log(firstDiagnosticStep("env-var-not-applied", "paas"));
console.log(firstDiagnosticStep("deployed-but-errors", "baas"));
console.log(firstDiagnosticStep("db-connection", "azure-vm"));

You should see

Five console.log lines: (1) the major-cloud db-connection check about VPC/security groups and connection settings; (2) the baas db-connection check about API key type and RLS; (3) the paas env-var check about the dashboard's variable list; (4) the baas deployed-but-errors check about function/API logs; (5) since 'azure-vm' isn't a known platformType, the fallback message 'Unknown combination - check the problem type and platform type spelling.'

5-minute try-it

Your team deploys the same app to two places: a Kubernetes cluster on Google Cloud (GKE) and a Railway service. After a deploy, the Railway version returns 500 errors on every request, while the GKE version works fine. Both use the same codebase and are assumed to have the same environment variables set. What is the first diagnostic step you'd take on the Railway side, and why might it differ from what you'd check on GKE? Write down your reasoning before checking either platform's dashboard.

One important caution

Assuming the platform-specific fix that worked on one platform will transfer to another platform type without re-checking what that platform actually exposes.

Jumping to application code changes before confirming which platform-level layer (network, env var scope, key type) is actually causing the symptom.

Supabase Docs: Row Level Security — Cloud Providers & Platforms