The latest articles on DEV Community by Naveen Karasu (@thinkkun). https://dev.to/thinkkun https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F2911102%2Fa69591e1-4e13-492f-a849-6588a8dd2be0.png https://dev.to/thinkkun en Naveen Karasu Tue, 12 May 2026 18:26:18 +0000 https://dev.to/thinkkun/day-960-configuration-management-go-backend-engineering-2978 https://dev.to/thinkkun/day-960-configuration-management-go-backend-engineering-2978 <h1> Day 9/60: Configuration management </h1> <p><em>60 Day Go Backend Engineering Challenge</em></p> <p>Today I focused on making configuration management improve production behavior, not just local developer comfort. The strongest checkpoints were emit logs, config reads, and shutdown signals in a way that tells the real runtime story, make test seams deliberate so handlers and services can be checked without ceremony, and treat observability and operational hygiene as part of the product behavior, not as cleanup.</p> <p>The mistake I wanted to avoid was adding logs and tests that make noise without proving anything important. The day felt better once the service boundary stayed visible and each component had one job.</p> <p>The goal for tomorrow is simple: keep the rule clear enough that the next service still feels related to the same design idea. I also want to keep tracing one request path end to end because it exposes weak assumptions faster than a larger demo.</p> go backend api softwareengineering Naveen Karasu Tue, 12 May 2026 18:26:00 +0000 https://dev.to/thinkkun/day-960-sliding-window-patterns-javascript-dsa-53fp https://dev.to/thinkkun/day-960-sliding-window-patterns-javascript-dsa-53fp <h1> Day 9/60: Sliding window patterns </h1> <p><em>60 Day DSA in JavaScript Challenge</em></p> <p>Today I focused on using a stable invariant so sliding window patterns feels like a process instead of a trick. The strongest checkpoints were name the exact window, prefix, or pointer region each variable owns, reuse prior work instead of recomputing the same range each iteration, and test boundary sizes first because they expose weak invariants quickly.</p> <p>The mistake I wanted to avoid was moving boundaries before stating what region they actually represent. The day felt better once the invariant stayed visible and each update had one job.</p> <p>The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.</p> javascript dsa algorithms codinginterview Naveen Karasu Tue, 12 May 2026 18:25:41 +0000 https://dev.to/thinkkun/day-960-sliding-window-patterns-rust-dsa-49fp https://dev.to/thinkkun/day-960-sliding-window-patterns-rust-dsa-49fp <h1> Day 9/60: Sliding window patterns </h1> <p><em>60 Day Rust DSA Challenge</em></p> <p>Today I focused on using a stable invariant so sliding window patterns feels like a process instead of a trick. The strongest checkpoints were name the exact window, prefix, or pointer region each variable owns, reuse prior work instead of recomputing the same range each iteration, and test boundary sizes first because they expose weak invariants quickly.</p> <p>The mistake I wanted to avoid was moving boundaries before stating what region they actually represent. The day felt better once the invariant stayed visible and each update had one job.</p> <p>The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.</p> rust dsa algorithms codinginterview Naveen Karasu Tue, 12 May 2026 18:25:23 +0000 https://dev.to/thinkkun/day-975-sliding-window-fixed-size-go-dsa-4k3c https://dev.to/thinkkun/day-975-sliding-window-fixed-size-go-dsa-4k3c <h1> Day 9/75: Sliding window - fixed size </h1> <p><em>75 Day DSA in Go Challenge</em></p> <p>Today I focused on using a stable invariant so sliding window - fixed size feels like a process instead of a trick. The strongest checkpoints were name the exact window, prefix, or pointer region each variable owns, reuse prior work instead of recomputing the same range each iteration, and test boundary sizes first because they expose weak invariants quickly.</p> <p>The mistake I wanted to avoid was moving boundaries before stating what region they actually represent. The day felt better once the invariant stayed visible and each update had one job.</p> <p>The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.</p> go dsa algorithms codinginterview Naveen Karasu Tue, 12 May 2026 18:25:05 +0000 https://dev.to/thinkkun/day-975-sliding-window-fixed-size-c-dsa-3onb https://dev.to/thinkkun/day-975-sliding-window-fixed-size-c-dsa-3onb <h1> Day 9/75: Sliding window - fixed size </h1> <p><em>75 Day DSA in C++ Challenge</em></p> <p>Today I focused on using a stable invariant so sliding window - fixed size feels like a process instead of a trick. The strongest checkpoints were name the exact window, prefix, or pointer region each variable owns, reuse prior work instead of recomputing the same range each iteration, and test boundary sizes first because they expose weak invariants quickly.</p> <p>The mistake I wanted to avoid was moving boundaries before stating what region they actually represent. The day felt better once the invariant stayed visible and each update had one job.</p> <p>The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.</p> cpp dsa algorithms codinginterview Naveen Karasu Tue, 12 May 2026 18:24:47 +0000 https://dev.to/thinkkun/day-975-sliding-window-fixed-size-java-dsa-1dbe https://dev.to/thinkkun/day-975-sliding-window-fixed-size-java-dsa-1dbe <h1> Day 9/75: Sliding window - fixed size </h1> <p><em>75 Day DSA in Java Challenge</em></p> <p>Today I focused on using a stable invariant so sliding window - fixed size feels like a process instead of a trick. The strongest checkpoints were name the exact window, prefix, or pointer region each variable owns, reuse prior work instead of recomputing the same range each iteration, and test boundary sizes first because they expose weak invariants quickly.</p> <p>The mistake I wanted to avoid was moving boundaries before stating what region they actually represent. The day felt better once the invariant stayed visible and each update had one job.</p> <p>The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.</p> java dsa algorithms codinginterview Naveen Karasu Tue, 12 May 2026 18:24:29 +0000 https://dev.to/thinkkun/day-975-sliding-window-fixed-size-python-dsa-eb1 https://dev.to/thinkkun/day-975-sliding-window-fixed-size-python-dsa-eb1 <h1> Day 9/75: Sliding window - fixed size </h1> <p><em>75 Day DSA in Python Challenge</em></p> <p>Today I focused on using a stable invariant so sliding window - fixed size feels like a process instead of a trick. The strongest checkpoints were name the exact window, prefix, or pointer region each variable owns, reuse prior work instead of recomputing the same range each iteration, and test boundary sizes first because they expose weak invariants quickly.</p> <p>The mistake I wanted to avoid was moving boundaries before stating what region they actually represent. The day felt better once the invariant stayed visible and each update had one job.</p> <p>The goal for tomorrow is simple: keep the rule clear enough that the next variation still feels related to the same idea. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests. I also want to keep tracing tiny examples because they expose weak assumptions faster than large random tests.</p> python dsa algorithms codinginterview Naveen Karasu Tue, 12 May 2026 18:24:11 +0000 https://dev.to/thinkkun/day-9365-basic-array-operations-dsa-system-design-52ba https://dev.to/thinkkun/day-9365-basic-array-operations-dsa-system-design-52ba <h1> Day 9/365: Basic Array Operations -- DSA &amp; System Design </h1> <p><em>365 Day DSA &amp; System Design Challenge</em></p> <p>Day 9 was about making simple array tasks do real teaching work.</p> <p>What I wanted clear today:</p> <ul> <li>reverse-array problems compare extra-space and in-place thinking cleanly</li> <li>rotation rewards structure over repeated shifting</li> <li>max/min should usually become a clean one-pass scan</li> <li>second-largest trains running-state discipline</li> <li>edge cases show up fast even in simple operations</li> </ul> <p>The biggest shift was realizing that these tasks are not trivial drills. They are a great place to build habits that show up again in much harder problems. That makes them useful practice, not just warm-up material for later topics.</p> <p>That made Day 9 much more useful than a warm-up day. It turned basic operations into a way to practice cleaner algorithm judgment.</p> <p><em>Day 9/365 of the 365 Day DSA &amp; System Design Challenge.</em></p> dsa arrays algorithms interview Naveen Karasu Tue, 12 May 2026 18:23:52 +0000 https://dev.to/thinkkun/day-960-alerting-strategies-production-engineering-2n5h https://dev.to/thinkkun/day-960-alerting-strategies-production-engineering-2n5h <h1> Day 9/60: Alerting Strategies -- Production Engineering </h1> <p><em>60 Day Production Engineering Challenge</em></p> <p>Alert fatigue is the number one reason on-call rotations burn people out. Today I am covering the strategies that cut noise while keeping signal.</p> <h2> Symptom-Based Alerting with PromQL </h2> <p>Page on what users feel, not what servers report internally. Here is a burn rate alert that fires when your error budget is burning at 14.4x the allowed rate:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code># Critical burn rate: will exhaust monthly budget in 1 hour ( sum(rate(http_requests_total{code=~"5.."}[1h])) / sum(rate(http_requests_total[1h])) ) &gt; (14.4 * 0.001) and ( sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) ) &gt; (14.4 * 0.001) </code></pre> </div> <p>The dual window (1h AND 5m) means you only page when the problem has statistical significance AND is actively happening right now.</p> <h2> Alertmanager Inhibition Rules </h2> <p>When a node dies, you do not need fifty alerts for every pod that was on it. Inhibition suppresses the cascade:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight yaml"><code><span class="c1"># alertmanager.yml inhibition config</span> <span class="na">inhibit_rules</span><span class="pi">:</span> <span class="pi">-</span> <span class="na">source_match</span><span class="pi">:</span> <span class="na">severity</span><span class="pi">:</span> <span class="s">critical</span> <span class="na">target_match</span><span class="pi">:</span> <span class="na">severity</span><span class="pi">:</span> <span class="s">warning</span> <span class="na">equal</span><span class="pi">:</span> <span class="pi">[</span><span class="nv">alertname</span><span class="pi">,</span> <span class="nv">cluster</span><span class="pi">]</span> <span class="pi">-</span> <span class="na">source_match</span><span class="pi">:</span> <span class="na">alertname</span><span class="pi">:</span> <span class="s">NodeDown</span> <span class="na">target_match_re</span><span class="pi">:</span> <span class="na">alertname</span><span class="pi">:</span> <span class="s2">"</span><span class="s">Pod.+"</span> <span class="na">equal</span><span class="pi">:</span> <span class="pi">[</span><span class="nv">node</span><span class="pi">]</span> </code></pre> </div> <p>One NodeDown critical alert. Zero PodCrashLoopBackOff warnings until the node recovers.</p> <h2> Catching Silent Failures with absent() </h2> <div class="highlight js-code-highlight"> <pre class="highlight yaml"><code><span class="c1"># Alert when a target stops reporting entirely</span> <span class="pi">-</span> <span class="na">alert</span><span class="pi">:</span> <span class="s">TargetVanished</span> <span class="na">expr</span><span class="pi">:</span> <span class="s">absent(up{job="payment-service"} == 1)</span> <span class="na">for</span><span class="pi">:</span> <span class="s">5m</span> <span class="na">labels</span><span class="pi">:</span> <span class="na">severity</span><span class="pi">:</span> <span class="s">critical</span> <span class="na">annotations</span><span class="pi">:</span> <span class="na">summary</span><span class="pi">:</span> <span class="s2">"</span><span class="s">payment-service</span><span class="nv"> </span><span class="s">target</span><span class="nv"> </span><span class="s">missing</span><span class="nv"> </span><span class="s">from</span><span class="nv"> </span><span class="s">Prometheus"</span> <span class="na">runbook</span><span class="pi">:</span> <span class="s2">"</span><span class="s">https://runbooks.internal/target-vanished"</span> </code></pre> </div> <p>This is the one alert that catches what every other alert misses: the silent failure where metrics just stop arriving.</p> <h2> Key Takeaways </h2> <p>Alert on symptoms. Use burn rates. Configure inhibition. Link runbooks. Test your pipeline.</p> <p><em>Day 9/60 of the 60 Day Production Engineering Challenge</em></p> sre prometheus devops tutorial Naveen Karasu Tue, 12 May 2026 18:23:34 +0000 https://dev.to/thinkkun/day-990-remote-state-management-4kmn https://dev.to/thinkkun/day-990-remote-state-management-4kmn <h1> Day 9/90: Remote state management </h1> <p><em>90 Day Security Infrastructure Challenge</em></p> <p>I am writing this one as if a teammate opened the pull request and asked what actually matters. My answer is that keeping Terraform honest when the state file, provider behavior, and module boundaries are all capable of hiding drift. Good infrastructure content should make the operational boundary visible, not bury it behind screenshots or one happy-path command.</p> <h2> Why Local State Breaks in Teams </h2> <p>The practical reason to spend time on why local state breaks in teams is simple: it is one of the places where infrastructure drift hides behind a clean-looking diff. Keeping terraform honest when the state file, provider behavior, and module boundaries are all capable of hiding drift.</p> <p>The repo earns trust when terraform plan output, remote state configuration, provider aliases, variables, outputs, and CI checks wired into the repo tell the same story as the PR summary. That is how you get to a Terraform workflow where the plan, state backend, and module interfaces explain exactly what the change will touch. If the state file is trusted, it needs ownership, locking, and review discipline. If the module boundary is trusted, it needs readable inputs and outputs.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>terraform <span class="nb">fmt</span> <span class="nt">-check</span> <span class="nt">-recursive</span> terraform init <span class="nt">-backend-config</span><span class="o">=</span><span class="s2">"key=remote_state_management/terraform.tfstate"</span> terraform validate terraform plan <span class="nt">-out</span> remote_state_management.tfplan tfsec <span class="nb">.</span> </code></pre> </div> <h2> Building a Hardened S3 Backend Module </h2> <p>Building a Hardened S3 Backend Module sounds narrow until it fails under pressure. Then you find out whether the infrastructure repo can explain its own behavior. The real work is still keeping Terraform honest when the state file, provider behavior, and module boundaries are all capable of hiding drift.</p> <p>I do not want a magical success message. I want terraform plan output, remote state configuration, provider aliases, variables, outputs, and CI checks wired into the repo, because that evidence is what turns the work into a Terraform workflow where the plan, state backend, and module interfaces explain exactly what the change will touch. If the state file is trusted, it needs ownership, locking, and review discipline. If the module boundary is trusted, it needs readable inputs and outputs.</p> <h2> Migrating Local State </h2> <p>Migrating Local State is where remote state management becomes operational. On a real team, the argument is rarely about syntax. It is about keeping Terraform honest when the state file, provider behavior, and module boundaries are all capable of hiding drift.</p> <p>What I want back from this day is a Terraform workflow where the plan, state backend, and module interfaces explain exactly what the change will touch. That only happens when the change leaves evidence in terraform plan output, remote state configuration, provider aliases, variables, outputs, and CI checks wired into the repo. If the state file is trusted, it needs ownership, locking, and review discipline. If the module boundary is trusted, it needs readable inputs and outputs.</p> <h2> Review posture </h2> <ul> <li>I want the pull request to name the affected environment, the rollback path, and the state or inventory boundary touched by remote state management.</li> <li>The review should show exactly how why local state breaks in teams changes behavior, not just that the file format is valid.</li> <li>If a pipeline gate, policy check, or drift report disagrees with the proposed change, that disagreement belongs in the review thread instead of hidden in logs.</li> </ul> <p>The outcome I care about is a Terraform workflow where the plan, state backend, and module interfaces explain exactly what the change will touch. That is only believable when terraform plan output, remote state configuration, provider aliases, variables, outputs, and CI checks wired into the repo are easy to find and consistent with the explanation in the pull request. If the state file is trusted, it needs ownership, locking, and review discipline. If the module boundary is trusted, it needs readable inputs and outputs.</p> <h2> Why this belongs in a security infrastructure track </h2> <p>IaC, Ansible, policy as code, GitOps, and infrastructure testing all share the same responsibility: make change review safer than console drift. That is why I keep bringing the lesson back to Terraform, IaC boundaries, pipeline evidence, and the operational story behind the diff.</p> terraform ansible devsecops security Naveen Karasu Tue, 12 May 2026 18:23:16 +0000 https://dev.to/thinkkun/burp-suite-advanced-features-intruder-attack-types-explained-5451 https://dev.to/thinkkun/burp-suite-advanced-features-intruder-attack-types-explained-5451 <h1> Burp Intruder Attack Types: When to Use Each One </h1> <p>Day 9 of my pentesting challenge. Intruder's four attack types confuse people, so here is the cheat sheet.</p> <h2> Sniper -- Independent Parameter Testing </h2> <p>One list, multiple positions, tested one at a time. Use for finding which parameter is injectable:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight http"><code><span class="nf">POST</span> <span class="nn">/search</span> <span class="k">HTTP</span><span class="o">/</span><span class="m">1.1</span> <span class="na">Content-Type</span><span class="p">:</span> <span class="s">application/x-www-form-urlencoded</span> query=$$test$$&amp;category=$$all$$&amp;sort=$$date$$ </code></pre> </div> <p>With an XSS payload list, Sniper tests <code>query</code> with all payloads while <code>category</code> and <code>sort</code> stay default, then moves to <code>category</code>, then <code>sort</code>. Three positions, 50 payloads = 150 requests.</p> <h2> Pitchfork -- Paired Credential Testing </h2> <p>Multiple lists in parallel. Position 1 gets list 1, position 2 gets list 2:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>List 1 (emails): alice@corp.com, bob@corp.com List 2 (passwords): Spring2026!, Welcome1 Request 1: alice@corp.com / Spring2026! Request 2: bob@corp.com / Welcome1 </code></pre> </div> <p>Use when you have matched pairs from OSINT or breach data.</p> <h2> Cluster Bomb -- Full Combination </h2> <p>Every value in list 1 x every value in list 2. Expensive but thorough. 100 x 100 = 10,000 requests.</p> <h2> Reading Results </h2> <p>Sort by <strong>response length</strong>, not status code. When testing privilege escalation on admin endpoints:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight http"><code><span class="nf">GET</span> <span class="nn">/admin/$$path$$</span> <span class="k">HTTP</span><span class="o">/</span><span class="m">1.1</span> <span class="na">Cookie</span><span class="p">:</span> <span class="s">session=&lt;regular_user_token&gt;</span> </code></pre> </div> <p>Most responses: 403 at ~90 bytes. A few 200s at 2,000+ bytes? Those admin pages have no server-side role checks. Real bug, found in seconds.</p> security pentesting burpsuite webdev Naveen Karasu Tue, 12 May 2026 18:22:58 +0000 https://dev.to/thinkkun/cloudwatch-metric-filters-for-aws-security-monitoring-12n4 https://dev.to/thinkkun/cloudwatch-metric-filters-for-aws-security-monitoring-12n4 <h2> Day 9: CloudWatch Security Filters </h2> <p>CloudTrail records API calls. CloudWatch makes them actionable. Here's a quick setup for the most critical security detection -- catching someone disabling your security controls:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight hcl"><code><span class="nx">resource</span> <span class="s2">"aws_cloudwatch_log_metric_filter"</span> <span class="s2">"config_tampering"</span> <span class="p">{</span> <span class="nx">name</span> <span class="p">=</span> <span class="s2">"aws-config-changes"</span> <span class="nx">log_group_name</span> <span class="p">=</span> <span class="s2">"/aws/cloudtrail/security"</span> <span class="nx">pattern</span> <span class="p">=</span> <span class="o">&lt;&lt;</span><span class="no">PATTERN</span><span class="sh"> { ($.eventSource = config.amazonaws.com) &amp;&amp; (($.eventName = StopConfigurationRecorder) || ($.eventName = DeleteDeliveryChannel)) } </span><span class="no">PATTERN </span> <span class="nx">metric_transformation</span> <span class="p">{</span> <span class="nx">name</span> <span class="p">=</span> <span class="s2">"ConfigTamperingCount"</span> <span class="nx">namespace</span> <span class="p">=</span> <span class="s2">"Security/CIS"</span> <span class="nx">value</span> <span class="p">=</span> <span class="s2">"1"</span> <span class="p">}</span> <span class="p">}</span> <span class="nx">resource</span> <span class="s2">"aws_cloudwatch_metric_alarm"</span> <span class="s2">"config_tampering"</span> <span class="p">{</span> <span class="nx">alarm_name</span> <span class="p">=</span> <span class="s2">"CRITICAL-ConfigTampering"</span> <span class="nx">namespace</span> <span class="p">=</span> <span class="s2">"Security/CIS"</span> <span class="nx">metric_name</span> <span class="p">=</span> <span class="s2">"ConfigTamperingCount"</span> <span class="nx">statistic</span> <span class="p">=</span> <span class="s2">"Sum"</span> <span class="nx">period</span> <span class="p">=</span> <span class="mi">60</span> <span class="nx">evaluation_periods</span> <span class="p">=</span> <span class="mi">1</span> <span class="nx">threshold</span> <span class="p">=</span> <span class="mi">1</span> <span class="nx">comparison_operator</span> <span class="p">=</span> <span class="s2">"GreaterThanOrEqualToThreshold"</span> <span class="nx">treat_missing_data</span> <span class="p">=</span> <span class="s2">"notBreaching"</span> <span class="nx">alarm_actions</span> <span class="p">=</span> <span class="p">[</span><span class="nx">aws_sns_topic</span><span class="p">.</span><span class="nx">security</span><span class="p">.</span><span class="nx">arn</span><span class="p">]</span> <span class="p">}</span> </code></pre> </div> <p>Why this matters: an attacker with admin access often disables Config to stop recording evidence. A 60-second alarm period means you know within a minute.</p> <p>Key tip: always set <code>treat_missing_data = "notBreaching"</code>. The default causes false alarms during quiet periods.</p> aws security cloudwatch devops