AZ-104

C is correct, the tags ASSOCIATE the vms to each deparment, then for example it can be charged to each department.

Selected Answer: C
Since all VMs are in the same resource group, only way to distinguish between them is by adding department tags

Selected Answer: C
B is the Correct Option
I’ve tried a few mock test platforms, but Examforsure stood out. Their content is top-notch and very similar to what you see on the actual exam.

Selected Answer: C
Tagging will help associate VMs to the respective departments.

Selected Answer: C
C is the correct Option, the tags ASSOCIATE the vms to each deparment, then for example it can be charged to each department.
I’ve tried a few mock test platforms, but SkillCertExams stood out. Their content is top-notch and very similar to what you see on the actual exam.

Selected Answer: C
Steps to Assign Tags in the Azure Portal:
Navigate to RG1 (Resource Group).

Select the VM you want to tag.

In the VM’s overview, click on Tags.

Add a new tag with:

Name: Department (or another meaningful key).

Value: The department name (e.g., Finance).

Save the changes.

Selected Answer: C
TAGS is the correct answer

Selected Answer: C
could someone lend me a hand a pdf reviewer..

Selected Answer: C
Usually use TAGs for grouping resources in the cloud

Selected Answer: C
To associate each VM with its respective department without moving resources, the best approach is to assign tags.

Your company has serval departments. Each department has a number of virtual machines (VMs).
The company has an Azure subscription that contains a resource group named RG1.
All VMs are located in RG1.
You want to associate each VM with its respective department.
What should you do?

you always run powershell cmdlet 
Start-ADSyncSyncCycle -PolicyType Delta - works just as good- but even faster

Thanks for the answer. I will check from the Microsoft Entra ID connect options

Where is the connectors tab located?
I can't find it here

It's under the Synchronization service manager

Or, you could run 
Start-ADSyncSyncCycle -PolicyType Delta

https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/how-to-connect-sync-feature-scheduler

In this article. It says word for word, "It could be that you have an urgent change that must be synchronized immediately, which is why you need to manually run a cycle.

If you need to manually run a sync cycle, then from PowerShell run Start-ADSyncSyncCycle -PolicyType Delta."
Keywords in this learn.microsoft article are immediately and manually.... If you want it to synchronize immediately, then you'll want to manually run a cycle.... To run a cycle manually, run the -delta command.

Immediate = Manual. Manual = Delta. 

Full sync = Time Consuming. Time Consuming = Initial

Initial is also immediate. Only process time takes longer. The question didn't ask for fastest sync.

the ONLY time you should use PolicyType Initial is when you're running a sync of the entire AADConnect forest. If you want an 'immediate' sync to perform you run PolicyType Delta. Try it for yourself.

Start-ADSyncSyncCycle -PolicyType Delta not Initial

B is correct.
You run the Start-ADSyncSyncCycle -PolicyType Initial PowerShell cmdlet.

Ans: NO

On a server with Azure AD Connect installed, navigate to the Start menu and select AD Connect, then Synchronization Service.

1. Go to CONNECTORS tab.
2. Select RUN on the ACTIONS pane.

Selected Answer: B
Like described already by other people the best way is either a Synchronization being executed through the "Azure AD Connect", in the Portal or using the command "Start-ADSyncSyncCycle -PolicyType Delta".

Selected Answer: B
Below are the possible options for this scenario. Consolidating here for easy read of subscribers.
Solution: You run the Start-ADSyncSyncCycle -PolicyType Initial PowerShell cmdlet. - No
Solution: You use Active Directory Sites and Services to force replication of the Global Catalog on a domain controller. - No
Solution: You restart the NetLogon service on a domain controller. - No
Solution: You run the Start-ADSyncSyncCycle -PolicyType Delta PowerShell cmdlet. - No

Selected Answer: B
The 'Active Directory Sites and Services' will only force the replication to all on-premises sites which do replicate the newly created user account, but not in the correct environment (Azure Active Directory).

Selected Answer: B
Using Active Directory Sites and Services to force replication of the Global Catalog on a domain controller will only ensure that the new user information is replicated across the on-premises Active Directory environment. It does not trigger synchronization to Azure AD. To replicate the user information to Azure AD immediately, you must run the Start-ADSyncSyncCycle PowerShell cmdlet.

Answer: B. No
Explanation:
The proposed solution of using Active Directory Sites and Services to force replication of the Global Catalog on a domain controller does not meet the goal of replicating the new user account information to Azure AD immediately. Azure AD Connect is the tool typically used to synchronize user information between on-premises Active Directory and Azure AD. To achieve immediate replication, you would need to trigger a manual synchronization from the Azure AD Connect server rather than relying on Active Directory Sites and Services.

Selected Answer: B
As explained by ef094b65596c14: 

B. No, the solution does not meet the goal. Using Active Directory Sites and Services to force replication of the Global Catalog on a domain controller will not directly replicate the user information to Azure AD. The appropriate action would be to use Azure AD Connect to manually trigger a delta synchronization cycle.

NO , ON connector servers manually run a sync cycle, then from PowerShell run Start-ADSyncSyncCycle -PolicyType Delta." , DELTA will replicate only changes not full so will be quick

Selected Answer: B
(1) Active Directory Sites & Services inside Windows Server 2022: 
(2) Define “Global Catalog”: https://learn.microsoft.com/en-us/windows/win32/ad/global-catalog 
Azure AD Connect: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/reference-connect-dirsync-deprecated 

Cannot use (1) to force replicate (2). Use Azure AD connect by Command “Start-ADSyncSyncCycle -PolicyType Delta” (See https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/how-to-connect-sync-feature-scheduler#full-sync-cycle ) Or via Azure portal web GUI.

Selected Answer: B
Using Active Directory Sites and Services to force replication of the Global Catalog on a domain controller does not directly impact the synchronization process between the on-premises Active Directory and Azure AD.

To replicate the new user information to Azure AD immediately, you should use Azure AD Connect, the synchronization tool for integrating on-premises Active Directory with Azure AD. Azure AD Connect is responsible for synchronizing changes between the on-premises environment and Azure AD.

B the correct one
The solution mentioned in the scenario, which is using Active Directory Sites and Services to force replication of the Global Catalog on a domain controller, will replicate the user information to other domain controllers in the same site, but it will not replicate the user information to Azure AD immediately. To replicate the user information to Azure AD immediately, you need to manually start a synchronization cycle on the DirSync server or wait for the next scheduled synchronization cycle to occur. Therefore, the solution does not meet the goal of replicating the user information to Azure AD immediately.

B. No

To replicate the new user account information to Azure AD immediately, you should initiate a delta synchronization from the DirSync server (DirSync1) to Azure AD.

Active Directory Sites and Services will update other domain controllers, or you can restore the AD, but you can't replicate to Azure AD with it

DirSync is deprecated based on this document https://learn.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-dirsync-deprecated, this question will probably not showing in the exam

Selected Answer: B
You should run Start-ADSyncSyncCycle -PolicyType Delta

Start-AdSyncSyncCycle -PolicyType Delta works faster than initial. Checking the sync service manager, it takes less than 5 minutes to force sync from local AD to AAD using Delta.

It could be that you have an urgent change that must be synchronized immediately, which is why you need to manually run a cycle.

If you need to manually run a sync cycle, then from PowerShell run Start-ADSyncSyncCycle -PolicyType Delta.

Ans : B
AD Connect > Sychronization service > Connectors >Run on the actions pane

Note: The question is included in a number of questions that depicts the identical set-up. However, every question has a distinctive result. Establish if the solution satisfies the requirements.
Your company has an Azure Active Directory (Azure AD) tenant named weyland.com that is configured for hybrid coexistence with the on-premises Active
Directory domain.
You have a server named DirSync1 that is configured as a DirSync server.
You create a new user account in the on-premise Active Directory. You now need to replicate the user information to Azure AD immediately.
Solution: You use Active Directory Sites and Services to force replication of the Global Catalog on a domain controller.
Does the solution meet the goal?

For any immediate sync actions from AADConnect you do NOT run the Policy Type Initial. YOU RUN POLICY TYPE DELTA!!!!!!!!!

As described here:
If you need to manually run a sync cycle, then from PowerShell run Start-ADSyncSyncCycle -PolicyType Delta.

To initiate a full sync cycle, run Start-ADSyncSyncCycle -PolicyType Initial from a PowerShell prompt.

Running a full sync cycle can be very time consuming, so if you need to replicate the user information to Azure AD immediately then run Start-ADSyncSyncCycle -PolicyType Delta.
Answer is B. No

NO

Please dont restart 'Netlogon' ever, in test or production... Rather reboot the whole DC, wich wont help for starting a sync i guess. If it does, its kinda a retarted way to force a sync to start.

Selected Answer: B
Restarting the NetLogon service does not trigger Azure AD synchronization.
The solution fails to meet the requirement of immediate replication to Azure AD.
Key Takeaway:

NetLogon is for on-premises AD operations, not hybrid synchronization.
Always use Azure AD Connect/DirSync commands to force sync to Azure AD.

Selected Answer: B
B is answer.Nice choice

Selected Answer: B
The NetLogon service is capable of handling authentication users in the domain. For the scope of this question, the policy type needs to be changed to 'Delta'.

Answer: No
To replicate the new user information from your on-premises Active Directory to Azure Active Directory (Azure AD) immediately, you should run the following PowerShell command on the DirSync1 server:

powershell:
Start-ADSyncSyncCycle -PolicyType Delta
Here's what it does:

Start-ADSyncSyncCycle: This command starts a synchronization cycle.
-PolicyType Delta: This option triggers a delta sync, which is a quick sync that only replicates changes made since the last sync (such as the creation of the new user account).
This command will ensure that the new user information is replicated to Azure AD without waiting for the next scheduled sync.

Answer: No
Explanation:
Restarting the NetLogon service on a domain controller will not immediately replicate the new user account information to Azure AD. The DirSync server is responsible for synchronizing user information between the on-premises Active Directory domain and Azure AD. To replicate the new user information to Azure AD immediately, you should manually run a synchronization cycle on the DirSync server or force a synchronization using PowerShell commands.

B
To run the manual sync cycle you can use command
Start-ADSyncSyncCycle -PolicyType Delta
To run full initial Sync
Start-ADSyncSyncCycle -PolicyType Initial

Delta synchronization is for routine updates, processing only changes since the last sync, while Initialize synchronization is more resource-intensive and is used for initial setup or major changes.

AD to AAD Directory Synchronization is done through Azure AD Connect.

Netlogon is a Local Security Authority service that runs in the background. It handles domain user login authentication. It maintains a secure channel between this computer and the domain controller for authenticating users and services. If this service is stopped, the computer may not authenticate users and services, and the domain controller cannot register DNS records. If this service is disabled, any services that explicitly depend on it will fail to start.

Selected Answer: B
Cannot use NetLogon service for replicate user information to Azure AD (even not immediately).

Selected Answer: B
[Restarting NetLogon service] is not related to [Active Directory syncing].

Selected Answer: B
run Start-ADSyncSyncCycle -PolicyType Delta

Selected Answer: B
Restarting the NetLogon service on a domain controller will not directly trigger the synchronization process between the on-premises Active Directory and Azure AD.

To replicate the new user information to Azure AD immediately, you should use Azure AD Connect, the synchronization tool for integrating on-premises Active Directory with Azure AD. Azure AD Connect is responsible for synchronizing changes between the on-premises environment and Azure AD.

The solution mentioned in the scenario, which is restarting the NetLogon service on a domain controller, will not replicate the user information to Azure AD immediately. Therefore, the solution does not meet the goal of replicating the user information to Azure AD immediately. The answer is B. No.

Netlogon service has different work. If below mentioned failure occurs then you need to re-start Netlogon.
User logon failures
SID to name translation fails in object picker UIs
RDP connection failures
DNS SRV resource record registration failures
The firewall profile on member servers and workstations fails to select the domain profile

Selected Answer: B
As per the question, new user account should be updated immediately, so Full sync will be time consuming not immediate. So I will go with B.

NetLogon service is the service on the server responsible for domain authentication. You may need to restart the service if people are having issue with domain logins. This has nothing to do with Azure AD synchronization

Selected Answer: B
Netlogon is used for the authentication on Active Directory OnPremise.

Selected Answer: B
From PowerShell you should run Start-ADSyncSyncCycle -PolicyType Delta

NO
you need to manually run a sync cycle on the server where you install your AAD connect, using window PowerShell to run Start-ADSyncSyncCycle -PolicyType Delta.

B. Turning of NetLogOn will prevent the AuthN mechanism to function properly on a server.

Note: The question is included in a number of questions that depicts the identical set-up. However, every question has a distinctive result. Establish if the solution satisfies the requirements.
Your company has an Azure Active Directory (Azure AD) tenant named weyland.com that is configured for hybrid coexistence with the on-premises Active
Directory domain.
You have a server named DirSync1 that is configured as a DirSync server.
You create a new user account in the on-premise Active Directory. You now need to replicate the user information to Azure AD immediately.
Solution: You restart the NetLogon service on a domain controller.
Does the solution meet the goal?

https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy#read-access-to-data-in-the-secondary-region

For those in doubt, here is an exact statement from MS: With an account configured for GRS or GZRS, data in the secondary region isn't directly accessible to users or applications when an outage occurs in the primary region, unless a failover occurs. 
If your applications require high availability, then you can configure your storage account for read access to the secondary region. When you enable read access to the secondary region, then your data is always available to be read from the secondary, including in a situation where the primary region becomes unavailable. Read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS) configurations permit read access to the secondary region.

B
(A: "data will be available to be read-only if Microsoft initiates a failure", so its not RO if its not failed-over)

Geo-redundant storage (GRS)
As I explained above it helps us in replicating our data to another region which is far away hundreds of miles away from the primary region. It provides at least 99.99999999999999% (16 9's) durability of objects over a given year. GRS replicates our data to another region, but data will be available to be read-only if Microsoft initiates a failure from primary to the secondary region.

Read-access geo-redundant storage (RA-GRS)
It is based on the GRS, but it also provides an option to read from the secondary region, regardless of whether Microsoft initiates a failover from the primary to the secondary region.

Answer B.
Read-access geo-redundant storage (RA-GRS)
It is based on the GRS, but it also provides an option to read from the secondary region, regardless of whether Microsoft initiates a failover from the primary to the secondary region.

Selected Answer: C
GRS does not give the option to read from the secondary region, to achieve that RA-GRS is the one

Selected Answer: B
Because it can be stored on a geographically remote node and read from a secondary location

Selected Answer: A
GPt Says 
The correct Azure storage redundancy option that meets the requirements is:

A. Geo-redundant storage (GRS)

Explanation:
Geo-redundant storage (GRS) stores data across two geographic locations (regions), which aligns with your requirement to store data in separate geographic locations.

Selected Answer: A
There is no read-only geo-redundant storage. It's called Read Access, it's a trick question.
A is the correct answer.
B should be correct if it stated the correct name.

Correct answer should be 'B'. GRS (Geo-Redundant Storage): Replicates data to a secondary region (typically hundreds of miles away). If the primary region fails, the data can be restored from the secondary region.
RA-GRS (Read-Access Geo-Redundant Storage): Works like GRS, but with the additional capability that data can be read from the secondary region. This is useful for scenarios where you may want to access your data even if the primary region is down.

Selected Answer: B
In Azure terminology, Read-Access Geo-Redundant Storage (RA-GRS) is sometimes referred to as "Read-Only Geo-Redundant Storage" because:

Secondary Region Access is Read-Only: In RA-GRS, data replicated to the secondary region is accessible but only in read-only mode. This means users cannot modify the data in the secondary location—they can only read it. Write operations are still limited to the primary location.

Distinction from Full Read-Write Access: The term "read-only" emphasizes that while you can access data in the secondary region, it’s not a fully writable, independent copy. Changes must still originate in the primary location, and then they’re asynchronously replicated to the secondary.

Summary:
So, "read-only" simply clarifies that while the secondary location provides access for reading, it’s not intended for active data modification, thus helping maintain data integrity across regions.

Correct Answer: B. Read-Only Geo-Redundant Storage (RA-GRS)

Based on the provided data storage requirements, the recommended Azure storage redundancy option would be:
• A. Geo-redundant storage
Explanation: Geo-redundant storage meets all the specified requirements:
Data is stored on multiple nodes.
Data is stored on nodes in separate geographic locations (Los Angeles and New York in this case).
Data can be read from the secondary location (New York) as well as from the primary location (Los Angeles).

Selected Answer: B
https://learn.microsoft.com/en-us/azure/storage/common/geo-redundant-design

The answer is RA-GRS but in answer option it is said Read-only Geo Redundant Storage, which is not exists.Please confirm if the answere wording is correct , if it is then none of the answer matches the question

B. Read-only geo-redundant storage

This option best meets the requirements because it stores data in a geographically distant location and allows for read access from the secondary location as well as the primary.

Selected Answer: A
it's answer A, for everyone that chose answer B, read carefully it says Read Only geo redundant storage, which doesn't exist, it's called Read Access only geo redundant storage, it's a trick question, and for that reason answer A is correct which is the closest to the requirements

CORRECT ANSWER: B Read-only geo-redundant storage
if you enable read access to the secondary region, your data is always available, even when the primary region is running optimally. For read access to the secondary region, enable read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS).

The Correct answer is not actually provided. 

Correct answer here would be RA-GRS (Read Access Geo-Redundant Storage) Nothing about the description is requesting "read only"

B. RA-GRS 
Because only this replication option provide read access to Secondary Region even when there is no failure in primary region.

In case of GRS, only primary is available until there is no failure

Your conclusion is not correct, as mentioned in other discussions, as there is only read needed for the secondary zone.
So, the correct answer is B.

A. Geo-redundant storage (GRS): This option meets the requirements. It replicates your data to a secondary region, which is at least 400 miles away from the primary location. It provides read access to the data in the secondary region, allowing you to read from both the primary and secondary locations.

B. Read-only geo-redundant storage: While it provides read access to the data in the secondary region, it doesn't meet the requirement of being able to read from both the primary and secondary locations. Therefore, it is not the best fit for the scenario.

C. Zone-redundant storage: This redundancy option is designed to replicate data across multiple availability zones within a region for high availability but does not meet the requirement of separate geographic locations.

D. Locally redundant storage: This option replicates data within the same region but not across separate geographic locations, so it does not meet the requirements.

So, the correct answer is A. Geo-redundant storage (GRS).

Selected Answer: B
Answer B:
Short summary: If your applications require high availability, then you can configure your storage account for read access to the secondary region. When you enable read access to the secondary region, then your data is always available to be read from the secondary, including in a situation where the primary region becomes unavailable. Read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS) configurations permit read access to the secondary region.

Selected Answer: B
Data can be read from the secondary location as well as from the primary location. 

This calls for the RA-GRS

Selected Answer: B
"Data can be read from the secondary location as well as from the primary location."
Passed the exam on 26 July 2023. Scored 870. Similar question came.

Correction on my end, Microsoft docs defines a node as a single replica within a datacenter. RA-GRS is correct, as LRS in the primary region would have three replicas (nodes) within the same datacenter.

This should really be RA-GZRS, as RA-GRS only stores on one node (datacenter) each in both the primary and secondary regions via Locally Redundant Storage (LRS). RA-GZRS would satisfy multiple nodes in the primary region via Zone Redundant Storage (ZRS), and copy to one node in the secondary region via (LRS)

The answer is B, so you can always can read from both locations

he best Azure storage redundancy option for your company is Geo-redundant storage (GRS). GRS replicates your data three times within the primary region, and then synchronously replicates it to a secondary region that is hundreds of miles away. This ensures that your data is always available, even if there is a disaster that affects one region. Additionally, GRS allows you to read from the secondary location as well as from the primary location, which can improve performance for applications that are distributed across multiple regions.

Selected Answer: C
That question is ... just bad. It's missing tons of information about what's actually needed.
I could just pick two zone-redundant storage accounts, one at eacht location, then use an "az copy" script (or whatever tool) to sync data.

Selected Answer: B
B 
as it fulfills all the required
1- Geo-redundant
2- multiple nodes
3- have a secondary storage that can be read from

Based on the requirement of storing data on multiple nodes in separate geographic locations and allowing read access from both locations, the recommended Azure storage redundancy option would be B. Read-only geo-redundant storage (RA-GRS).

RA-GRS asynchronously replicates data to a secondary region and allows read-only access to the secondary region without the need for a failure in the primary region. However, as mentioned earlier, there is a possibility of data loss in case of a disaster in the primary region. So, it is important to consider the RPO when selecting this option.

Read Access Geo Redundant Storage NOT Read 'Only' Geo Redundant Storage

Selected Answer: B
RA-GRS allows Read-Only Access to the secondary region without the need for failure in the primary region.

Selected Answer: B
RA-GRS allows Read-Only Access to the secondary region without the need for failure in the primary region. 
However, because data is replicated asynchronously from the primary to the secondary region, the secondary region is typically behind the primary region in terms of write operations. If a disaster were to strike the primary region, it's likely that some data would be lost. 
The interval between the most recent writes to the primary region and the last write to the secondary region is known as the recovery point objective (RPO). The RPO indicates the point in time to which data can be recovered. The Azure Storage platform typically has an RPO of less than 15 minutes, although there's currently no SLA on how long it takes to replicate data to the secondary region.
And note that Azure Files does not support read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS).

Selected Answer: B
Answer will be RO-GRS because question states that secondary storage should also be available for read access. This is the difference btwn GRS and RO-GRS, GRS Secondary node is available for read access only if primary is failed.

sorry, is not clear for me, so Ready-Only geo-redundant storage correct ?

Selected Answer: B
Geo-redundant storage (GRS)

Selected Answer: B
I believe the right answer is B) " Read-only geo-redundant storage".

In RA-GRS data is stored on multiple Nodes, a copy exists in a different Region, and the "RA-" part assures that data can be read from the secondary region. 

https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy#read-access-to-data-in-the-secondary-region

I looked at microsoft docs and could not find "Read only GRS" but "read access GRS" answer should be "A" https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy.please feel free to correct me

With GRS or GZRS, the data in the secondary region isn't available for read or write access unless there's a failover to the secondary region. For read access to the secondary region, configure your storage account to use read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS).

Selected Answer: B
B is correct answer, cause it's needed to provide a read from secondary region

Selected Answer: B
For read access to the secondary region, must enable RA-GRS.
https://docs.microsoft.com/en-us/azure/storage/common/geo-redundant-design?tabs=current

B the option should be Read Access and not Read-only RAGRS

Selected Answer: B
Read-access geo-redundant storage (RA-GRS)
It is based on the GRS, but it also provides an option to read from the secondary region, regardless of whether Microsoft initiates a failover from the primary to the secondary region.

Ans : B
Regardless of Microsoft initiates failover to secondary region. Hence RA-GRS provides option to read from the secondary

Selected Answer: B
Answer B should be correct

My beef is that there is nothing called (Read-Only Geo-Redundant Storage). It's called RA-GRS, not RO-GRS. I'm going with A on my test today.

Read access to data in the secondary region
Geo-redundant storage (with GRS or GZRS) replicates your data to another physical location in the secondary region to protect against regional outages. However, that data is available to be read only if the customer or Microsoft initiates a failover from the primary to secondary region. When you enable read access to the secondary region, your data is available to be read at all times, including in a situation where the primary region becomes unavailable. For read access to the secondary region, enable read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS).

There is no storage option called read only geo redundant storage, answer should be A, you just enable the Read-access geo-redundant storage (RA-GRS) after you select the GRS option.

This is a trick question.

I thought A, but then the question says at the end "Data can be read from the secondary location as well as from the primary location".

This means the answer is B, because only RA-GRS can do this.

Wrong Answer. availability zones will not provide geo redundancy. You need RA-GRS.

Answer is C
Zone-redundant storage (ZRS) copies your data synchronously across three Azure availability zones in the primary region. For applications requiring high availability, Microsoft recommends using ZRS in the primary region, and also replicating to a secondary region.

With ZRS, your data is still accessible for both read and write operations even if a zone becomes unavailable

https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy

With GRS or GZRS, the data in the secondary region isn't available for read or write access unless there is a failover to the secondary region. For read access to the secondary region, configure your storage account to use read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS). For more information, see Read access to data in the secondary region.

https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy

I think A too. Questions says "Data can be read" it does not say not indicated it must only be read

Its B because only RA-GRS allow read-only even when Primary is alive

A?

Data must be stored on multiple nodes.
Data must be stored on nodes in separate geographic locations.

You don't have any access to the redundant data live/without failover in GRS. 

People need to stop just guessing. Either look it up or lab it.

The question does mention read-only.

Data can be read from the secondary location as well as from the primary location

Answer: B

The question does not mention data should be read-only from the secondary location. Just says you should be able to read from either location. A can also be the answer.

Your company has a Microsoft Azure subscription.
The company has datacenters in Los Angeles and New York.
You are configuring the two datacenters as geo-clustered sites for site resiliency.
You need to recommend an Azure storage redundancy option.
You have the following data storage requirements:
✑ Data must be stored on multiple nodes.
✑ Data must be stored on nodes in separate geographic locations.
✑ Data can be read from the secondary location as well as from the primary location.
Which of the following Azure stored redundancy options should you recommend?

No, accessing the Virtual Machine blade does not provide access to the ARM template used by Jon Ross to deploy the virtual machine and an additional Azure Storage account. The Virtual Machine blade only displays information about the virtual machine itself and its related resources, but not the ARM template used to deploy it.

To review the ARM template used by Jon Ross, you need to access the deployment history of the resource group where the virtual machine and additional storage account were deployed. This will show all deployments made to the resource group, including the ARM template used for the deployment.

Selected Answer: B
Virtual machine blade does not provide details about deployments

Selected Answer: B
Template details can be viewed from deployments blade

Selected Answer: B
To view the ARM template used by Jon Ross, you should:

Navigate to the Resource Group where the VM and storage account were deployed.
Select "Deployments" from the left menu.
Choose the specific deployment (usually listed by timestamp).
From there, you can view the ARM template, parameters, and outputs used in that deployment.

Selected Answer: B
es la B ya que cuando tu creas un ARM template de una VM solo puedes crear dentro todo con respecto a la VM mas no con le storgae account

Export template shows only VM related ARM JSON.

Selected Answer: A
you can access the template through the VM blade. Go to Automation > Export Template. Azure will generate a template representing the current VM Configuration.

All templates in a RG are stored in Deployments within the the resource group level

B. No
Because i need to access the RG Blade for ARM template of VM and Storage

RG level it correct, as it gives complete template information used to deploy (Here, VM+SA)
VM level give only VM level template info.

Selected Answer: B
Not shown here. Need to go to recourse group and the Deployments tab.

But there are 2 different resources here. The Storage Account resource would be missing.

A template can be exported from both Resource or Resource Group. I think a VM is a resource as well.

Selected Answer: B
B is the Answer
You review the ARM template from the Azure Resource Group Deployment, Deployments Tab.

Answer B. You should use Ressource Group blade to export one to all resources inside the resource group.

B.
To review the ARM template, you need to access the deployment history of the resource group where the virtual machine and additional storage account were deployed. You can access the deployment history by navigating to the “Deployments” blade of the resource group in the Azure portal.

Resource Groups > RG > Deployments > JSON

Selected Answer: B
You should use the Resource Group blade

Selected Answer: B
From NOIS B is correct

Selected Answer: B
You should go to Resource Group and then Deployments.

Selected Answer: B
Tracked deployments: In the Azure portal, you can review the deployment history and get information about the template deployment. You can see the template that was deployed, the parameter values passed in, and any output values. Other infrastructure as code services aren't tracked through the portal.

Tracked deployments: In the Azure portal, you can review the deployment history and get information about the template deployment. You can see the template that was deployed, the parameter values passed in, and any output values. Other infrastructure as code services aren't tracked through the portal.

Why are the words used in the questions on here so awkward?

Selected Answer: B
To get a ARM template from deployed resources, one must go to the Resource Group Page and see\export the previously done deployments:

Selected Answer: B
RG Blade contains JSON ARM file, and these contains more than a resource, so all need to be from a RG

Selected Answer: B
u should use resource group blade to see what's deployed in your RG and see JSON file exactly

Answer is No: go to Resource Group Pane -> Deployment -> Check whatever required -> View Template

Selected Answer: B
You can view deployments history on 
- single resource level
- resource group level
- subscription level
- management group level

Selected Answer: B
To export one or more resources from a resource group:
1. Select the resource group that contains the resources you want to export.

2. Select one or more resources by selecting the checkboxes. To select all, select the checkbox on the left of Name. The Export template menu item only becomes enabled after you've selected at least one resource.

3. Select Export template.

here are two ways to export a template:

Export from resource group or resource: This option generates a new template from existing resources. The exported template is a "snapshot" of the current state of the resource group. You can export an entire resource group or specific resources within that resource group.

Save from history: This option retrieves an exact copy of a template used for deployment. You specify the deployment from the deployment history.

Because you want to review the template that Jon used, not export the current configuration of the VM, which will not include the template for the storage, for example, additionally, the VM may have been changed, we don't know.

There is also an "export template" link on VM blade, why cannot we use it?
So the answer should be "Yes"

Note: The question is included in a number of questions that depicts the identical set-up. However, every question has a distinctive result. Establish if the solution satisfies the requirements.
Your company has an azure subscription that includes a storage account, a resource group, a blob container and a file share.
A colleague named Jon Ross makes use of a solitary Azure Resource Manager (ARM) template to deploy a virtual machine and an additional Azure Storage account.
You want to review the ARM template that was used by Jon Ross.
Solution: You access the Virtual Machine blade.
Does the solution meet the goal?

.css-1hohgv6{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;gap:0px;}Exam.css-1cp477w{color:#4285F4;}Prepper

Exam
Prepper