AZ-204 Implement Azure security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Store secrets as Kubernetes secrets without encryption

  Why it's wrong here

  Storing secrets as unencrypted Kubernetes secrets is a significant security vulnerability because Kubernetes secrets are only base64 encoded by default, not encrypted at rest in etcd. This means that anyone with access to the etcd database or the cluster API can easily decode and view sensitive information, such as database credentials or API keys. For true security, secrets should be encrypted at rest using a Key Management System (KMS) like Azure Key Vault via a Secrets Store CSI driver.

• ✗

  Enable SSH access to all nodes for troubleshooting

  Why it's wrong here

  Enabling broad SSH access to all worker nodes significantly expands the attack surface of an Azure Kubernetes Service (AKS) cluster. Each open SSH port represents a potential entry point for attackers if credentials are compromised or weak, making the cluster more susceptible to unauthorized access and malicious activity. Best practice dictates restricting direct node access, often leveraging Azure Bastion or Just-In-Time (JIT) access for audited and temporary troubleshooting.

• ✓

  Enable Azure AD integration with Kubernetes RBAC

  Why this is correct

  Enabling Azure Active Directory (Azure AD) integration with Kubernetes Role-Based Access Control (RBAC) is a fundamental security measure for AKS, providing robust identity-based access control. This integration allows organizations to leverage their existing Azure AD identities and groups to define granular permissions within the Kubernetes cluster. It centralizes authentication and authorization, ensuring that only authorized users and service principals can perform specific actions, thereby enforcing the principle of least privilege.

• ✗

  Deploy Azure Firewall in the cluster VNet

  Why it's wrong here

  Deploying Azure Firewall in the cluster's Virtual Network (VNet) primarily provides perimeter security for inbound and outbound traffic at the VNet level, inspecting traffic between the VNet and external networks or other VNets. While beneficial for overall network security, it does not directly secure internal pod-to-pod communication or access to the Kubernetes API server within the cluster itself. Azure Firewall is not designed for micro-segmentation within the cluster, which is a critical aspect of securing containerized workloads.

• ✓

  Use network policies to restrict pod-to-pod communication

  Why this is correct

  Using Kubernetes Network Policies is a crucial action to secure an AKS cluster by enabling micro-segmentation and restricting pod-to-pod communication. These policies define rules for how pods are allowed to communicate with each other and with external network endpoints, based on labels and namespaces. By limiting network access to only what is necessary, network policies significantly reduce the blast radius of a compromised pod and prevent unauthorized lateral movement within the cluster.

Go deeper

Related to this question