These questions cover identity, data security, and container networking — areas the AZ-305 exam tests at the architectural design level, asking you to choose between services rather than configure them.
Question 1
External auditors need read-only access to Azure resource configurations for a compliance review. They must use their own corporate credentials. Which solution is correct?
- A) Create local member user accounts in the organisation's Entra ID tenant and assign the Reader role
- B) Invite the auditors as Azure AD B2B guest users and assign the Reader role at the subscription scope
- C) Share the subscription Owner credentials with the auditors
- D) Export resource configuration data to a storage account and share the SAS URL
Answer: B — B2B guest users with Reader role
Azure AD B2B collaboration lets external users authenticate with their own organisation's identity provider (their corporate credentials) while you control what they can access in your tenant via RBAC. The auditors never need credentials you manage.
Why this is the right design:
- Own credentials: B2B guests authenticate with their home tenant — no password management on your side
- Scoped access: Reader role at subscription scope = read-only to all resources, no write permissions
- Auditable: All access is logged in Entra ID and Azure Monitor under the auditor's identity
- Time-bounded: Guest accounts can be set to expire after the engagement
Creating member accounts gives broader directory permissions than guest accounts and requires you to manage credentials. Sharing Owner credentials is a critical security failure.
</details>Question 2
A company stores sensitive documents in Azure Blob Storage. Compliance requires the encryption keys to be controlled by the security team, not Microsoft. Which configuration is required?
- A) Enable Azure Blob Storage default encryption (already uses Microsoft-managed keys)
- B) Configure the storage account to use customer-managed keys (CMK) stored in Azure Key Vault
- C) Enable Azure Information Protection on the storage account
- D) Enable infrastructure double encryption
Answer: B — Customer-managed keys (CMK) in Azure Key Vault
Azure Storage encrypts all data at rest by default using Microsoft-managed keys. CMK moves key control to you — the encryption key lives in your Azure Key Vault, and the security team controls rotation, revocation, and access policy.
Key management options for Azure Storage:
| Option | Key managed by | Use case |
|---|---|---|
| Microsoft-managed keys | Microsoft | Default, no compliance requirement |
| Customer-managed keys (CMK) | Customer (Key Vault) | Compliance, key rotation control |
| Customer-provided keys | Customer (per-request) | Client-side key control per operation |
If the security team needs to revoke access, they can disable or delete the key in Key Vault — all blobs encrypted with that key become inaccessible immediately.
Azure Information Protection adds classification and protection labels to documents — it's not about storage-level encryption key management.
</details>Question 3
An AKS cluster serves multiple teams via separate namespaces. The security team requires pods in different namespaces to be unable to communicate directly with each other. Which approach enforces this?
- A) Kubernetes RBAC with namespace-scoped roles
- B) Kubernetes Network Policies using the Azure CNI or Calico plugin
- C) Azure NSGs applied to the AKS node subnet
- D) Azure Firewall with FQDN filtering on AKS egress traffic
Answer: B — Kubernetes Network Policies
Kubernetes Network Policies control pod-to-pod traffic at the IP and port level within the cluster. A NetworkPolicy in namespace A that denies ingress from all namespaces except A means pods in namespace B can't reach pods in namespace A directly.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-cross-namespace
namespace: team-a
spec:
podSelector: {}
ingress:
- from:
- podSelector: {}
Important: Network Policies require a CNI plugin that supports them. In AKS, you must choose Azure CNI with network policy enabled, or Kubenet with Calico. The default AKS setup without a policy engine ignores NetworkPolicy objects.
Kubernetes RBAC controls API access (who can deploy, get, delete), not pod network traffic. NSGs operate at the node VM network level and can't distinguish between pods on the same node. Azure Firewall handles egress to external destinations, not intra-cluster pod traffic.
</details>Key Takeaways
- External users = B2B guest users; they authenticate with their own org's credentials, you control access via RBAC
- CMK in Key Vault = compliance-grade key control; Microsoft-managed keys are the default, not a compliance option
- Network Policies control pod-to-pod traffic but require a compatible CNI plugin (Azure CNI or Calico) to take effect