For those who have never heard of Open Policy Agent — which, to be fair, still includes a fairly large chunk of the engineering world — the simplest way to think about it is this: OPA is a policy engine.

Now, “policy engine” may sound like one of those terms that appears in architecture diagrams and disappears before anyone explains it properly, so let’s simplify it.

At its core, a policy engine is something to which you provide:

• a set of rules that define what is allowed and what is not allowed
• some contextual information about the current situation
• and then a question asking whether a certain action should be permitted

The engine evaluates all of that and returns an answer.

In plain language, you are essentially saying:

Here are my rules.
Here is the context.
Now tell me whether this action should be allowed.

A very simple real-world example would be this:

Suppose we define a rule that says:

Anyone with the role Admin is allowed to CREATE something.

Now we provide some context:

Alice has the role Admin.

And finally we ask:

Is Alice allowed to CREATE?

A policy engine takes these three pieces, evaluates them together, and gives you the answer.

If we map that into OPA terminology, it looks like this:

• Policy → Anyone with role Admin is allowed to CREATE
• Data → Alice has role Admin
• Input → Is Alice allowed to CREATE?

And that is really the first mental model to build before going deeper into OPA: OPA itself does not hardcode your business decisions — it simply evaluates the rules you give it against the context you provide.

That separation is what makes it powerful.

Enough theory — let’s see OPA in action

Theory is useful, but policy engines become much easier to understand once you actually see one running.

For this demo, we will run Open Policy Agent inside a Docker container using a docker-compose.yaml setup, just to keep things simple and reproducible.

If you want to follow along, the full demo code is available here: https://github.com/purnima-jain/opa-access-control-rest-api

The setup is intentionally lightweight — bring everything up with:

docker-compose up

Once the container is up, it is always a good idea to verify that OPA is actually alive and healthy before doing anything else.

You can jump into the container and check the installed version using:

docker exec -it opa_container opa version

If everything is wired correctly, you should see version details printed back, which confirms that OPA is running properly inside the container.

And now that our policy engine is sitting there quietly waiting for instructions, we can finally make it do something useful.

For this demo, instead of inventing policies from scratch, we will borrow one of the well-known examples from the Rego Playground — specifically the Role-Based Access Control (RBAC) example available in the official playground.

Injecting our first policy into OPA

Now that Open Policy Agent is up and running, the first real thing we need to do is give it a policy to evaluate.

OPA does not magically know your rules — you have to explicitly load them into the engine.

For this demo, we will take the policy available in the Rego Playground (RBAC example) policy panel and push it into OPA using its REST API.

And yes, for quick experimentation, Postman makes this extremely convenient.

We will send a PUT request to:

http://localhost:8181/v1/policies/example1

Using:

• HTTP Method → PUT
• Body Type → raw
• Format → Text

Then simply copy the policy content from the left-hand Policy panel of the Rego Playground and paste it into the request body.

A small but important detail here: the name at the end of the URL — in this case example1 — becomes the policy identifier inside OPA.

So effectively, with this request, we are telling OPA:

Here is a policy. Store it under the name example1.

Once the request succeeds, OPA compiles and stores that policy immediately, and it becomes available for evaluation.

This is one of the nice things about OPA during development: you can inject, replace, and iterate on policies very quickly without restarting anything.

Reading back the policy (because trust, but verify)

Once we push a policy into Open Policy Agent, it is always worth checking whether OPA actually accepted it the way we expected.

A successful PUT response is reassuring, but I still prefer verifying what is sitting inside the engine before moving further.

OPA gives us another REST endpoint for exactly that.

Send a GET request to:

http://localhost:8181/v1/policies

Using:

• HTTP Method → GET

This returns the list of policies currently loaded into OPA.

If everything worked correctly, you should see the policy we inserted earlier — example1 — along with its stored source content.

And now that the policy is safely inside OPA, the next obvious question is:

A policy alone is just a rule. Where does OPA get the actual contextual information from?

That is where data injection comes in.

Injecting data: giving OPA some context

At this point, our policy is loaded, but on its own it still cannot answer anything meaningful.

Why? Because a policy defines only the rule — not the real-world context in which that rule has to be evaluated.

And that contextual information is what Open Policy Agent calls data.

Think of it this way:

• the policy says what should be allowed
• the data tells OPA what currently exists in the system

So next, we need to push some data into OPA as well.

For that, send a PUT request to:

http://localhost:8181/v1/data

Using:

• HTTP Method → PUT
• Body Type → raw
• Format → JSON

Then copy the contents from the Data panel in the Rego Playground and paste it into the request body.

Without data, OPA has rules but nothing to apply them to.

With data loaded, the engine now has both:

• the rulebook
• the supporting facts

Reading back the data

Just like with policies, it is a good habit to verify that the data actually landed inside Open Policy Agent exactly the way we intended.

To read the currently stored data, send a GET request to:

http://localhost:8181/v1/data

Using:

• HTTP Method → GET

OPA will return the full data document currently available inside the engine.

At this point, OPA now has both major ingredients loaded:

• Policy → the rules
• Data → the contextual facts

And that means we are finally very close to asking the most interesting part:

Given this policy and this data, is a particular action allowed?

That final piece is where input comes in.

Asking OPA the actual question

Now comes the part where everything finally connects.

We already loaded:

• the policy (the rules)
• the data (the supporting context)

The only missing piece is the actual request we want OPA to evaluate.

In OPA terminology, this is called input.

This is the dynamic part — the thing that changes from one authorization request to another.

For example: Is Alice allowed to create?

For our demo, send a POST request to:

http://localhost:8181/v1/data/app/rbac

Using:

• HTTP Method → POST
• Body Type → raw
• Format → JSON

Now copy the contents of the Input panel from the Rego Playground, but there is one important adjustment:

Wrap that JSON inside an attribute called input.

So instead of sending plain JSON directly, the body should look like:

{
  "input": {
    ...
  }
}

That wrapper matters because OPA expects runtime input under the input key during evaluation.

One detail that is easy to miss here — and worth paying close attention to — is the URL path:

/v1/data/app/rbac

This path is derived directly from the package name inside your policy.

If your policy contains:

package app.rbac

Then OPA converts that package path into:

/app/rbac

In other words:

• dots (.) become slashes (/)
• the package path becomes part of the API endpoint

This is one of those small OPA conventions that makes complete sense once you notice it, but can be confusing the first time you hit it.

And once you send the request, the response returned by OPA should match exactly what you see in the Output panel of the Rego Playground.

That is your final evaluated decision.

Updating data: changing the decision without touching the policy

This is where Open Policy Agent starts showing why separating policy from data is actually powerful.

So far, our policy says who is allowed to do what, and our data tells OPA who currently has which role.

Now let’s change just the data and watch the decision change immediately — without touching the policy at all.

Suppose we want to revoke Alice’s admin access and assign her a different role, say non-admin.

For that, send a PUT request to:

http://localhost:8181/v1/data/user_roles/alice

Using:

• HTTP Method → PUT

And the request body:

[
  "non-admin"
]

What we are doing here is updating only Alice’s role assignment inside the data store.

The policy itself remains exactly the same.

That means the rule still says:

Admins are allowed.

But the supporting fact has changed:

Alice is no longer an admin.

A nice follow-up step is to read the data again using the same GET /v1/data endpoint we used earlier, just to confirm that Alice’s role has actually been updated.

And once that looks correct, run the exact same query again — the same input, the same policy path, everything unchanged.

This time, the output changes.

And no surprises there: Alice is no longer allowed.

That moment is actually one of the clearest demonstrations of OPA’s design philosophy:

• policy stays stable
• data changes frequently
• decisions adapt automatically

In real systems, this becomes incredibly useful because role changes, permissions, entitlements, and user context change all the time, while the authorization logic often remains structurally consistent.

Instead of rewriting application code every time something changes, you simply update the underlying data and let OPA re-compute the decision.

That separation is where a lot of operational elegance comes from.

Wrapping up

Before closing, one important clarification: this is obviously not how Open Policy Agent would typically be integrated in a real production system.

In the real world, policies are not pushed ad hoc through REST APIs every time. They usually live as .rego files in version control, go through the normal engineering lifecycle of review and approval, and are deployed into OPA in a controlled way — very often through a CI/CD pipeline. Likewise, application data would continue to live in your database or source systems; you would not simply dump everything into the OPA engine.

The intent of this write-up was much simpler: to understand OPA in isolation, at a conceptual level, without immediately getting pulled into programming languages, microservice frameworks, application servers, databases, caches, or remote calls to other systems. Sometimes it helps to look at a tool without the surrounding ecosystem first.

And for that purpose, this small hands-on flow gives a pretty good first feel for how OPA works. Once you see policy, data, and input flowing separately, the overall model becomes much easier to appreciate. What makes it interesting is how changing just the data can immediately change the decision without touching the policy itself — and that is exactly where its real strength starts to show in larger systems. For anyone curious about externalizing authorization logic and keeping access control cleaner, OPA is definitely worth exploring further.

Now, if I’m being completely honest, one of the biggest reasons for the delay was good old-fashioned laziness (no surprises there 😄). But right behind that was something a little more intimidating — my lack of familiarity with the Linux ecosystem.

I’ve never been particularly comfortable around Linux, Bash, Shell scripting, Vim, or any of those mystical tools that seem to be second nature to hardcore Linux folks. So, naturally, the CKAD exam felt like a distant dream — a mountain too steep to climb.

But here’s the twist: I did climb it.

And that’s exactly why I’m writing this blog — to share my experience and to tell anyone who’s hesitant because they’re “not a Linux person” that you absolutely can do it too. If I managed to get through it, trust me, so can you.

So, without further ado (and before I talk myself out of writing this post altogether 😅), let’s get into what I learned, how I prepared, and what you should know if you’re even thinking about attempting CKAD — now or in the future.

Things to Know Before Attempting CKAD

#1. Certification Path

Kubernetes certifications generally follow two paths — the administrator track (CKA), which focuses on cluster management, and the developer track (CKAD), which centers on application deployment. If you’re just starting out, the KCNA (Kubernetes and Cloud Native Associate) is a good entry point, covering the basics before moving on to CKA, CKAD, or the advanced CKS (Certified Kubernetes Security Specialist). And for the truly ambitious — earning all five Kubernetes certifications grants you the title of Kubestronaut. Pretty cool, right?

#2. It’s a hands-on exam, not multiple choice.

Unlike most certifications out there, CKAD isn’t about selecting the right answer from a list. It’s entirely practical — you’re given access to a live Kubernetes cluster and expected to work directly on it. You’ll troubleshoot and debug existing YAML files and often create new ones from scratch. The good news? It’s an open-book exam. You’re free to access the official Kubernetes documentation, blogs, and even Helm docs during the test.

#3. kubectl is your best friend.

During the exam, you won’t have access to any Kubernetes dashboards or fancy UIs — it’s just you and the command line. The test heavily rewards the imperative approach, which is quite the opposite of the declarative style we usually prefer in real-world projects. It might not feel fair, but then again, when has life ever promised fairness? The key is to make kubectl commands second nature, especially the ones that can generate YAMLs instantly. They save precious minutes — and in this exam, time is your most valuable resource.

#4. Know your tools.

You don’t need to be a command-line wizard, but a decent level of comfort with basic Linux commands (wget, curl, ps, cd, ls, etc.), shell scripting, Docker, and YAML goes a long way. And then there’s Vim — yes, the legendary text editor that refuses to let you leave. The old joke still stands: “I’ve been using Vim for two years now… mostly because I can’t figure out how to exit it.”

#5. Get comfortable with the Kubernetes documentation.

Spend some time exploring the official docs before the exam — know where things are, what examples exist, and which snippets are worth reusing. Have a rough plan for how you’ll adapt them to your specific tasks. For example, PersistentVolumes and PersistentVolumeClaims almost always show up, and there’s little value in typing those YAMLs from scratch. Instead, know exactly which snippet you’ll copy and use as a starting template.

One small practical tip — when you copy from the documentation, the indentation often ends up messy. Don’t spend precious minutes trying to make the YAML look pretty. Nobody is grading formatting, and there are no brownie points for perfectly aligned spaces. The solutions are machine-validated; readability is for humans, correctness is for the cluster.

That said, treat the docs as a backup, not your primary tool. Copying and tweaking YAML snippets can quietly eat up valuable minutes, so whenever possible, rely on commands instead. Efficiency matters when the clock is running.

#6. Understand the exam format and plan your time.

The CKAD exam runs for two hours and typically includes 16–19 tasks. You’ll need 66% score to pass, and yes — partial credit is awarded for answers that are partially correct. The weight of each question isn’t disclosed, and the difficulty level varies quite a bit — some are quick wins, others can be real time sinks. The best approach? Do an initial sweep — tackle the easier questions first, and tag the tougher ones to revisit later. It’s a simple strategy, but it can make a big difference when the clock starts to feel uncomfortably fast.

A small word of caution: the individual tasks themselves aren’t as intimidating as they may seem. The real challenge isn’t complexity — it’s volume. There are quite a few questions packed into a short window, and time disappears faster than you expect.

#7. The exam setup — and a few words about PSI Secure Browser.

You can take the CKAD exam from home, proctored online through your webcam. You’ll need a reliable internet connection, a valid photo ID, and your laptop’s built-in microphone (headphones aren’t allowed). Before starting, you’ll sign a Non-Disclosure Agreement stating you won’t share exam questions afterward.

Now, about the exam platform — it runs on PSI Secure Browser, and let’s just say it’s not exactly the highlight of the experience. It can be slow, laggy, and occasionally uncooperative (in my case, copy-paste stopped working mid-exam). If you encounter major issues and can’t continue meaningfully, don’t panic — you can discontinue the test and request a reschedule. It’s a fairly common occurrence, and the support team is usually accommodating once you report the issue.

#8. After the exam — what to expect.

Results usually arrive within 48 hours of completing the exam, straight to your inbox. The certificate simply shows a Pass or Fail — no scores or breakdowns. If you pass, you’ll also receive an email from Credly to claim and display your shiny new badge. And if things don’t go your way the first time, don’t worry — your registration includes one free retake, which you can use within the next 12 months.

Resources

Here are the resources that helped me survive (and eventually pass) the CKAD — consider this my shortlist of trusted companions:

• Kubernetes Certified Application Developer (CKAD) with Tests by Mumshad Mannambeth of KodeKloud Training

https://www.udemy.com/course/certified-kubernetes-application-developer/

• Certified Kubernetes Application Developer (CKAD), 4th Edition by Sander Van Vugt

https://www.oreilly.com/videos/certified-kubernetes-application/9780135349700/

• Certified Kubernetes Application Developer (CKAD) Prep Course by Benjamin Muschko

https://www.oreilly.com/videos/certified-kubernetes-application/0642572045296/

• Certified Kubernetes Application Developer (CKAD) Study Guide, 2nd Edition by Benjamin Muschko

https://learning.oreilly.com/library/view/certified-kubernetes-application/9781098152857/

Price

The certification currently costs $445 on the Linux Foundation website — but there’s almost never a reason to pay full price. You can usually find discounts floating around. For instance, Benjamin Muschko’s CKAD course on O’Reilly often includes a 20% discount code, while Mumshad Mannambeth’s KodeKloud course on Udemy typically offers around 30% off. And if you’re patient, the CNCF or Linux Foundation themselves occasionally run promotions where 40% discounts aren’t uncommon. A little timing can save you a fair bit of money.

Final Thoughts

Practice like your life depends on it.

If there’s one thing that truly determines whether you pass or fail the CKAD, it’s not just your Kubernetes knowledge — it’s your time management. This exam is as much about how you perform under pressure as it is about what you know. You’re juggling multiple clusters, YAML files, commands, and a ticking clock — and it’s easy to lose precious minutes on small mistakes.

So, practice until you’re comfortable enough that working in the terminal feels second nature. Simulate the exam environment, build speed, and learn to move past the tricky questions without panicking. Passing the CKAD isn’t only about Kubernetes mastery — it’s about staying composed, managing your time, and sometimes just hoping the tech gods are on your side when the PSI browser decides to misbehave.

If you can balance all that — the concepts, the commands, and the chaos — you’ll walk away with not just a certification, but a real sense of accomplishment.