SC-100 Managed Identity 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.

• ✓

  Enable managed identity for the AKS cluster, integrate Key Vault with AKS using the Secrets Store CSI driver, deploy the cluster as a private cluster, and enable diagnostic settings on Key Vault to send logs to a Log Analytics workspace.

  Why this is correct

  Managed identity eliminates long-lived service principal credentials by providing an Azure AD-backed identity automatically rotated, which AKS uses to authenticate to Key Vault. The Secrets Store CSI driver mounts selected Key Vault items directly into pods as ephemeral volumes, so secret material never persists in etcd and supports rotation without pod restarts. Deploying AKS as a private cluster ensures the Kubernetes API server receives only private IP addresses, preventing exposure to the public internet. Enabling diagnostic settings on Key Vault streams audit event logs to Log Analytics, giving the security operations team a centralized, queryable trail of access and modifications.

• ✗

  Use a service principal for AKS to access Key Vault, store secrets as Kubernetes secrets, configure a private cluster, and enable audit logging on Key Vault.

  Why it's wrong here

  Using a service principal reintroduces a static credential that must be provisioned, stored, and rotated somewhere in the deployment pipeline, creating an unnecessary attack surface compared to managed identity. Storing the pulled secrets as Kubernetes secrets means they exist in the cluster's etcd database; without an encryption provider configured, these are merely base64-encoded and readable by anyone with etcd access. A private cluster prevents API server exposure, but it does nothing to protect secrets at rest. Key Vault audit logging will record the service principal's reads, but it will not protect the wide-spread plaintext copies that are now living in Kubernetes secrets.

• ✗

  Enable managed identity for the AKS cluster, store secrets in the cluster's native Kubernetes secrets, use a private endpoint for the AKS API server, and enable Azure Monitor for containers.

  Why it's wrong here

  While enabling managed identity is a positive step, keeping secrets as native Kubernetes secrets leaves them in etcd in plaintext base64 rather than in Key Vault, and Kubernetes has no built-in encryption at rest unless you explicitly configure a KMS provider. A private endpoint on the AKS API server only changes how the API server is reached; it does not convert a standard cluster into a private cluster, because node-to-API-server communication and cluster operations may still use the public DNS and network path. Azure Monitor for containers provides CPU and memory telemetry, not secret encryption or network isolation. Thus the solution still misses the core requirement of keeping secret material out of etcd and making the cluster fully private.

• ✗

  Use a service principal to access Key Vault, store secrets as encrypted Kubernetes secrets with a customer-managed key, deploy a public cluster with network policies, and enable Key Vault logging.

  Why it's wrong here

  Relying on a service principal requires you to manage and rotate a client secret or certificate, and if it leaks, an attacker can read all Key Vault contents; managed identity removes that static credential completely. The proposal to encrypt Kubernetes secrets with a customer-managed key is not a native Kubernetes feature—it requires extra components like Azure Key Vault KMS provider or a tool such as SOPS, and even then the secrets are still Kubernetes secrets rather than being mounted directly from the vault. A public cluster with network policies can restrict east-west traffic, but the API server remains reachable from the public internet without a private cluster configuration. Enabling Key Vault logging only generates records; it never protects the secret material that is already stored in etcd.

Go deeper

Related to this question