Try each one before opening the answer. Every option is explained, with the Microsoft documentation page that proves it.
Question 1 · choose 2
An insurer's AKS clusters use a shared cluster-admin kubeconfig that several engineers keep on their laptops, and the API server is reachable from the whole internet. The new requirements say every action must be tied to a named identity governed by Microsoft Entra ID, and the API server must not be open to the internet. Which two requirements should the design specify? (Choose TWO.)
AMicrosoft Entra ID authentication with Azure RBAC for Kubernetes authorization, and local accounts disabled
BA private cluster, or authorized IP ranges on the API server
CRotate the shared kubeconfig every month
DMicrosoft Entra ID authentication, with local accounts left enabled so the shared kubeconfig keeps working
EGive every engineer the Azure Kubernetes Service Contributor role permanently
Show the answer and why
AMicrosoft Entra ID authentication with Azure RBAC for Kubernetes authorization, and local accounts disabled
Correct
Entra integration ties access to named identities, Azure RBAC role assignments authorize Kubernetes actions, and disabling local accounts removes the shared credential.
BA private cluster, or authorized IP ranges on the API server
Correct
A private cluster or authorized IP ranges stop the API server being reachable from the whole internet.
CRotate the shared kubeconfig every month
Incorrect
Rotation doesn't tie actions to named identities.
DMicrosoft Entra ID authentication, with local accounts left enabled so the shared kubeconfig keeps working
Incorrect
The shared cluster-admin credential stays usable, so not every action is tied to a named Entra identity.
EGive every engineer the Azure Kubernetes Service Contributor role permanently
AKS supports Microsoft Entra ID authentication for the control plane, and Microsoft Entra ID authorization uses Azure RBAC role assignments to grant access to Kubernetes resources; local accounts should be disabled, with a break-glass path only as a fallback. API server exposure is limited with a private cluster or with authorized IP ranges.
A leaked API key for a Foundry Tools resource (formerly Azure AI services) was used from outside the company for two weeks. The security architect wants every current and future AI services resource in the subscriptions to accept only Microsoft Entra ID authentication. What should the requirement specify?
ADisable local authentication and enforce it with the built-in Azure Policy
BRegenerate the keys every 30 days
CStore the keys in Key Vault instead of app settings, and grant the apps a managed identity to read the keys from the vault
DAdd a content filter to every deployment
Show the answer and why
ADisable local authentication and enforce it with the built-in Azure Policy
Correct
Disabling local authentication makes resources accept only Entra ID, and the built-in policy applies it to all resources in scope.
BRegenerate the keys every 30 days
Incorrect
Rotation shortens exposure but keeps key-based access.
CStore the keys in Key Vault instead of app settings, and grant the apps a managed identity to read the keys from the vault
Incorrect
Keys stored anywhere can still be used if leaked.
DAdd a content filter to every deployment
Incorrect
Filters screen content, not who can authenticate.
Foundry Tools resources support Microsoft Entra authentication, and organizations can disable local (key-based) authentication. The built-in Azure Policy definition that requires key access to be disabled can be assigned at subscription or resource group level to enforce this across resources.
An audit of 80 App Service web apps finds deployment credentials (username and password) used for FTP and Web Deploy, some shared in old scripts. The security requirements for web workloads must remove this weakness while keeping CI/CD deployments working. What should they specify?
AChange the deployment passwords every quarter
BAdd an IP restriction for the public site only, limiting it to the addresses used by the build servers and the office
CDisable basic authentication for FTP and Web Deploy, and deploy with Entra identities
DEnable App Service authentication for end users
Show the answer and why
AChange the deployment passwords every quarter
Incorrect
Rotating the same kind of credential leaves the weakness.
BAdd an IP restriction for the public site only, limiting it to the addresses used by the build servers and the office
Incorrect
Site access restrictions don't stop deployment credential misuse.
CDisable basic authentication for FTP and Web Deploy, and deploy with Entra identities
End-user authentication doesn't change how deployments authenticate.
App Service provides basic authentication for FTP and Web Deploy using deployment credentials. You can disable basic authentication, use fallback deployment methods based on Microsoft Entra ID, and monitor any basic authentication attempts.
A company is connecting 50,000 smart meters to Azure IoT Hub. The security requirement draft says every device must sign in with Microsoft Entra ID for device-to-cloud messages, and backend services must also use Entra ID. Which correction should the architect make?
ADevices should share one symmetric key so they're easier to manage
BDevices should use the IoT Hub owner connection string
CUse per-device X.509 certificates; Entra ID isn't supported on device APIs
DKeep the draft, but give each meter its own Azure RBAC role assignment so Entra tokens work on the device APIs
Show the answer and why
ADevices should share one symmetric key so they're easier to manage
Incorrect
A shared key means one leak compromises every device.
BDevices should use the IoT Hub owner connection string
Incorrect
Embedding a hub-wide owner credential on devices is a severe risk.
CUse per-device X.509 certificates; Entra ID isn't supported on device APIs
Correct
IoT Hub device APIs authenticate with symmetric keys or X.509 certificates; Microsoft Entra ID isn't supported for them.
DKeep the draft, but give each meter its own Azure RBAC role assignment so Entra tokens work on the device APIs
Incorrect
Entra ID isn't supported for device APIs whatever the roles, and IoT Hub role assignments can't be scoped to an individual device identity.
IoT Hub authenticates devices with X.509 certificates or symmetric keys; Microsoft Entra ID authentication isn't supported for device APIs such as device-to-cloud messages and reported property updates, so the device part of the draft must change. Per-device X.509 certificates avoid a shared secret across the fleet.
In the shared responsibility model, Microsoft is responsible for physical hosts, network and datacenter for IaaS, while the customer is responsible for the operating system, network controls, applications, identities and data.
What is an Azure security baseline, such as the one for App Service?
AA legal contract between Microsoft and the customer about each service's security commitments
BA monthly bill for security features
CMCSB guidance applied to one specific service
DA list of the service's outages
Show the answer and why
AA legal contract between Microsoft and the customer about each service's security commitments
Incorrect
Baselines are technical guidance.
BA monthly bill for security features
Incorrect
Baselines aren't billing documents.
CMCSB guidance applied to one specific service
Correct
Security baselines apply MCSB controls to an individual Azure service.
DA list of the service's outages
Incorrect
Outage history is in service health.
Security baselines for Azure apply guidance from the Microsoft cloud security benchmark to the specific service, describing which security features are available and how to configure them.
Are the prompts and completions a company sends to Azure OpenAI models in Microsoft Foundry used to improve the model providers' models?
ANo, they aren't used to improve the providers' models
BYes, all prompts are used to retrain the public models unless the company opts out in the portal
COnly prompts from free trial subscriptions are used
DYes, unless the company pays for a premium support plan
Show the answer and why
ANo, they aren't used to improve the providers' models
Correct
Prompts, completions, embeddings and training data aren't used by providers to improve their models.
BYes, all prompts are used to retrain the public models unless the company opts out in the portal
Incorrect
Customer data isn't used that way.
COnly prompts from free trial subscriptions are used
Incorrect
There's no such exception described.
DYes, unless the company pays for a premium support plan
Incorrect
Support plans don't change data use.
For Foundry Models sold by Azure, including Azure OpenAI models, prompts, completions, embeddings and training data aren't used by the model providers to improve their models or services, and aren't used to train generative AI foundation models without your permission or instruction.
What's true about the admin user account of an Azure Container Registry?
AIt's enabled by default and required for AKS clusters to pull images from the registry
BIt can be scoped to read-only access
CIt's disabled by default and meant mainly for testing
DIt's the only way to authenticate to the registry
Show the answer and why
AIt's enabled by default and required for AKS clusters to pull images from the registry
Incorrect
AKS pulls with managed identities, and the admin user is disabled by default.
BIt can be scoped to read-only access
Incorrect
The admin account has full push and pull permissions.
CIt's disabled by default and meant mainly for testing
Correct
The admin account has full permissions and shouldn't be shared.
DIt's the only way to authenticate to the registry
Incorrect
Microsoft Entra identities can authenticate.
Each container registry has an admin user that's disabled by default and has full permissions. It's designed for a single user, mainly for testing, and its credentials shouldn't be shared; use individual identities for access.