Kubernetes training for application teams using restricted AKS namespaces

We offer private, instructor-led training for developers who understand local Kubernetes examples but need to deploy and diagnose applications inside restricted AKS namespaces.

Your team knows basic workload resources. Local administrator access hides the boundaries of a shared platform, including permissions, ingress ownership, Azure identities, and infrastructure support.

LearnKube uses a sample application with namespace-scoped access to connect those differences. Your engineers will practice the actions they own and gather useful evidence for PlatformOps.

Discuss your team's training

Learning in practice

Hands-on learning and the skills engineers take back to work.

Preview: course-wide figures are not yet available.

Hands-on learning
60%
Of instruction time spent on labs and challenges.
Troubleshooting confidence
86%
Of respondents report greater confidence diagnosing Kubernetes problems.
Relevant to your work
92%
Of respondents say the course addressed their engineering responsibilities.
Skills put into practice
95%
Of respondents applied their new skills at work within 90 days.

Work effectively within the access your team has

Deploy an application in its namespace by using permitted workload resources and platform conventions, so developers can deliver changes without assuming cluster-wide control.
Preserve application access by configuring the available traffic, credential, and storage interfaces, so the workload can use the shared services it requires.
Diagnose restricted-environment failures by inspecting permitted events, logs, and authorization results, so developers can distinguish application corrections from platform requests.
Define the PlatformOps handoff by documenting the resource, action, scope, and evidence behind an issue, so the responsible team can act without unnecessary escalation.

The same resource sits inside a different permission boundary

Local examples often use broad permissions and directly configured infrastructure. In a shared AKS environment, role bindings can limit application work to a namespace, while platform teams manage cluster-wide capabilities. AKS identity also separates user, workload, and Azure-resource access. Developers need to identify which identity and resource scope apply to each task.

I want developers to explain a forbidden response before they ask for cluster-admin. They need to identify the resource, verb, and namespace involved, then decide whether the application team or PlatformOps owns the action.
— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirement	New concept or decision	Practice
Apply a local example	Namespace-scoped permissions	Inspect a denied action
Publish an application route	Shared ingress ownership	Trace the permitted route
Access an Azure dependency	User and workload identities	Identify the active credential
Request platform support	Evidence and responsibility boundaries	Prepare a useful escalation

Case Study: EDF Trading

EDF Trading developers use AKS within dedicated namespaces while PlatformOps controls the wider cluster. The team wanted a clearer connection between local Kubernetes exercises and that operating environment.

LearnKube delivered three-day developer courses with hands-on labs and retained material. The instructor covered AKS, and further private courses followed.

The course was easy to follow, interactive and designed very well
— Valdis, Data & IT Graduate at EDF Trading.

A recommended four-day workshop for namespace-scoped application work

We recommend this four-day agenda for your team, with explicit comparisons between local exercises and restricted platform access.

Day 1

Workloads, releases, and permitted actions

We review Pods, Deployments, Services, and probes through an application developer's access. You will compare local examples with resources and operations permitted in a shared namespace.

Hands-on exercises

Deploy and update a sample application using a restricted identity.
Diagnose an unready release using accessible workload events and logs.

Day 2

Templates and the architecture outside your namespace

You will use Helm and compare Kustomize for repeatable application configuration. We explain controllers, nodes, and the control plane so developers understand the components they do not administer.

Hands-on exercises

Adapt a release that incorrectly tries to create cluster-scoped resources.
Observe a replacement Pod and identify which actions the workload controller performs.

Day 3

Shared routes and dependency connections

We connect DNS, Services, ingress, and network policies to the platform's supported interfaces. You will discuss service mesh use cases and distinguish application placement requirements from node-management decisions.

Hands-on exercises

Trace a request through the application's approved route.
Diagnose a failed dependency connection and identify the platform evidence needed for escalation.

Day 4

Credentials, state, scaling, and role boundaries

You will examine configuration, secrets, storage claims, and HPA settings within the available permissions. We distinguish application identity, developer access, and the Azure operations controlled by PlatformOps.

Hands-on exercises

Diagnose an application credential failure separately from a denied Kubernetes action.
Inspect a storage or capacity constraint and prepare a focused platform-support request.

Your namespace permissions, shared integrations, and PlatformOps boundaries can shape the agenda. Get in touch to tailor the workshop to your application team's AKS adoption.

Turn a denied command into a precise question

When an engineer expects a local command to work unchanged on AKS, the instructor can examine its required permissions and resource scope. Your team can identify a permitted alternative or explain exactly what PlatformOps needs to provide.

Start with the permissions and interfaces available to developers

Tell us what your team can change in AKS, which shared services it uses, and how PlatformOps receives support requests. We will recommend exercises for that operating boundary.

Discuss your team's training