Identifying Service Protection API Limit in Power Automate
A retail company runs a Microsoft Power Automate flow that notifies customers when their orders are shipped. The flow runs under a service account that experienced much higher API transection volumes over the last 12 hours due to a sales promotion. An administrator reports that the flow is often delayed and sometimes fails to send the customer notification. You need to validate the platform limit the flow is encountering. Which platform limit is disrupting the flow?
Community Votes
71% of anonymous learners picked answer E. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Tests the difference between standard API quotas and global service protection mechanisms, with the trap being the assumption that a specific connector limit is the bottleneck.
Distinguish between tenant-level service protection and per-flow API limits when a flow experiences delays during high-volume spikes. This page establishes that the Service Protection API limit is the correct cause for throttling.
Candidates often select Option D (Microsoft Power Automate API Request limit), confusing general licensing-based request caps with the broader tenant-wide protection against excessive load.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The scenario describes a sudden spike in transaction volume due to a sales promotion, resulting in delays and failures across the platform. The Service Protection API limit is a tenant-wide safety mechanism designed to prevent abuse or accidental overload. When this limit is hit, the platform returns a 429 Too Many Requests error, causing flows to pause temporarily before retrying, which matches the reported symptoms of delay and eventual failure.Why the Other Options Are Wrong
Option A and B are incorrect as they do not govern the overall API transaction volume for flows. Option C refers to storage capacity, which would cause errors related to data size, not request frequency. Option D is the most common distractor; while individual connectors have limits, the 'Service Protection' level is specifically triggered by aggregate tenant usage spikes that exceed safe operational thresholds, which fits the 'sales promotion' context better than a static license limit.Community Comment Notes
Community feedback strongly supports Option E, noting that the 'delayed but eventually executed' behavior is characteristic of the 429 retry logic implemented by service protection. One commenter highlighted that this limit acts as a mechanism to pause flows during excessive requests, validating the diagnosis based on the high transaction volumes mentioned.Official Reference
Exam Strategy
When you see keywords like 'high volume spike', 'tenant-wide', or 'service protection', look for the option that addresses global platform health rather than specific user or connector limits.
Frequently Asked Questions
What is the difference between Service Protection and Power Automate API limits?
Service Protection is a tenant-wide safeguard against massive spikes, while Power Automate limits are typically per-connector or per-license quotas.
How does the Service Protection limit affect running flows?
It causes temporary pauses and returns 429 errors, forcing flows to wait before retrying their requests.