A reviewer answers “secure AKS” with a twelve-chart service mesh for the canal scheduler. Which host and cluster security controls should the security engineer prioritize instead?
Select an answer to reveal the explanation.
Short Explanation
Twelve Helm charts aren’t the AZ-500 answer. Patch the node image, keep Kubernetes current, kill public node IPs, and force egress through the hub firewall—that’s cluster security, not an app cookbook.
Full Explanation
Prioritize host and cluster security outcomes: keep node images and Kubernetes versions current, disable public IP addresses on nodes, and restrict cluster egress through the hub firewall. Those controls harden the tugboat/canal AKS estate at the platform layer the AZ-500 expects, rather than answering “secure AKS” with a twelve-chart service mesh cookbook.
Packaging every microservice under a custom Helm umbrella and treating mesh sidecars as the only required security control fails by concept: mesh can help service identity and traffic policy, but it does not replace node patching, private nodes, or egress control. Replacing AKS with Azure Container Instances so host hardening and egress “are no longer required” fails because moving runtimes does not eliminate the need for image, identity, and network controls—and it ignores the existing AKS requirement. Opening outbound Any on node NSGs so image pulls never fail during reviews fails by widening egress and undermining hub firewall inspection.
Exam caveat: service mesh and Helm are application-delivery topics; cluster security questions lean toward node hygiene, private networking, and controlled egress. Operational check: verify node image/Kubernetes version currency in the portal, confirm nodes have no public IPs, and test that egress is forced through the hub firewall with denies for unexpected destinations.