SC-100 Private cluster 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.

• ✓

  Deploy AKS as a private cluster with no public endpoint.

  Why this is correct

  Deploying AKS as a private cluster with no public endpoint is essential because the Kubernetes API server is placed behind a private IP address on a virtual network, using Azure Private Link. This prevents the control plane from being reachable from the internet, directly satisfying PCI DSS network compartmentalization requirements for cardholder data environments. Unlike merely disabling public access, this design ensures administrative and operational traffic to the API server also traverses the private network.

• ✓

  Configure Always Encrypted for sensitive columns in Azure SQL Database.

  Why this is correct

  Configuring Always Encrypted for sensitive columns in Azure SQL Database protects data by encrypting it client-side before it ever reaches the database, with keys stored in Azure Key Vault or Windows Certificate Store. The database service only sees ciphertext, so even DBAs or threat actors with access to the server cannot read plaintext values. This addresses PCI DSS encryption-at-rest requirements while also preventing data exposure during transit from the application to the database, complementing network-level isolation.

• ✗

  Enable Azure RBAC for Kubernetes authorization.

  Why it's wrong here

  Enabling Azure RBAC for Kubernetes authorization is incorrect as a standalone control because it only governs user and group permissions to perform API actions, not the network traffic or packet-level isolation required by PCI DSS. While RBAC is a good security hygiene practice, it does nothing to prevent an attacker from reaching an exposed API server or pivoting between pods. PCI DSS mandates strict network segmentation, which RBAC cannot deliver; network policies or a private cluster are required for that isolation.

• ✓

  Use private endpoints for Azure SQL Database and Azure Cache for Redis.

  Why this is correct

  Using private endpoints for Azure SQL Database and Azure Cache for Redis ensures each service receives a private IP address inside the virtual network and all traffic to those services flows over the private network backbone rather than the public internet. This removes the need to expose service FQDNs to the internet, reducing the attack surface for cardholder data stores. Unlike service endpoints, private endpoints provide fine-grained access control and prevent data exfiltration through the public endpoint, aligning with PCI DSS network requirements.

• ✗

  Disable TLS for Azure Cache for Redis to improve performance.

  Why it's wrong here

  Disabling TLS for Azure Cache for Redis is explicitly wrong because PCI DSS requires encryption of cardholder data in transit, and Redis without TLS sends all data — including sensitive values or application tokens — as plaintext over the network. This would expose the Redis cache to eavesdropping or man-in-the-middle attacks, especially because Redis is often used for session state or caching sensitive request data. Even if performance improves slightly, the compliance and security risk far outweighs the benefit; TLS 1.2+ is mandatory for production workloads.

Go deeper

Related to this question