Cloud foundations
Infrastructure as code with Pulumi, Terraform, and AWS CDK. Repeatable environments, clear boundaries, and configurations people can review.
AWS · IaC · ServerlessDevOps · Infrastructure automation
Complex systems.
Clear thinking.
I’m James Jenkins. I turn cloud infrastructure, delivery pipelines, and operational workflows into systems that are easier to build, understand, and run.
Based in Utah / Jenkins Cloud Solutions
THE ENGINEER BEHIND THE SYSTEMS01 / JJ
James JenkinsDevOps + AI Engineer Contractor
Build it deliberately.
Make it repeatable.
Leave a clear path for the next person.
IN THE TOOLKIT
AWSAzureGoogle CloudKubernetesPulumiTerraformAWS CDKGitLab CI/CDisCOBOLPuppeteerPython
01 / Practice
Infrastructure with
an operating plan.
I work across the lifecycle: provision the environment, ship the application, and make the next change easier to reason about.
Delivery & operations
Kubernetes, EKS, Helm, and GitLab pipelines. Deployment workflows that connect a source change to an identifiable release and a recovery path.
Kubernetes · Helm · CI/CDUseful automation
Python services, AWS Lambda, API Gateway, and AI-assisted workflows. Reduce repetitive work while keeping decisions and results inspectable.
Python · APIs · AI workflowsSelected engineering work
From complex workflows
to repeatable systems.
Two examples of my contribution. Client identities and internal implementation details are omitted.
Case study / 01Build engineering
Parallel isCOBOL builds in GitLab
I created a parallel compilation pipeline that makes shared prerequisites, worker isolation, and final packaging explicit.
- isCOBOL
- GitLab CI/CD
- Shell
- Artifact validation
Case study / 02AWS client work
Checking beyond the login screen
As an AWS DevOps Consultant, I used browser automation to check an internal tool and reuse authentication state between checks.
- CloudWatch Synthetics
- Puppeteer
- DynamoDB
- Functional monitoring
Public repositories / Workbench
Practical projects.
Ideas you can inspect.
Identity & accessReference implementation
Multi-cloud Kubernetes RBAC
A shared namespace access policy for existing EKS, AKS, and GKE clusters, with Terraform identity mappings and automated allow/deny checks on a local kind cluster.
- Terraform
- EKS / AKS / GKE
- Kubernetes RBAC
- Python
Cloud deliveryReference implementation
GitLab OIDC cloud deployments
GitLab-to-cloud OIDC federation with scoped trust, temporary credentials, separate dev/prod storage, and rejection tests. Cloud deployment jobs are disabled until federation and storage are configured.
- GitLab CI/CD
- OIDC
- Terraform
- AWS / Azure / Google Cloud
Reliability & diagnosisLocal lab
Kubernetes SRE observability
A local Kubernetes and Docker Compose lab connecting an instrumented Python API to Prometheus SLOs, Grafana dashboards, OpenTelemetry traces, and controlled fault injection.
- Kubernetes
- Prometheus
- Grafana
- OpenTelemetry
- Python
Infrastructure as codePublic example
AWS CDK → EKS
A Python/AWS CDK example for an EKS cluster and Helm-deployed NGINX application, including ALB ingress and CI configuration.
- Python
- AWS CDK
- Kubernetes
- Helm
Streaming & servicesPublic example
Kinesis ingest service
Python ingestion examples using Kinesis/Firehose, S3, and DynamoDB, with Terraform/EKS and Helm deployment configuration.
- Python
- AWS
- Terraform
- Helm
Descriptions reflect the public source and README. Each repository documents its setup, scope, and validation; the examples are available to explore and adapt.
Part of the delivery / Documentation
Leave good documentation.
Make the next step clear.
I leave clear, practical documentation alongside my work, so another engineer can set it up, understand the decisions, troubleshoot a problem, and carry it forward.
- A clear starting point
Prerequisites, setup, validation, limitations, and cleanup.
- Commands with context
Explain what to run, which signals matter, and how to interpret the result.
- A way to verify recovery
Define healthy behavior and the checks that confirm it.
- A useful handoff
Record evidence, decisions, and follow-up actions for the next engineer.
docs/runbook.mdPublic local-lab example
An incident runbook someone else can follow
A public guide to investigating error-budget burn and missing telemetry in my local Kubernetes SRE lab, with commands, interpretation, recovery checks, and a postmortem handoff.
- Confirm the symptom
Identify the service and SLO, compare user-facing request signals, and inspect both alert windows.
- Follow the evidence
Correlate logs with a trace ID and inspect the request and dependency spans in Grafana and Tempo.
- Recover and verify
Stop the local fault traffic, supply healthy baseline traffic, then confirm successful requests and alert recovery.
One documented check · local Compose lab
docker compose logs --since=10m app otel-collector tempo02 / Architecture & standards
Draw the system.
Explain the decisions.
Architecture is a set of decisions you can explain: who can act, where traffic flows, what gets deployed, and how the system recovers.
Explore compute patterns for AWS, Azure, and Google Cloud, alongside delivery, access, and engineering standards. These illustrative designs make the boundaries and decisions visible.
- Enter through a public load balancer
An Application Load Balancer accepts HTTPS and forwards application requests to its registered targets.
- Run the app across Availability Zones
An EC2 Auto Scaling group places application instances in private subnets across two Availability Zones.
- Scale and replace deliberately
Use demand metrics for scaling and configure load-balancer health checks for instance replacement.
- Keep the database connection private
The application connects to the RDS primary through its database endpoint, with network access scoped to the application tier.
- Provide a database recovery path
An RDS Multi-AZ DB instance synchronously replicates to a standby in another Availability Zone. That standby supports failover; it does not serve reads.
01
Separate the tiers
Public ingress, private compute, and database access have distinct network boundaries.
02
Spread the application
Multiple Availability Zones and health-based replacement reduce dependence on one instance.
03
Choose the right resilience
Application scale-out and database failover solve different problems.
- Accept HTTPS at the gateway
Application Gateway WAF v2 provides the public entry point in its own dedicated subnet.
- Distribute requests to private backends
The gateway routes requests to application VMs in a scale set across availability zones.
- Operate the compute fleet
Health probes and autoscale rules support routing and capacity decisions. Plan instance repair and upgrades explicitly.
- Connect through a private endpoint
A private endpoint gives Azure SQL a private address reachable from the application virtual network. Azure SQL remains a managed service outside the VNet.
- Resolve the database name correctly
Private DNS maps the database hostname to the endpoint. Configure database authentication and public-network access separately.
01
Reserve the gateway subnet
Application Gateway uses its own subnet, separate from application VMs.
02
Make capacity intentional
Availability zones, probes, scaling, and repair each need an explicit configuration.
03
Show the service boundary
The SQL service and its private endpoint are different parts of the architecture.
- Start at the provider-managed edge
A global external Application Load Balancer accepts HTTPS and forwards traffic to the backend service. The global edge sits outside the customer VPC.
- Spread Compute Engine VMs across zones
A regional managed instance group distributes application VMs across zones in the region.
- Separate health from capacity
Load-balancer health checks guide routing. Configure autoscaling and MIG autohealing for their respective jobs.
- Connect privately to Cloud SQL
A Private Service Connect endpoint in the customer VPC connects the application to the managed Cloud SQL service.
- Plan identity and recovery
Use scoped VM service accounts for Google APIs, configure database authentication, and select the database availability and backup options the application needs.
01
Use the right scope
The global load-balancing edge and regional compute fleet have different scopes.
02
Design for zonal disruption
Regional MIG distribution adds redundancy across zones.
03
Name the private connection
Cloud SQL private IP depends on configured connectivity and permissions.
- Delivery identity
GitLab CI exchanges its OIDC token for a scoped AWS role. The trust policy defines which jobs may assume it.
- Artifact identity
The pipeline publishes an image to ECR. An image digest identifies the bytes selected for deployment.
- Runtime boundary
HTTPS traffic enters through an application load balancer and reaches the application in an EKS workload boundary.
- Workload identity
The application uses its own scoped AWS identity for S3 access. Its permissions are separate from the pipeline’s role.
01
Trust is explicit
CI authority and application permissions are separate identities.
02
Boundaries are visible
Account, network, and workload boundaries are part of the design.
03
Artifacts are traceable
A release points to a specific image digest.
- Define the contract
Record ownership, access scope, expected behavior, and the conditions for a successful release.
- Validate the change
Review infrastructure and application changes, then run relevant tests and policy checks.
- Identify the release
Retain the source commit, pipeline result, and immutable artifact identifier.
- Release with a recovery path
Use deployment gates, verify health and the real request path, and keep the previous release available.
- Observe and improve
Use metrics, logs, and runbooks to feed operational evidence into the next change.
01
Reviewable changes
The proposed change and its evidence can be inspected together.
02
Verifiable outcomes
A successful job is followed by checks of actual behavior.
03
Concrete recovery
A known release and a usable restore procedure are retained.
- Identity: ServiceAccount
The workload runs as apps:pod-observer. Identity alone does not grant permissions.
- Connection: RoleBinding
The binding names the subject and points to the Role in the apps namespace.
- Permissions: Role
Allow get, list, and watch on Pods, plus get on the pods/log subresource.
- Scope: apps namespace
The grant applies to the named namespace. Check other bindings too: RBAC grants are additive.
01
An intentional identity
Use a workload-specific ServiceAccount.
02
A small grant
Name the required resources and operations.
03
A tested boundary
Check both required access and operations outside the grant.
A small example / RBAC
Make the boundary
visible.
A useful permission model explains what an identity can do—and gives you a way to check where that access ends.
Try this policy sketch: a service account can read Pods in the observability namespace.
permission-check / example
IDENTITY
system:serviceaccount:observability:reader
CHECK$ kubectl auth can-i get pods
-n observability
--as=system:serviceaccount:observability:readeryes
The Role grants read access to Pods in this namespace.
Illustrative policy · runs entirely in your browser
03 / Engineering notes
The reasoning
behind the work.
Practical guides on access, diagnosis, and delivery. Written to be useful at the terminal, with links to the source documentation.
01Security & RBAC
Kubernetes RBAC that is small enough to explain
Start with identity, scope, and concrete operations. Then verify both the access a workload needs and the boundaries it should keep.
5 min readRead the note
02Kubernetes
Debug Kubernetes by following the evidence
A repeatable path from a failing request to the responsible layer: workload state, process logs, probes, routing, and resource signals.
5 min readRead the note
03GitLab CI/CD
GitLab pipelines that make releases verifiable
Connect pipeline rules, immutable artifacts, deployment authority, temporary cloud credentials, and a practical recovery path.
5 min readRead the note
04 / Engineering community
Help another engineer
get unstuck.
I share what I learn on Stack Overflow: answering questions, investigating the details, and following up when the first explanation leaves something unresolved.
13+years on Stack Overflow
Member since
Behind every technical question is someone trying to move a project forward. I aim to leave them with a clearer explanation and a concrete next step.
See my Stack Overflow contributionsFind me as jdj333
A real troubleshooting exchangeKeycloak · Bash · OIDC
Getting a Keycloak setup script past a 401
An engineer wanted to provision Keycloak realms from a local script, but getting and using an administrator token was blocking the setup.
Explain the path
I explained how to use the built-in admin-cli client with bootstrap administrator credentials, and why the administrator’s permissions determine what the token can do.
Follow the evidence
When the edited script still returned 401, I reproduced it on Keycloak 26.8.2. The token extracted with jq kept its JSON quotes; raw extraction with jq -r removed them, and the same realm-creation request returned 201. I also pointed out the password-variable mismatch and checking HTTP errors before continuing.
401 quoted token201 raw token
Read my answer and the follow-up I’m a DevOps and infrastructure automation engineer based in Utah.
Through Jenkins Cloud Solutions, I work across AWS infrastructure as code, serverless services, Kubernetes, and automated delivery. My focus is making complex environments repeatable, improving developer workflows, and building systems teams can understand and operate with confidence.
My background spans frontend and Java development, DevOps engineering, and cloud consulting. That mix keeps me interested in both the infrastructure and the people who depend on it.
2023 — present
Jenkins Cloud Solutions LLCDevOps + AI Engineer Contractor
2022 — 2023
Amazon Web ServicesDevOps Consultant
2019 — 2022
bioMérieuxSenior DevOps Engineer
2011 — 2019
Enterprise software engineeringFrontend & Java development → DevOps engineering
Background drawn from my LinkedIn profile; repository descriptions reflect their public documentation.
Keep the conversation going