AB-400 Practice Tests - Power Platform Developer Associate

Prévia do material em texto

1 / 14
Exam : AB-400
Title :
https://www.passcert.com/AB-400.html
Power Platform Developer
Associate
2 / 14
1.An integration submits a top-level Create request for a Shipment row in a standard Dataverse table.
Custom code must also update a related Booking row. Both Dataverse changes must commit or roll back
together. A carrier service must be notified only after those changes commit.
Notification can complete later, and carrier failures must not reject shipment creation.
Which implementation should you choose?
A. Use a synchronous PreOperation plug-in to update Booking and a synchronous PostOperation plug-in
to notify the carrier.
B. Use a synchronous PreValidation plug-in to update Booking and an asynchronous PostOperation
plug-in to notify the carrier.
C. Use an asynchronous PostOperation plug-in to update Booking and then notify the carrier.
D. Use a synchronous PreOperation plug-in to update Booking and an asynchronous PostOperation
plug-in to notify the carrier.
Answer: D
Explanation:
A synchronous PreOperation plug-in runs within the Shipment Create transaction, allowing a propagated
exception to roll back both Dataverse changes. An asynchronous PostOperation plug-in runs after the
record operation completes and outside that transaction, placing carrier notification after commit.
Synchronous PostOperation still participates in the transaction: it follows the main operation, not the
transaction's commit.
A - Incorrect: The Booking update has the required transaction boundary, but synchronous
PostOperation still runs inside the Create transaction. The carrier call would occur before commit,
violating the required notification timing.
B - Incorrect: For this top-level request, PreValidation precedes the main transaction, so its Booking
update does not share the required rollback boundary. A nested operation invoked by a transactional
extension can already be in a transaction at PreValidation, but that exception does not apply here.
C - Incorrect: Asynchronous PostOperation runs after Shipment creation completes. A subsequent failure
updating Booking cannot roll back the original Shipment creation, so the two Dataverse changes are not
atomic.
D - Correct: Synchronous PreOperation keeps the Booking update within the original Create transaction.
Asynchronous PostOperation places carrier notification outside that transaction and after successful
completion, satisfying both boundaries.
2.A standard Dataverse Order table has a decimal Amount column. Both the model-driven app and a
Web API integration must receive an error before an Order with a negative Amount is committed.
An active business rule has this configuration:
Scope: All Forms
Condition: AmountDataverse caller and a delegated employee identity as
the Import service's caller.
C. Use a delegated employee identity as the Review app's Dataverse caller and an application user as
the Import service's caller.
D. Use application users as the Dataverse callers for both components.
Answer: C
Explanation:
The caller's relationship to the work determines the identity choice. The Review app performs updates
under the signed-in employee's Dataverse permissions, so delegated user access fits. The Import
service operates independently of employees, so its caller should be an application user associated with
its registered application and assigned appropriate Dataverse security roles. Application-user access for
both components would support the unattended import but would make the Review app's caller the
application user rather than the employee. See [Use OAuth authentication with Microsoft Dataverse]
(https://learn.microsoft.com/en-us/power-apps/developer/data-platform/authenticate-oauth).
A - Incorrect: Delegated employee access fits the Review app. Using it for the Import service would
make the unattended integration depend on an employee identity instead of its own application authority.
B - Incorrect: This reverses the required caller contexts. The Review app needs the employee's identity,
while the Import service needs an identity independent of employees.
C - Correct: Delegated employee access retains the Review app's required user context. An application
user provides the Import service with its own Dataverse identity for unattended operations.
D - Incorrect: Application-user access fits the Import service. Making an application user the Review
app's caller would use that application's Dataverse permissions rather than the signed-in employee's
permissions.
5.An unattended reporting integration uses Microsoft Entra client credentials to read the organization-
owned Shipping Zone table through the production Dataverse Web API.
5 / 14
The request fails with a table-privilege error.
A developer confirms these findings:
- The access token is valid, unexpired, and issued for the production Dataverse environment.
- The application user is active in that environment, and its application ID matches the calling application.
- No security roles are granted to the application user directly or through teams.
Which change addresses the failure?
A. Replace the application's client secret and acquire another Dataverse access token.
B. Assign the production application user a Dataverse security role with Read privilege on the Shipping
Zone table.
C. Grant admin consent for the app registration's delegated Dynamics CRM user_impersonation
permission.
D. Assign the developer's user account a Dataverse security role with Read privilege on the Shipping
Zone table.
Answer: B
Explanation:
The valid token and matching active application user establish the caller's identity in the intended
environment. The failure concerns Dataverse authorization: the application user has no security role
granting the required table Read privilege. Assigning an appropriate Dataverse role addresses that
missing grant. Delegated API consent does not supply the application user's table privileges. Microsoft
documents application-user role assignment separately from application credentials in [Use OAuth
authentication with Microsoft Dataverse] (https://learn.microsoft.com/en-us/power-apps/developer/data-
platform/authenticate-oauth).
A - Incorrect: Replacing credentials addresses a credential problem. The application already obtains a
valid token, and obtaining another token does not add the missing Dataverse privilege.
B - Correct: The application user is the caller, and its effective role grants are empty. Assigning a
Dataverse security role with Read privilege on Shipping Zone supplies the required authorization.
C - Incorrect: The delegated user_impersonation permission concerns access on behalf of a user.
Granting its consent does not assign Dataverse table privileges to this application user.
D - Incorrect: The integration uses application credentials. A role assigned to the developer's user
account does not become a role of the application user.
6.A Dataverse plug-in uses workload identity federation through a Microsoft Entra app named
UploadApp to upload files to Azure Storage. Uploads succeed. A timer-triggered Azure Function will use
a separate managed identity, SyncMI, to read account rows from the same Dataverse environment. No
user signs in for the scheduled job, and the working upload path must remain in place.
Which configuration should you add for the Function's Dataverse access?
A. Create a Dataverse application user for UploadApp and assign it a security role with Read access to
the required account rows.
B. Create a Dataverse application user for SyncMI and assign it a security role with Read access to the
required account rows.
C. Assign SyncMI the Azure Reader role at subscription scope.
D. Configure SyncMI to obtain a Dataverse access token and rely on UploadApp's existing federation for
table access.
Answer: B
6 / 14
Explanation:
The requests cross different resource boundaries. The working federation path supports UploadApp's
outbound calls to Azure Storage. The Function calls Dataverse as SyncMI, so the target environment
needs an application user mapped to SyncMI and a security role granting the required account access.
Mapping that role to UploadApp would authorize a different caller. Azure RBAC and the existing
outbound federation do not supply SyncMI's Dataverse mapping or table privileges.
A - Incorrect: This assigns Dataverse privileges to UploadApp. The Function authenticates as SyncMI, so
an application user mapped to UploadApp does not authorize the Function's requests.
B - Correct: The application user maps the Function's managed identity into the target Dataverse
environment, and its security role grants the required account access. The working outbound upload
configuration remains separate.
C - Incorrect: Azure RBAC at subscription scope is separate from Dataverse table authorization. This
assignment does not establish SyncMI's application-user mapping or Dataverse security role.
D - Incorrect: A Dataverse access token identifies the caller but does not itself grant account access.
UploadApp's outbound federation does not provision or authorize SyncMI in the Dataverse environment.
7.An order solution uses a standard Dataverse table with Discount, a decimal-number column storing a
percentage, and Justification, a text column. Discounts above 15% are permitted only when Justification
is nonblank. For discounts of 15% or less, Justification may be blank. Invalid saves must be rejected with
an error message. Orders are entered through model-driven main forms and an integration that uses the
Dataverse Web API. Both columns appear on the forms.
Which declarative configuration meets the requirement?
A. Create an All Forms-scope business rule that always sets Justification to Business Required.
B. Create an Entity-scope business rule that shows an error when Discount exceeds 15% and
Justification is blank.
C. Create an All Forms-scope business rule that shows an error when Discount exceeds 15% and
Justification is blank.
D. Create an Entity-scope business rule that shows an error whenever Discount exceeds 15%.
Answer: B
Explanation:
The decimal and text columns support business rules, and the requirement is a conditional validation: a
discount above 15% is valid when justification is present. An Entity-scope business rule can detect the
invalid combination and show an error, applying on model-driven forms and the server. All Forms scope
can provide the same validation during form entry, but it does not cover writes submitted through the
Dataverse Web API.
A - Incorrect: Making Justification mandatory for every order rejects permitted orders with discounts of
15% or less and blank justification. All Forms scope also leaves Web API writes outside the rule's scope.
B - Correct: The condition detects preciselythe invalid combination. Entity scope applies the supported
validation to both model-driven forms and server operations.
C - Incorrect: The validation condition is appropriate, but All Forms scope covers model-driven forms
rather than server operations submitted through the Web API.
D - Incorrect: This rule rejects every discount above 15%, including discounts that have justification and
are explicitly permitted.
7 / 14
8.You are assessing additional requirements for an order app that uses standard Dataverse tables and
model-driven main forms. A legacy warehouse maintains stock and reservations in a separate system
and exposes a REST API. No existing integration connects the app to that API. The local columns
referenced below use supported text, currency, or single-select choice types and appear on the main
form.
Which requirement needs an integration extension beyond the app's column configuration and business
rules?
A. Initialize Handling Fee to 0 for a new order.
B. Show Pickup Instructions only when Delivery Method is Pickup.
C. Create a stock reservation in the warehouse and save its returned reservation ID on the order.
D. Require Customer Reference when Order Type is Special.
Answer: C
Explanation:
The warehouse owns the stock and reservation state, so creating a reservation requires invoking an
operation in that external system and using its returned ID. Local column configuration and business
rules cannot perform that REST operation. A custom connector is one supported way to expose the API
to Power Apps or Power Automate. By comparison, default values, conditional visibility, and conditional
requirement levels are supported declarative behaviors for the stated model-driven main form.
A - Incorrect: Initializing a local currency column is a default-value requirement supported by declarative
configuration; it does not require a warehouse operation.
B - Incorrect: A form-scoped business rule can show or hide Pickup Instructions based on the Delivery
Method choice.
C - Correct: The reservation must be created where warehouse stock is maintained. An integration must
execute the external API operation and obtain the reservation ID.
D - Incorrect: Although this condition involves two columns, a form-scoped business rule can set the
Customer Reference requirement level based on Order Type.
9.A standard Dataverse table stores shipment rows. A model-driven app and a Web API integration
submit initial Create requests, each containing weight and service code. An existing short custom
calculation uses these inputs to populate a stored handling charge.
The charge must be present when Dataverse inserts the row, and the calculation must execute within the
transaction that creates it.
Which implementation should you use?
A. Run the calculation in a JavaScript OnSave handler and set the handling charge on the form.
B. Run the calculation in a synchronous Create plug-in at PreValidation and set the incoming handling
charge.
C. Run the calculation in a synchronous Create plug-in at PreOperation and set the incoming handling
charge.
D. Run the calculation in a synchronous Create plug-in at PostOperation and update the handling charge
on the created row.
Answer: C
Explanation:
The calculation must cover both callers, supply the handling charge before insertion, and execute within
the create transaction. A synchronous Create plug-in at PreOperation meets these conditions by
8 / 14
changing incoming values before the main operation. PreValidation also runs before insertion, but an
initial request reaches it before the database transaction. Synchronous PostOperation participates in the
transaction but runs after insertion. Form scripting does not cover direct Web API requests. These stage
boundaries are documented in the [Dataverse event framework] (https://learn.microsoft.com/en-
us/power-apps/developer/data-platform/event-framework).
A - Incorrect: A form OnSave handler can calculate a value for form submissions, but direct Web API
requests bypass it. It also does not execute within the Dataverse create transaction.
B - Incorrect: PreValidation allows incoming values to be processed before insertion, but for the initial
Create requests described, it runs before the database transaction. It fails the transaction requirement.
C - Correct: Synchronous PreOperation runs before the main Create operation and within its database
transaction. Setting the incoming handling charge here supplies the value for insertion for both callers.
D - Incorrect: Synchronous PostOperation runs within the transaction, but the row has already been
inserted. Updating the handling charge then triggers a separate Update event and does not supply the
charge for the original insert.
10.A standard Dataverse Order table is populated by a model-driven app and a Web API integration. A
synchronous PostOperation plug-in on Create calls an external notification API, which usually takes 15
seconds to respond. The notification is needed only for successfully saved orders and may be delivered
later. You need to remove the notification wait from the Create request while covering both callers.
Which change should you make?
A. Move the HTTP notification to a synchronous PreValidation plug-in on Create.
B. Move the notification to an OnSave handler in the model-driven form.
C. Keep synchronous PostOperation and use an asynchronous HTTP call that the plug-in waits for
before returning.
D. Register the notification plug-in on Create in asynchronous PostOperation mode.
Answer: D
Explanation:
The notification may complete after the order is saved, so it belongs in asynchronous PostOperation
processing. That execution mode runs after the record operation completes and outside its transaction,
removing the external API wait from the Create request. Server-side registration covers both the model-
driven app and the Web API integration. Waiting for an asynchronous HTTP call inside a synchronous
step still holds the request open; changing the pipeline stage alone does not remove that wait.
A - Incorrect: A synchronous PreValidation step still runs before the Create request returns. It also sends
the notification before the order's successful save is established.
B - Incorrect: Form logic does not run for the Web API integration, so this move loses required
notification coverage.
C - Incorrect: Using an asynchronous HTTP API does not change the plug-in step's synchronous
execution mode. Waiting for the HTTP call to finish keeps the notification delay in the Create request.
D - Correct: Asynchronous PostOperation runs after the record operation completes and outside its
transaction. It covers Create requests from both callers and allows the notification to finish later.
11.An Order table has two model-driven app forms: Dispatch and Service. Both contain Delivery Method
and Courier Instructions.
On the Dispatch form, Courier Instructions must appear when Delivery Method is Courier and disappear
9 / 14
when it is Collection. Visibility must change during editing, before the user saves the row. On the Service
form, Courier Instructions must remain visible for either delivery method.
This requirement does not change stored values or validation for API and import callers.
Which implementation should you choose for the visibility logic?
A. Use a synchronous Dataverse plug-in registered in PreOperation for the Order table's Update
message.
B. Use a business rule on the Order table with its scope set to the Dispatch form.
C. Use a business rule on the Order table with its scope set to All Forms.
D. Use a Power Automate cloud flow triggered when an Order row is modified.
Answer: B
Explanation:
The requirement concerns field visibility during editing, using values that have not yet been saved. A
business rule scoped to the Dispatch form supports this client interaction and limits it to the intended
form. Scoping the rule to All Forms would also change the Service form. Server processing triggered by
a row update cannot provide the required response to unsavedform edits.
A - Incorrect: PreOperation runs when Dataverse processes an Update request. Running before the
database write does not make a plug-in respond to unsaved field edits or control field visibility on an
open form.
B - Correct: Form-scoped business rules support showing and hiding fields. Selecting the Dispatch form
as the scope provides the requested interaction without changing visibility on the Service form.
C - Incorrect: All Forms scope would apply the visibility behavior to both forms. It meets the interaction
requirement but violates the requirement that Courier Instructions remain visible on the Service form.
D - Incorrect: The row-modification trigger depends on a Dataverse update. It does not respond to
unsaved form edits or directly control the open form's field visibility.
12.A plug-in is registered for Update on a standard Dataverse table with stage PostOperation and
execution mode Asynchronous.
During a test, the caller receives a successful Update response. The plug-in subsequently runs and
throws an unhandled InvalidPluginExecutionException. A later retrieval confirms that the updated value
remains.
No other process changes the row during the test.
Which diagnosis explains why the plug-in failure did not roll back the original Update?
A. The PostOperation stage is outside the original transaction in both synchronous and asynchronous
execution modes.
B. The plug-in participates in the original transaction, but rollback excludes the Update submitted by the
caller.
C. The asynchronous plug-in runs after the Update completes and outside its original transaction.
D. InvalidPluginExecutionException reports a failure but cannot cause rollback in either execution mode.
Answer: C
Explanation:
The successful Update is followed by an asynchronous PostOperation execution. That execution runs
outside the original transaction after the record operation completes, so its exception cannot undo the
committed Update. A synchronous PostOperation step on a standard table participates in the original
transaction, where an exception causes the entire transaction to roll back. The deciding condition is the
10 / 14
asynchronous execution mode, rather than the stage name, the origin of the write, or the exception type.
A - Incorrect: This confuses the stage with its execution mode. Synchronous PostOperation steps on a
standard table participate in the original transaction; asynchronous steps run outside it.
B - Incorrect: Rollback is not restricted by which code submitted a write. An exception within the original
transaction rolls back the entire transaction, including the caller's Update. This asynchronous execution
does not participate in that transaction.
C - Correct: The asynchronous step executes after the record operation completes and outside the
original transaction. Its later failure cannot roll back the committed Update.
D - Incorrect: InvalidPluginExecutionException can cause rollback when thrown within a synchronous
transactional stage. The execution boundary explains the retained value here, rather than a limitation of
this exception type.
13.A company is building an equipment booking application. Booking and Equipment Balance records
must be stored in Dataverse. Confirming a booking creates a Booking row and reduces the available
quantity in the related Equipment Balance row. If either write fails, neither change may remain.
The application also needs relational queries joining bookings, equipment, and customers.
Which table design supports these requirements?
A. Use elastic tables for both Booking and Equipment Balance.
B. Use standard tables for both Booking and Equipment Balance.
C. Use an elastic table for Booking and a standard table for Equipment Balance.
D. Use virtual tables backed by an external SQL database for Booking and Equipment Balance.
Answer: B
Explanation:
Both records must reside in Dataverse, and booking confirmation must support an atomic change across
them. Standard tables support relational modeling and transactions across tables. The confirmation
implementation must use that transactional support; choosing the table type does not make separate
requests atomic. Including an elastic table in either part of this operation fails the multi-record transaction
requirement. [Microsoft Learn: Elastic tables for developers] (https://learn.microsoft.com/en-us/power-
apps/developer/data-platform/elastic-tables)
A - Incorrect: Elastic tables suit high-throughput and bursty workloads, but they do not support multi-
record transactions. Treating every Dataverse table type as having the same transaction capabilities
would leave the booking and balance changes without the required atomicity.
B - Correct: Standard tables provide local Dataverse storage and support relational modeling with
transactional operations across tables. Both writes can therefore participate in the transaction required
by booking confirmation.
C - Incorrect: Putting only the balance in a standard table does not make the entire confirmation atomic.
The booking write still targets an elastic table, whose writes do not participate in multi-record
transactions.
D - Incorrect: Virtual tables expose data held in an external source. Even if the SQL database supports
transactions, this design places the records outside Dataverse storage and fails the stated location
requirement. [Microsoft Learn: Virtual tables] (https://learn.microsoft.com/en-us/power-apps/maker/data-
platform/create-edit-virtual-entities)
14.A Power Platform solution ingests unpredictable bursts of application usage events. The events must
11 / 14
be persisted in Dataverse, and the event store must support automatic horizontal scaling as volume
grows. Events are saved independently and retrieved by identifier. After successfully creating an event,
the ingestion client must immediately be able to read that event.
Separate reporting sessions can tolerate delayed visibility.
Which design is the best fit?
A. Use a standard table and retrieve each event after its create request succeeds.
B. Use an elastic table and carry the create operation's session token into subsequent requests within
the ingestion client's logical session.
C. Use an elastic table and retrieve each event in a new logical session without carrying the create
operation's session token.
D. Use a virtual table backed by an external event store and retrieve each event through the table's data
provider.
Answer: B
Explanation:
Elastic tables fit the required automatic horizontal scaling and burst ingestion. Carrying the session token
returned by a create operation into subsequent requests in the same logical session provides read-your-
writes consistency. Separate reporting sessions may observe changes later, which the scenario permits.
Independent event saves also avoid requiring multi-record transactions, which elastic tables do not
support.
A - Incorrect: Standard tables provide strong consistency, but elastic tables are the documented fit for
horizontal scaling and burst throughput. The independent, identifier-based event operations do not
require the relational joins or multi-record transactions that favor standard storage.
B - Correct: Elastic storage matches the workload, and preserving the create operation's session token
maintains the logical session context needed to read the client's own write immediately.
C - Incorrect: A successful create does not guarantee immediate visibility in a different logical session.
Without carrying the session token, the subsequent read may not return the newly created event.
D - Incorrect: A virtual table exposes externally stored records through a provider without replicating
them into Dataverse storage. This does not meet the requirement to persist the events in Dataverse.
15.You are extending a model-driven app to display a supplier's catalog. Users must browse catalog
records in ordinary Dataverse views and open them in record forms. The supplier remains the system of
record, and catalog rows must not be copied into Dataverse.An available data provider has been
validated for the catalog's schema and required read queries, but it does not support writes. Users
require online, read-only access; Dataverse auditing and offline access are not required.
Which data-access design should you choose?
A. Use a standard Dataverse table populated by catalog synchronization.
B. Use a custom connector that exposes the supplier's catalog query operations.
C. Use a virtual table backed by the validated data provider.
D. Use an elastic table populated by catalog ingestion.
Answer: C
Explanation:
A virtual table presents externally stored rows as Dataverse records and retrieves their data at runtime
without replicating the catalog into Dataverse. The validated provider supports the required reads, and its
lack of write support fits the read-only workload. The absence of auditing and offline requirements also
12 / 14
fits the documented virtual-table restrictions. A custom connector can expose external query operations,
but those operations alone do not expose catalog records through ordinary Dataverse views and forms.
Synchronizing or ingesting rows into local tables would violate the no-copy requirement.
A - Incorrect: A standard table can support ordinary views and forms, but populating it through
synchronization creates a local copy of the catalog. This confuses the required table experience with a
requirement for local storage.
B - Incorrect: A custom connector exposes external API operations. It does not by itself represent the
returned catalog rows as a Dataverse table for ordinary views and record forms. External query access
alone is insufficient here.
C - Correct: The virtual table supplies the required Dataverse table experience while leaving catalog
rows in the external source. The provider's supported reads fit the workload, and unsupported writes,
auditing, and offline access are not required.
D - Incorrect: Elastic tables suit high-volume local storage, but ingesting the catalog still creates a
Dataverse copy. Their scaling capability does not satisfy the requirement to access externally stored
rows without replication.
16.You are extending a Power Automate cloud flow that obtains shipping prices. A courier's public
HTTPS REST API exposes CalculateRate, which accepts a destination, parcel weight and service level
and returns a price and currency as JSON. It exposes no table or record endpoints, and no prebuilt
connector supports the operation. The API supports API-key authentication, the endpoint is reachable
from Power Automate, and the environment's data policy permits the integration.
The flow uses the response for the current order; it does not need to store courier rate data in Dataverse.
Which component best fits this integration requirement?
A. Use a standard Dataverse table for shipping rates.
B. Use a virtual Dataverse table for shipping rates.
C. Use a custom connector for the courier API.
D. Use an elastic Dataverse table for shipping rates.
Answer: C
Explanation:
The flow needs to invoke an external calculation and consume its response. A custom connector can
expose CalculateRate as an action, with a connection supplying API-key authentication. The stated
authentication, network and policy conditions support this approach. The absence of a storage
requirement or external record interface makes a Dataverse table an unsuitable integration surface here.
A - Incorrect: Standard tables provide local relational storage and transactional capabilities. Creating a
table for shipping rates would not itself invoke CalculateRate, and the flow does not require local rate
storage.
B - Incorrect: Virtual tables provide a record-based interface to externally stored data through a suitable
provider. External ownership makes this a plausible alternative, but the courier exposes a calculation
operation rather than rate records to access.
C - Correct: A custom connector wraps the courier's REST API and exposes CalculateRate as an action
that Power Automate can call. No prebuilt connector supports the operation, and the supplied access
conditions permit this integration.
D - Incorrect: Elastic tables support scalable local data storage. Receiving a JSON response does not
establish an elastic-storage requirement, and creating an elastic table would not itself call the courier's
13 / 14
calculation operation.
17.Marta belongs to the Operations business unit. A developer checks her permissions on the standard,
user-or-team-owned Dataverse Inspection table.
Her directly assigned security role grants User-level Read and Write. She also belongs to an owner team
whose security role grants Organization-level Read and no Write privilege.
Inspection row I1 is owned by Marta. I2 is owned by another user in Operations. I3 is owned by a user in
another business unit.
No other access grants or column-security restrictions apply.
Which access does Marta have to these three rows?
A. Read and update I1, I2, and I3.
B. Read I1, I2, and I3; update only I1.
C. Read and update only I1; neither read nor update I2 or I3.
D. Read I1, I2, and I3; update I1 and I2 only.
Answer: B
Explanation:
Dataverse combines privileges from directly assigned roles and team roles. The owner team's
Organization-level Read grant lets Marta read all three Inspection rows. Her User-level Write grant
permits updating the row she owns, but neither role grants Write access to the other two rows. The
team's absence of Write does not remove her directly granted Write privilege.
A - Incorrect: Organization-level Read does not extend the scope of Write. Read and Write privileges are
configured and combined separately.
B - Correct: The team role supplies Read for all three rows, while the direct role supplies Write for I1,
which Marta owns.
C - Incorrect: Considering only Marta's direct role overlooks the Organization-level Read privilege she
receives through the owner team.
D - Incorrect: User-level Write does not grant Write to another user's row merely because that user
belongs to the same business unit.
18.A Dataverse Support owner team owns all Service Request rows and has a security role that lets its
members read and update those rows.
A changing group of specialists must read and update only one selected request during a review. The
request must remain owned by Support, and specialist membership must be managed separately for
each reviewed request.
The specialists already have User-level Read and Write privileges on the Service Request table.
Which design should the developer use for the specialists?
A. Add the specialists to the Support owner team for the duration of the review.
B. Create a review owner team, add the specialists, and assign the selected request to it.
C. Create a review access team, add the specialists, and share the selected request with it for Read and
Write.
D. Create a review access team, add the specialists, and assign the Support security role to it.
Answer: C
Explanation:
The Support owner team must retain ownership, while each specialist group needs shared Read and
14 / 14
Write access to one selected request. An access team supplies that record-specific sharing without
taking ownership or receiving a security role. Adding specialists to Support would expose its other
records, and transferring the selected request to another owner team would violate the ownership
requirement.
A - Incorrect: Support team membership would give specialists access to the team's other requests,
exceeding the selected-request scope and coupling review membership to Support membership.
B - Incorrect: An owner team can own the request, but assigning it to the review team would change
ownership from Support.
C - Correct: Sharing the request with an access team grants the required record access while preserving
Support ownership and separate review membership.
D - Incorrect: Access teams cannot receive security roles. Their members obtain access through records
shared with the team.