Practice Test #4

No. Each Azure subscription has only one Account Administrator. The Account Administrator is a legacy role tied to the billing account and has broad administrative capabilities for the subscription, but it is singular per subscription. You can change (transfer) the Account Administrator, but you cannot assign multiple Account Administrators to the same subscription simultaneously. What you can have multiple of are RBAC role assignments (for example, multiple users/groups can be Owners, Contributors, or Readers at the subscription scope). Many learners confuse “multiple administrators” (true in the RBAC sense) with “multiple account administrators” (not true). For AZ-900, remember: one Account Administrator per subscription, but potentially many users with administrative permissions via RBAC.

No. An Azure subscription is not managed only by using a Microsoft account. Subscriptions are commonly managed using work or school accounts in Microsoft Entra ID (organizational identities). In enterprise scenarios, administrators sign in with Entra ID accounts and manage access using RBAC, Privileged Identity Management (PIM), Conditional Access, and other governance controls. While a Microsoft account (personal account) can be used in some cases (especially for individual/trial subscriptions), it is not the only option, and it is not the standard for organizational governance. The key exam takeaway: Azure management is typically performed through Entra ID identities, and subscriptions can be associated with an Entra tenant to enable centralized identity and access management.

No. An Azure resource group does not contain multiple Azure subscriptions. The relationship is the opposite: a subscription contains multiple resource groups. A resource group is a container for Azure resources within a single subscription and a single region for metadata (resources can be in different regions, but the resource group itself is created in a specific region). Resource groups are used to manage lifecycle (deploy/update/delete as a unit), apply RBAC at a convenient scope, and apply governance controls like Azure Policy and resource locks. Because resource groups are scoped to exactly one subscription, they cannot span or include multiple subscriptions. If you need to organize across subscriptions, you use management groups, not resource groups.

No. Authorization to access Azure resources is not provided only to Azure AD (Microsoft Entra ID) “users.” Azure authorization commonly uses Azure RBAC, which can assign roles to multiple security principals, including: - Users - Groups - Service principals (application identities) - Managed identities (system-assigned or user-assigned) Additionally, Azure can grant access to external identities such as guest users (Entra ID B2B) and identities federated from other identity providers. The word “only” makes the statement incorrect because Azure supports non-user identities and external identities for authorization. In practice, many workloads use managed identities or service principals to access resources securely without user credentials, which is a best practice for automation and applications. Therefore, limiting authorization to only Azure AD users is inaccurate.

Yes. Identities from Azure Active Directory (Microsoft Entra ID), third-party cloud services, and on-premises Active Directory can be used to access Azure resources, typically through federation or synchronization. - On-premises Active Directory identities can be synchronized to Entra ID using Azure AD Connect (or cloud sync), enabling the same identity to authenticate to Azure. - Third-party identity providers (IdPs) can be federated with Entra ID using standards such as SAML, WS-Federation, or OpenID Connect, allowing users to sign in with external identities. - Entra ID B2B also allows inviting external users (guests) from other organizations. Once authenticated, authorization is granted via Azure RBAC (or resource-specific authorization). This supports hybrid identity and single sign-on (SSO), aligning with security best practices and common enterprise requirements.

Yes. Azure includes built-in authentication and authorization capabilities to secure access to Azure resources. - Authentication: Microsoft Entra ID provides identity management and authentication features such as MFA, Conditional Access, Single Sign-On, and identity protection. - Authorization: Azure RBAC provides built-in role definitions and scope-based access control (management group, subscription, resource group, resource) to implement least privilege. Azure Policy can further enforce governance controls, and some services also support additional authorization models (e.g., data-plane RBAC for Azure Storage). These services are foundational to Azure’s security model and are heavily emphasized in AZ-900. They support the Azure Well-Architected Framework security pillar by enabling centralized identity, strong authentication, and least-privilege authorization across the platform.

No. Storing 1 TB in Azure Blob Storage does not always cost the same across regions. Azure pricing is published per region, and the per-GB (or per-TB) monthly storage rate can differ between regions (for example, East US vs. West Europe vs. Southeast Asia). In addition, the total cost of “storing 1 TB” can vary based on choices that are often tied to availability and regional offerings, such as redundancy (LRS/ZRS/GRS/GZRS) and access tier (Hot/Cool/Archive). Even if you keep the same redundancy and tier, the base storage meter is still region-dependent. The statement uses the absolute term “always,” which is a strong indicator it’s false in Azure pricing questions. Therefore, the correct selection is No.

No. With a general-purpose v2 (StorageV2) storage account, you are charged for more than just the amount of data stored. Azure Storage has separate billing meters for transactions/operations (such as read, write, list, and other requests). The exact operation costs depend on the service (Blob, Files, Queues, Tables), the access tier (Hot/Cool/Archive for Blob), and sometimes the type of operation (e.g., write vs. read). Additionally, features like data retrieval (especially from Cool/Archive), early deletion fees (Cool/Archive), and certain replication options can add cost. The statement claims “All read and write operations are free,” which is incorrect—operations are typically billed per 10,000 (or similar unit) transactions. So the correct answer is No.

No. Transferring data between Azure Storage accounts in different Azure regions is not generally free. While inbound data transfer to Azure is typically free, outbound data transfer (egress) is usually billed, and cross-region transfers commonly incur bandwidth charges. If you copy data from a storage account in Region A to a storage account in Region B, the data leaving Region A is treated as outbound bandwidth and is typically charged. There can also be additional costs depending on the method used (for example, transaction costs for reads/writes during the copy). This is an important cost-optimization concept: architectures that frequently move large datasets across regions can become expensive. Therefore, the statement “is free” is false, and the correct selection is No.

Correct answer: No. An Azure free account does not include Standard support. By default, Azure subscriptions (including Free and Pay-As-You-Go) come with Basic support at no additional cost. Basic support includes access to documentation, community support, and the ability to create billing and subscription management requests, but it does not include the technical support response times and 24x7 technical access associated with paid plans. Standard support is a paid support plan (along with Developer and Professional Direct). You must explicitly purchase it, and it is billed separately from Azure resource consumption. Therefore, the statement that Standard support is included with an Azure free account is false. Why “Yes” is wrong: “Free account” refers to free credits and limited free services for a period, not bundled paid support tiers.

Correct answer: No. A Premier support plan (now commonly aligned with Microsoft Unified Support in many contexts) is an enterprise support offering purchased via a contractual agreement with Microsoft. While Enterprise Agreements (EA) are a common way large organizations buy Azure and related services, Premier/Unified Support is not strictly limited to customers with an EA. Organizations can obtain enterprise support through various commercial arrangements depending on size, needs, and region, and it is not accurate to say it “can only be purchased” by EA customers. The key exam concept is that enterprise support is a separate, organization-level contract and not inherently tied to a specific Azure subscription billing type. Why “Yes” is wrong: it incorrectly treats EA as a mandatory prerequisite for Premier/Unified Support.

Correct answer: No. Support from MSDN forums (and similar community channels) is not restricted only to companies with a pay-as-you-go subscription. MSDN/Developer community forums are generally open community support resources. They are not an entitlement that depends on the Azure subscription type (Free, Pay-As-You-Go, Visual Studio subscription benefits, CSP, or EA). In AZ-900 terms, community support is available broadly, while Microsoft technical support with guaranteed response times requires a paid support plan (Developer/Standard/Professional Direct) or an enterprise support contract. Subscription billing model does not gate access to community forums. Why “Yes” is wrong: it confuses community support availability with paid Microsoft support entitlements and incorrectly ties it to Pay-As-You-Go.

Correct answer: B (disaster recovery). Azure Site Recovery is designed to provide disaster recovery for virtual machines by replicating them to a secondary location and enabling orchestrated failover/failback. If a primary site or Azure region becomes unavailable, ASR helps restore service by starting replicated VMs in the target location, supporting recovery objectives such as RPO (data loss tolerance) and RTO (time to restore service). Why the other options are wrong: - A (fault tolerance): Fault tolerance typically refers to an architecture that continues operating despite component failures (often within the same region) through redundancy and automatic handling of failures. ASR is about recovering after a major outage, not continuous operation through component failure. - D (high availability): High availability focuses on minimizing downtime for localized failures (e.g., using Availability Zones/sets, load balancing). ASR is cross-site/cross-region recovery, not the primary mechanism for in-region HA. - C (elasticity): Elasticity is the ability to automatically scale resources up/down based on demand (e.g., VM Scale Sets, autoscaling). ASR does not provide scaling.