AZ-104 practice exam — 592 free practice questions

Member users are internal accounts you credential; guest users are external people invited through Microsoft Entra B2B collaboration who keep their home credentials.

The deciding facts are that she belongs to another organization, already has an identity there, and your team refuses to manage her password. Inviting her as an external user creates a guest object she activates by redeeming the invitation, and she then authenticates against her home tenant. A new member account would put her password in your directory. A service principal is an application identity, not something a person signs in as. Adding an email address to a group fails because a group holds existing directory objects, and she does not have one in your tenant yet.

1. Note that the person is external and already has an identity elsewhere.
2. Note the constraint: your tenant must not issue or reset her password.
3. Map that to a guest created through Invite external user (B2B collaboration).
4. Grant access to the guest (directly or through a group) after the invitation is redeemed.

Exam tip: Outside collaborator with their own account and no password managed by you means a B2B guest invitation, not a member account.

Azure Storage has three SAS types. Account SAS and service SAS are signed with a storage account access key; a user delegation SAS is signed with a user delegation key that a Microsoft Entra security principal requests.

Only the user delegation SAS avoids account keys entirely: the managed identity calls Get User Delegation Key with its Entra token and signs the SAS with the returned key. A service SAS, with or without a stored access policy, and an account SAS are both computed with key1 or key2, so the application would need the key in memory. A stored access policy changes how a service SAS is revoked, not what signs it.

1. Identify the constraint: no workload may read or hold an account key.
2. Recall what signs each SAS type: account and service SAS use an account key.
3. Note that a stored access policy does not change the signing key of a service SAS.
4. Choose the user delegation SAS, which is signed with an Entra-issued user delegation key.

Exam tip: If account keys are off-limits, the only SAS you can issue is a user delegation SAS, signed with an Entra-issued user delegation key.

Bicep is a domain-specific language that transpiles to standard ARM JSON templates. Everything a Bicep file expresses is an ARM template underneath, so the deployment engine and capabilities are identical.

'az bicep build' converts the .bicep source into an ARM template JSON file; that is the core relationship between the two languages. It does not produce executables (Bicep is declarative), it does not generate parameter files (that is 'az bicep generate-params'), and there is no state file because Azure Resource Manager is the source of truth for what exists.

1. Recall that Bicep is an authoring layer over ARM JSON, not a separate engine.
2. Map the command: build goes Bicep to JSON; decompile goes JSON to Bicep; generate-params creates a parameter file.
3. Deploy either the .bicep file directly or the emitted JSON; Resource Manager processes the same ARM JSON either way.

Exam tip: Bicep build emits ARM JSON: same engine, same capabilities, friendlier syntax, no state file.

Azure virtual networks should use RFC 1918 private address space: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Choosing public ranges can break connectivity to real internet endpoints and complicates future peering and hybrid connectivity.

10.20.0.0/16 sits inside 10.0.0.0/8, one of the three RFC 1918 private ranges, so it is a safe, valid VNet address space. The distractors are traps built on off-by-one boundaries: 11.0.0.0/16 is outside 10.0.0.0/8 entirely, 172.32.0.0/16 is just past the end of 172.16.0.0/12 (which stops at 172.31.255.255), and 192.169.0.0/16 is just past 192.168.0.0/16. All three are publicly routable ranges.

1. Memorize the three RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
2. Check whether the candidate range falls entirely inside one of those blocks — pay attention to the exact boundaries (172.16–172.31, not 172.32).
3. Also plan for uniqueness: pick ranges that will not overlap with other VNets or on-premises networks you may later peer or connect to.

Exam tip: Valid private VNet space comes from 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 — watch the exact block boundaries.

Azure Monitor stores two fundamental data types: metrics (lightweight numeric time-series values, collected at regular intervals, near-real-time) and logs (event and trace records with rich properties, queried with KQL in a Log Analytics workspace).

Platform metrics fit every requirement in the scenario: they are collected automatically for all Azure resources with no agent, they are numeric samples suitable for charting an average, and they appear in metrics explorer within minutes. Resource logs need a diagnostic setting and a destination before analysis, the activity log only records control-plane operations (not performance counters), and Application Insights is app telemetry that requires instrumentation and never captures host CPU.

1. Open the virtual machine in the Azure portal and select Metrics under Monitoring.
2. Choose the Percentage CPU metric from the Virtual Machine Host namespace.
3. Set the aggregation to Avg and the time range to the last hour to render the chart.

Exam tip: Platform metrics are agentless, numeric, and near-real-time; logs are event records that need routing and KQL to analyze.