Forem: Andrew Kalik

cx_Oracle vs setuptools: A Dependency Fight Nobody Wanted

Andrew Kalik — Tue, 10 Feb 2026 16:14:21 +0000

If you've recently tried installing cx_Oracle and it blew up in your face…

Yeah. Same.

And if your first thought was:

Why the hell did this break? It worked fine a few days ago.

Welcome to the wonderful world of dependency drift, Python packaging ecosystem changes, and the uncomfortable reality that “cloud managed” does not mean “someone else will keep your dependencies from rotting.”

This post is part technical breakdown, part cloud PSA, and part friendly warning:

✅ If you're still using cx_Oracle, it’s time to migrate to oracledb.

The Breaking Change Nobody Asked For

For years, Oracle connectivity in Python was basically muscle memory:

pip install cx_Oracle

And it worked.

It worked locally.

It worked in EC2.

It worked in containers.

It worked in Airflow.

It worked in MWAA.

And then suddenly it didn’t.

If you’ve updated your Python build toolchain recently (pip / setuptools / wheel), you may have seen installs fail with errors like:

build failures during pip install
metadata generation errors
compilation failures depending on OS image
dependency resolution errors that feel random
“it worked yesterday” failures after rebuilding an image

And here’s the important part:

This isn’t just a cloud problem anymore.

If your laptop is running a modern Python toolchain, cx_Oracle can fail locally too. So this isn't just some AWS runtime quirk.

This is Python packaging evolution colliding with a legacy dependency.

Why This Happens (And Why It Feels Random)

The Python ecosystem has been steadily moving away from older build behaviors and pushing toward modern standards:

PEP 517 / PEP 518 build isolation
pyproject.toml driven builds
stricter build dependency enforcement
fewer “legacy fallback” behaviors

This is a good thing overall.

But it also means packages that depend on older assumptions can break as pip/setuptools evolve.

cx_Oracle has been around forever, and a lot of codebases still depend on it, but it’s increasingly out of alignment with how Python packaging works today.

MWAA Makes This Worse (Because You Don’t Control the Runtime)

This is where the pain becomes operational instead of just annoying.

In AWS MWAA (Managed Workflows for Apache Airflow), you are not fully in control of the runtime environment forever.

Even if you never click "upgrade", AWS still applies platform patching and refreshes as part of operating a managed service.

So you end up in the worst-case scenario:

✅ your DAGs didn’t change

✅ your requirements.txt didn’t change

❌ your environment breaks anyway

And now your production orchestration system is down because a dependency that used to install cleanly no longer does.

MWAA Maintenance Windows: The Silent Dependency Killer

If you're running MWAA, you’ve probably seen the concept of maintenance windows.

These are the scheduled windows where AWS can apply updates behind the scenes.

During MWAA maintenance windows, AWS may patch or refresh things like:

the underlying base OS image
Python runtime components
pip
setuptools
wheel
OpenSSL and other system libraries

Which is great for security.

But it also means your environment can shift underneath you without you explicitly touching your deployment pipeline.

And that means a MWAA maintenance window can quietly turn into:

Congrats, your production scheduler is now a science experiment.

Because dependency installation behavior changes, and brittle packages fall apart.

This Is the Shared Responsibility Model in Real Life

This is the part people don’t like to hear.

AWS owns securing the MWAA platform.

You own your application dependencies.

That’s the cloud shared responsibility model, whether we like it or not.

AWS will keep patching MWAA. They should. They have to.

But if your workloads depend on fragile dependencies, you’re effectively betting your data platform stability on old packaging assumptions staying frozen in time.

And they won’t.

The Tempting Fix: Pin setuptools (Not Recommended)

One quick fix is to pin setuptools back to an older version:

pip install "setuptools<XX"
pip install cx_Oracle

And yes, this can work.

But this is duct tape.

Now you’re freezing foundational build tooling, which can introduce:

future dependency conflicts
security risk
unpredictable behavior across environments
even more painful breakage later

In a cloud environment, pinning ancient build tooling is basically saying:

Let’s solve this by refusing to update ever again.

That’s not a strategy. That’s denial.

The Real Fix: Stop Using cx_Oracle

Here’s the PSA:

If you’re still using cx_Oracle, migrate to oracledb.

Oracle’s supported modern replacement is:

pip install oracledb

This isn’t just a rename.

It’s the forward path.

Why oracledb Is Better

The oracledb package is:

actively maintained
Oracle’s official successor to cx_Oracle
more compatible with modern Python packaging standards
built to survive modern CI/CD and container workflows
capable of running in both Thin mode and Thick mode

Translation: it behaves better in modern cloud runtimes and managed services.

Migration Is Usually Easier Than You Think

In many codebases, migration is minimal.

Often it’s just:

import cx_Oracle

becoming:

import oracledb

The API is intentionally similar because oracledb was designed as the successor.

Yes, you should test it.
Yes, there are edge cases.

But compared to debugging broken Airflow deployments and chasing packaging failures across ephemeral compute fleets?

This is the easier problem.

If You're Running MWAA + Oracle, This Is a Real Risk

In MWAA, dependencies are installed during environment creation or update.

If your requirements.txt fails to install cleanly, your environment becomes unstable fast:

workers fail to start
schedulers fail
tasks stop running
CloudWatch logs become a wall of stack traces
your “simple DAG deployment” becomes a multi-hour incident

And when the root cause is dependency ecosystem changes, it’s even worse because it feels random.

It’s not random.

It’s just the ecosystem moving forward.

PSA: Do This Before Your Next Maintenance Window

If you’re using Oracle connectivity in Python:

stop building new pipelines on cx_Oracle
migrate existing workloads to oracledb
test the migration before the next MWAA maintenance window forces your hand

Because MWAA is going to keep evolving.

Your codebase needs to keep up.

Final Thought

A lot of outages don’t happen because AWS went down.

They happen because your dependency tree quietly shifted under your feet.

And that’s exactly why patching and upgrades aren’t optional in cloud engineering.

They’re operational survival.

So yeah…

Update your stuff.

Test your stuff.

And stop using cx_Oracle.

Your future self will thank you.

Designing a Cross-Cloud Data Plane with Apache Iceberg

Andrew Kalik — Mon, 26 Jan 2026 19:50:36 +0000

Designing a Cross-Cloud Data Plane with Apache Iceberg

Most organizations don’t deliberately choose to build multi-cloud data platforms.

They arrive there gradually — through acquisitions, organizational boundaries, and the reality that different teams and workloads gravitate toward different platforms. Over time, AWS and GCP both become part of the picture, whether that was the original plan or not.

The challenge isn’t the presence of multiple clouds.

The challenge is what happens to data once they are.

Rather than focusing on specific tools or implementations, this post is meant to share a mental model for reasoning about cross-cloud data platforms — one that prioritizes cost discipline, simplicity, and long-term flexibility.

Why Multi-Cloud Is Often Unavoidable

Multi-cloud is rarely ideological.

It usually emerges from:

Independent teams choosing platforms that fit their needs
Mergers and acquisitions that bring existing cloud footprints
Organizational boundaries that resist forced standardization
Analytics and AI capabilities evolving at different speeds

In practice:

Most organizations are already multi-cloud long before they design for it.

Trying to undo that reality often leads to brittle mandates and slow delivery. A more durable approach is to design around multi-cloud instead of fighting it.

The Real Cost of Multi-Cloud Is Data Duplication

Where most multi-cloud data architectures struggle is not orchestration or tooling — it’s duplication.

The same dataset is often:

Ingested separately into AWS and GCP
Transformed independently in each environment
Stored in different formats
Reprocessed for analytics, applications, and AI

Each duplication multiplies:

Storage cost
Compute cost
Pipeline complexity
Operational risk

At scale, this becomes compounding waste.

Multi-cloud becomes expensive only when data is duplicated.

The alternative is to process data once and reuse it everywhere.

A Three-Plane Model for Cross-Cloud Data Platforms

To make this practical, it helps to step back and use a simple mental model that separates responsibilities into three planes, each with a distinct purpose.

The Data Plane: The Source of Truth

The data plane defines what the data is.

It includes:

How data is stored
How tables are structured
How schemas evolve
How versions and snapshots are managed

This plane should be:

Durable
Engine-agnostic
Slowly changing
Written once and reused many times

Apache Iceberg fits naturally here. It provides a stable, open table contract that works across object storage and compute engines, without binding data to a specific cloud or execution model.

The data plane is not optimized for speed — it is optimized for correctness and reuse.

This is what enables a true single source of truth — not by centralizing platforms, but by standardizing how data is defined and evolved.

The Control Plane: Coordination Without Ownership

The control plane defines when and why work happens.

It includes:

Orchestration
Eventing
Scheduling
Governance hooks
Policy enforcement

Each cloud can have its own control plane. AWS and GCP do not need to share orchestration logic or operational workflows.

The critical constraint is this:

Control planes coordinate access to data, but they do not own it.

This keeps orchestration stateless, replaceable, and cloud-native, while the data plane remains stable.

The Consumption Plane: Execution and Experience

The consumption plane defines how data is used.

It includes:

Analytics and querying
Applications
Feature extraction
Machine learning and AI workloads

This plane is intentionally:

Ephemeral
Cost-variable
Optimized for workload needs
Free to evolve independently

Serverless execution fits naturally here. Compute spins up only when needed, processes a slice of data, and shuts down.

Compute should be temporary. Data should not be.

Apache Iceberg as a Shared Cross-Cloud Data Plane

By using Apache Iceberg as the data plane, AWS and GCP can evolve independently while relying on the same underlying data contract.

Iceberg allows:

Data to be processed once
Schemas to evolve without rewrites
Snapshots to support consistent reads
Multiple consumers across clouds
Object storage to remain the system of record

The clouds don’t need shared pipelines.

They need shared tables.

Single Processing Is the Biggest Cost Reduction Lever

Without a shared data plane:

Each cloud processes the same raw data
Each environment runs its own transformations
Each platform retrains AI models independently
Compute cost scales with the number of clouds

With a shared data plane:

Data is transformed once
Snapshots are reused across consumers
Incremental processing minimizes rework
Serverless compute stays small and targeted

Processing a dataset once and reusing it across analytics, applications, and AI workloads is one of the most effective ways to reduce cost in cross-cloud data platforms.

Every additional cloud, engine, or workload that reuses that same processed dataset benefits from this decision without incurring proportional cost.

This is architectural efficiency, not after-the-fact optimization.

Where AI Fits

AI makes architectural efficiency non-negotiable, because the cost of duplicated data shows up fastest in training, retraining, and experimentation.

AI does not require a separate plane.

It spans all three:

The data plane provides training data and historical snapshots
The control plane governs training and retraining
The consumption plane handles inference and interaction

Training the same data multiple times across clouds is expensive and unnecessary.

A shared data plane reduces that pressure by design.

Tradeoffs and Reality Checks

This approach does not eliminate complexity entirely.

Teams still need to manage:

Catalog consistency
Identity and access boundaries
Feature differences across execution engines
Cross-cloud networking considerations

These are governance and coordination problems — not data duplication problems — and they scale far better than parallel pipelines.

When This Pattern Makes Sense

Strong fit

Organizations operating in AWS and GCP
Shared analytical and AI datasets
Cost-sensitive platforms
Serverless-first execution models

Less ideal

Ultra-low-latency streaming
Workloads tightly coupled to proprietary execution features
Single-cloud environments with no external consumers

Looking Ahead: Cloud Interconnect as the Final Enabler

One of the most exciting developments for cross-cloud data architectures is the continued maturation of private cloud interconnect between AWS and GCP.

Interconnect transforms cross-cloud connectivity from a workaround into a first-class architectural feature. It provides a private, predictable network path that avoids the public internet entirely, improving not just performance, but security and control.

As interconnect becomes more accessible:

Cross-cloud data access becomes more deliberate and auditable
Serverless consumption across clouds becomes more practical
Data no longer needs to be duplicated simply to feel “close” or “safe”

This is where the three-plane model fully comes together. A shared data plane backed by Iceberg, independent control planes per cloud, and ephemeral consumption planes can operate across platforms with confidence.

Instead of copying data defensively, teams can design for access intentionally — reducing cost, tightening security boundaries, and simplifying how data moves between clouds.

It’s one of the clearest signals that cross-cloud data architectures are moving from workaround to first-class design.

Interconnect doesn’t change the need for good architecture.

It rewards it.

Closing Thoughts

Multi-cloud does not require identical architectures.

It requires:

A shared data plane
Independent control planes
Ephemeral, serverless consumption

By treating Apache Iceberg as the data contract, teams can avoid duplicating data, minimize compute cost, and support analytics and AI across AWS and GCP without rebuilding their platform for each cloud.

In practice, the most resilient architectures make the fewest assumptions about where compute runs — and the strongest assumptions about how data is defined.

A Pragmatic, Event-Driven Serverless Data Architecture

Andrew Kalik — Sat, 24 Jan 2026 16:28:43 +0000

MWAA + Glue + Iceberg + Snowflake

Batch data pipelines are often far more expensive and complex than they need to be.

Many teams still operate always-on schedulers, persistent Spark clusters, and long-running infrastructure for workloads that:

Run a few times per day
Complete in minutes
Are triggered by data arrival, not time

This post walks through a pragmatic, event-driven serverless data architecture on AWS that focuses on real cost reduction and operational simplification, not architectural theory.

The Core Problem: Paying for Idle Data Infrastructure

A traditional batch pipeline commonly includes:

Always-running Airflow workers
Persistent EMR or Spark clusters
Cron-based scheduling for event-driven data
Infrastructure sized for peak usage

In practice, this means teams pay for:

Idle CPU and memory
Idle orchestration capacity
Ongoing patching and operational overhead

For many pipelines, most of the cost is spent waiting.

Design Principles

This architecture is built around a few non-negotiable principles:

Event-driven first, schedule only when necessary
Fully serverless wherever possible
Task-level isolation
Pay only when something executes
Open storage formats to avoid lock-in

The system reacts to data. It does not sit idle waiting for a clock.

Architecture Overview

High-level flow:

Data arrives in Amazon S3 or an upstream system
An event (for example, S3 object creation) triggers orchestration
Amazon MWAA (Serverless) coordinates the workflow
AWS Glue (Serverless) executes transformations
Data is written as Apache Iceberg tables in Amazon S3
Tables are registered in the AWS Glue Data Catalog
Snowflake queries the data using external tables

The key shift is reactive execution — pipelines run because data changed, not because time passed.

Event-Driven Orchestration with MWAA Serverless

Airflow is still used, but only for what it does best:

Dependency management
Retry semantics
Visibility and auditability
Coordinating multiple services

With MWAA Serverless:

There are no always-on workers
There is no capacity planning
There is no idle orchestration cost

Events (for example, S3 notifications via EventBridge) trigger DAG runs only when new data arrives. MWAA spins up to coordinate execution and scales back down afterward.

Airflow becomes control flow, not infrastructure.

Glue Serverless as Event-Driven Compute

Each transformation step is implemented as a small, purpose-built Glue job:

One responsibility per job
No shared cluster assumptions
Independent scaling and retries

From a cost perspective:

Jobs run only when triggered
There is no idle cluster time
Failures are isolated and cheap to retry

Instead of paying for a Spark cluster all day, you pay per execution.

Why Apache Iceberg Enables Cost Reduction

Apache Iceberg is foundational to making this architecture efficient.

Iceberg enables:

Schema evolution without rewriting entire tables
Partition evolution without backfills
Snapshot-based time travel for recovery
Multiple engines reading the same data

From a cost perspective:

No duplicate datasets per consumer
No full-table rewrites for small schema changes
No tight coupling between producers and consumers

Iceberg supports incremental, event-driven writes without downstream reprocessing.

Surfacing Data to Snowflake Without Duplication

Snowflake consumes Iceberg tables using external tables backed by Amazon S3 and the Glue Data Catalog.

This approach:

Avoids copying data into Snowflake-managed storage
Makes data available immediately after it is written
Keeps storage costs centralized in S3

If performance requirements change later, data can still be materialized — but duplication becomes a deliberate choice, not a default.

Where the Cost Savings Actually Come From

This architecture removes several major cost drivers.

Traditional Pipeline Costs

24/7 Airflow workers
Always-on Spark or EMR clusters
Idle compute between scheduled runs
Operational effort maintaining infrastructure

Even small clusters add up over time.

Costs Removed by This Architecture

Eliminated

Idle Airflow capacity
Persistent Spark clusters
Long-running EC2 instances
Custom metastore infrastructure

Introduced

Per-event MWAA execution cost
Per-job Glue runtime cost
Object storage costs in S3

In practice, teams often see:

Near-zero idle compute spend
Costs directly proportional to data volume
Predictable per-run pricing

For short-lived batch workloads, this frequently results in meaningful cost reduction without sacrificing capability.

Operational Simplification (The Hidden Savings)

Cost is not just dollars.

This architecture also reduces:

On-call surface area
Patch and upgrade cycles
Capacity planning work
Failure blast radius

Fewer always-on systems means fewer things that can fail silently.

Tradeoffs to Be Aware Of

This pattern does introduce responsibilities:

Event-driven pipelines require idempotent design
Iceberg requires schema and table discipline
External tables may not suit all query patterns

These are engineering tradeoffs, not infrastructure problems.

When This Pattern Works Best

Strong fit

Event-driven or near-real-time batch ingestion
Teams optimizing for cost and simplicity
Lakehouse or multi-engine environments

Less ideal

Ultra-low-latency streaming
Always-on interactive workloads
Extremely large, tightly coupled transformations

Final Thoughts

Serverless data architectures are not about removing structure.

They are about aligning cost and complexity with reality.

By combining MWAA Serverless, Glue Serverless, and Apache Iceberg, teams can build pipelines that:

React to data instead of schedules
Eliminate idle compute
Scale naturally
Remain flexible as requirements evolve

In many cases, the simplest architecture is also the most cost-effective one.

Building a Private Photo Sharing Platform on AWS

Andrew Kalik — Mon, 05 Jan 2026 05:17:31 +0000

In July 2024, my dad had a massive stroke.

In the weeks that followed, my sister, my wife, other family members, and I started going through my dad’s barn. We were not expecting much beyond tools and old boxes. What we found instead was almost 3,000 photos, handwritten letters, family recipes, notes, and other documents. Many of them had been sitting there for more than 15 years.

Some were in decent shape. Others were dusty, faded, warped, or brittle. All of them felt irreplaceable.

At some point, the question stopped being what did we find and became how do we make sure we do not lose this.

This Was Not a Photo App Problem

The emotional part came first. The technical problem came later.

We needed a way to:

Scan a large volume of photos and documents quickly
Clean them up enough to be readable and usable
Avoid passing fragile originals around
Share access privately with family across the United States
Ensure nothing disappeared if a laptop died or a service changed direction

This was not about building a public gallery or a social feed.

It was about preserving family history quietly and predictably.

Why I Did Not Use Facebook Instagram or a Consumer Photo Platform

I did not want this living on Facebook or Instagram.

Not because those platforms cannot store photos, but because I wanted:

Private sharing
No social feeds
No resurfacing or reminders
Clear ownership of the data
Predictable long term access

I also looked at consumer photo services. Most of them technically worked, but they required giving up control in ways that did not feel right for this situation.

I wanted something boring, understandable, and under my control.

Why This Turned Into an AWS Architecture

Eventually this stopped being a where do we upload photos question and became an infrastructure problem.

I deployed a private self hosted photo sharing platform on AWS and later presented it to my local AWS User Group as a real world case study.

The goal was not polish. The goal was durability and access.

Deployment Architecture

The platform runs on a simple AWS setup:

EC2 runs the application
EBS provides primary attached storage
S3 stores original scans and long term artifacts
Elastic Load Balancer handles HTTPS access

Family members access the system over HTTPS. Active data lives on EBS. Originals live in S3.

Nothing exotic.

Why I Chose to Self Host

Self hosting was not about ideology.

I needed:

Control over data
Independent backups
Predictable costs
A UI my family could use

What I Learned

Two things stood out.

Emotional situations change technical priorities
Simple systems are easier to trust and explain

Closing Thoughts

I did not set out to build a platform.

I set out to make sure we did not lose pieces of our family.

The architecture mattered, but the mindset mattered more.

Own the data
Keep the system understandable
Optimize for recovery

Event-Driven Data Pipelines - Real-Time Orchestration on AWS

Andrew Kalik — Sat, 03 Jan 2026 17:26:31 +0000

For a long time, batch pipelines were “good enough.”

Nightly jobs ran. Dashboards updated the next morning. Everyone learned to live with the lag.

But as data volumes grew — and expectations for freshness grew even faster — those tradeoffs stopped being acceptable.

I originally developed this material while preparing a talk for AWS Summit Los Angeles, and later refined it through conversations and feedback at the Portland AWS User Group. This post is the expanded, written version of that work — focused on what actually breaks in real systems, and how event-driven architectures help fix it.

Why Batch Pipelines Start to Break Down

Most teams don’t choose slow pipelines — they inherit them.

Over time, the same failure modes show up again and again:

Slow feedback loops – Nightly batch jobs mean yesterday’s data drives today’s decisions.
Manual orchestration – Scripts and human coordination introduce fragility.
Duplicate or failed runs – No idempotency leads to wasted compute and inconsistent results.
Missed or late events – Downstream teams lose trust when data silently disappears.
Over-provisioned infrastructure – Jobs sized “just in case” drive unnecessary cost.
Limited observability – It’s difficult to answer a basic question: Where is my data right now?

These were the exact pain points that kept coming up in conversations after both talks — and they’re strong signals that schedule-driven pipelines are being pushed past what they were designed to do.

What “Event-Driven” Really Means

At a high level, an event-driven pipeline reacts to something happening:

A file lands in object storage
An API request is received
A message is published to a queue or stream
A record arrives from an upstream system

Instead of polling on a fixed schedule, the pipeline starts the moment the event occurs.

This framing resonated strongly at both AWS Summit LA and the Portland AWS User Group:

Stop asking “when should this run?”

Start asking “what should trigger this?”

That shift alone simplifies architecture decisions and reduces wasted compute.

Event Triggers & Routing: The Backbone

Modern AWS architectures give you multiple ways to capture and route events:

Object storage events
API-driven ingestion
Message queues
Streaming platforms

What matters most is decoupling producers from consumers.

This is where event routing becomes more than just plumbing. A centralized event bus allows you to:

Filter noisy events
Transform payloads
Fan out to multiple consumers
Make data flow explicit and observable

One point I emphasized heavily in the Portland AWS User Group talk is that routing is an architectural boundary. When done well, teams can evolve independently without coordinating deployments or breaking downstream consumers.

Workflow Orchestration Without Schedule Glue

Once an event is routed, something still needs to coordinate the work.

Depending on complexity, orchestration might involve:

Lightweight coordination for simple pipelines
Stateful workflows for multi-step transformations
Long-running or dependency-heavy DAGs
Request-driven data products

Airflow still plays an important role here — not as a time-based scheduler, but as a state coordinator.

This distinction landed particularly well at AWS Summit Los Angeles, where many teams were already using Airflow but struggling to move beyond cron-driven DAGs.

Transforming Data with Serverless ETL

Once data is flowing, transformation is where value is created.

A serverless ETL approach works especially well in event-driven systems because it:

Scales automatically with demand
Eliminates idle infrastructure
Aligns cost with actual work performed
Integrates cleanly with cataloged datasets

Common patterns include:

Micro-batch processing as data lands
Small-file compaction and partition optimization
Deduplication and data quality enforcement
Normalizing raw inputs into analytics-ready formats

These patterns consistently came up in follow-up discussions after both talks, especially from teams trying to reduce operational overhead without sacrificing data freshness.

Resiliency Is Not Optional

In event-driven systems, failures don’t disappear — they become more visible.

That’s a good thing.

Resilient pipelines are built with:

Retries at every execution boundary
Idempotent processing to avoid duplicates
Dead-letter queues for poison messages
Buffering to absorb traffic spikes
Clear failure paths instead of silent drops

This section generated some of the best questions at the Portland AWS User Group, particularly around how to design for failure without over-engineering.

Observability: Knowing Where Your Data Is

If you can’t answer “what’s happening right now?”, the pipeline isn’t finished.

Strong observability means:

End-to-end visibility into pipeline state
Metrics that surface lag and backlog
Clear lineage from source to output
The ability to trace a single event across services

Event-driven architectures make this easier — but only if observability is designed in from the start.

Final Thoughts

This post reflects lessons learned not just from slides, but from real conversations — at AWS Summit Los Angeles, at the Portland AWS User Group, and with teams actively modernizing their data platforms.

Event-driven pipelines aren’t about chasing trends.

They’re about aligning your data systems with how the business actually operates — in real time, not yesterday.

When done well, they are:

Faster
More cost-efficient
More resilient
Easier to reason about at scale

And most importantly: they restore trust in the data.

If you attended either talk — or you’re tackling similar challenges — feel free to connect with me. I’m always happy to dig deeper into specific patterns, tradeoffs, or failure modes.

Relearning How to Learn: Preparing for AWS Certifications with ADHD

Andrew Kalik — Sat, 27 Dec 2025 18:34:04 +0000

For as long as I can remember, I’ve not been a great test taker.

Timed exams, dense wording, and second-guessing myself under pressure have never played to my strengths. Add ADHD and a learning disability on top of that, and standardized tests have always been something I approach with hesitation.

Because of that, I put off AWS certifications for a long time. Not because I didn’t work with AWS, but because I already knew the testing format was something I struggled with.

Eventually, I decided that avoiding it forever wasn’t helping either.

So I studied for — and passed — the AWS Cloud Practitioner exam. Now that I’ve figured out what actually works for me when preparing, I plan to use the same approach as I work toward other cloud certifications.

This post isn’t about exam hacks or speed-running certs. It’s about relearning how I learn — and what actually worked for me.

I Had to Stop Studying the “Right” Way

Most certification prep advice assumes you can sit down for long, structured study sessions and steadily grind through material. That has never worked for me. When I tried to force it, I just procrastinated harder.

The problem wasn’t learning AWS.
The problem was the test itself.

Once I stopped pretending otherwise, my approach changed.

Using Practice Exams Without Spiraling

Practice exams can be rough if you already struggle with testing. A bad score can quickly turn into “this is why I don’t do this.”

So I stopped treating practice exams as pass/fail signals and started using them as feedback:
• Which questions did I misread?
• Where did wording trip me up?
• What concepts was I almost understanding?

That gave me direction without wrecking my confidence.

Understanding Beats Memorization

Memorization has never been reliable for me. Context is.

Instead of trying to memorize services, I focused on:
• What problem a service solves
• When it’s the wrong choice
• What trade-offs it makes

That made it possible to reason through questions instead of freezing when I couldn’t recall a specific detail.

Short Sessions, Hard Stops

I didn’t do marathon study sessions. I did short, focused bursts. Sometimes 20 minutes. Sometimes less.

If my brain checked out, I stopped. Forcing it just made the next session worse.

Progress wasn’t neat or linear, and that had to be okay.

Exam Day Was Still Uncomfortable

I didn’t walk into the Cloud Practitioner exam feeling confident. I walked in nervous and fully expecting to overthink things.

And I still passed.

Not because I suddenly became a good test taker — but because I stopped fighting how my brain works and planned around it instead.

⸻

Why I’m Sharing This

If you’ve been avoiding certifications because you’re bad at tests, have ADHD, or don’t learn well from traditional study methods — you’re not alone.

You’re not broken.
You’re not lazy.
And you’re not imagining how hard this can be.

You don’t need a perfect study plan.
You need one that doesn’t work against you.

Passing one exam doesn’t make everything easy — but it does make the next one feel possible.

And that’s enough to keep going.

What I Actually Used to Study

I didn’t rely on a single resource. I bounced between a few depending on what I needed that day:
• AWS Skill Builder for official context and terminology
• Tutorials Dojo for realistic practice questions and explanations
• QA Academy to reinforce fundamentals and fill in gaps
• Pluralsight when I needed a concept explained differently

I didn’t follow any of them linearly. I treated them as a menu and pulled from whatever helped the concept click.

That flexibility mattered more than the specific platform.