← Back to Blog

My First Dynatrace Community Challenge (And How Curiosity Helped Me 'Cheat')

My experience completing the Dynatrace Community Beginner Challenge, a lesson in curiosity, Git, and a little bit of reverse engineering.

Published
ByMark N
dynatracechallengecommunitykubernetesgitdevops

Today I discovered something I somehow hadn’t noticed before: the Dynatrace Community hosts hands-on learning challenges.

As someone who’s currently diving deeper into Dynatrace and observability, it sounded like the perfect way to learn something new while having a bit of fun.

I decided to start with the Beginner Challenge: The Twelve Tables – Lex Imperfecta.

You can find the challenge here:

https://community.dynatrace.com/t5/Challenges/Take-the-Lex-Imperfecta-Challenge-The-Twelve-Tables-Beginner/ba-p/301932

What surprised me most was how well the challenge is designed. Although it revolves around Kubernetes policy files, you don’t actually need any Kubernetes experience to complete it. That’s great news for people like me—I don’t have a Kubernetes background either, yet I still managed to finish the challenge.

Getting Started

The challenge offers two ways to get started:

  • Launch the environment in GitHub Codespaces
  • Clone the repository and run it locally

I chose GitHub Codespaces because it was the fastest option. Within a few minutes, everything was up and running.

Before diving in, I carefully read through the challenge description, the rules, and the information posted in the community forum.

Once the Codespace was ready, I noticed that three YAML policy files were already open in the editor. I skimmed through them—not in great detail, just enough to understand what each policy was supposed to represent.

Everything seemed straightforward.

Or at least, it did for a moment.

Then Curiosity Took Over…

If you’ve ever worked with me, you’ll know I have a habit of opening files I probably don’t need to open.

So naturally, my eyes landed on a file called verify.sh.

“I wonder what this does…”

Instead of immediately solving the challenge, I opened the script and started reading it.

Not just reading it.

Reading it very carefully.

A few minutes later, I had one of those moments where you slowly lean back in your chair and think:

“Wait… I think I just reverse-engineered the entire solution.”

Apparently my curiosity had accidentally switched from learning mode to capture-the-flag mode.

Let’s just say the verification script was… rather informative.

Applying the Solution

After understanding how the verification worked, I made the necessary changes to the three policy files.

Time for the moment of truth.

./verify.sh

Success.

Everything passed.

Mission accomplished.

Or so I thought…

The Small Detail I Forgot

I was expecting my completion certificate.

Instead, the verification script politely informed me that I had forgotten one very important step.

I hadn’t committed my changes.

The script basically said:

“Nice try, but I’m not giving you a certificate until you learn to commit your work.”

Fair enough.

A quick git commit later, I ran the verification script again.

This time everything worked exactly as expected, and I proudly shared my completion certificate on the Dynatrace Community forum.

Final Thoughts

I genuinely enjoyed this challenge.

It’s beginner-friendly, well structured, and a fun way to get familiar with Dynatrace while picking up a bit of Kubernetes and Git along the way. Even without prior Kubernetes experience, I never felt lost.

Although I may have unintentionally taken the “reverse engineering” route, I still spent time understanding why the solution worked instead of blindly changing files. In the end, that’s what these challenges are really about: learning.

If you’re starting your own Dynatrace journey, I’d definitely recommend giving this challenge a try.

Just one piece of advice…

Maybe don’t inspect verify.sh as thoroughly as I did.

Unless, of course, your inner curious goblin refuses to listen. 👹

Happy learning! 🚀