Which Two Credentials Let App1 Access App2 Across Tenants?
You have an Azure subscription that is linked to a Microsoft Entra tenant. The tenant contains a registered app named App1. You have a partner organization that has a Microsoft Entra tenant. The tenant contains a registered app named App2. You need to ensure that App1 can access App2. Which two types of credentials can App1 use? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.
Community Votes
67% of anonymous learners picked answer AC. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests the credential types of a confidential client doing app-to-app authentication across two Entra tenants, and the trap is reaching for human or resource-bound identity types such as a user account or managed identity that never appear in the client credentials grant.
App1 is an app registration in your Microsoft Entra tenant that must reach App2 in a partner organization's tenant, which requires app-only, cross-tenant authentication through the OAuth 2.0 client credentials flow. This page establishes that the two valid credential types App1 can present are a certificate and a client secret.
The most common wrong pick is a user account (option D) — learners imagine inviting a guest user or signing in as a user in the partner tenant, but an app registration acquired through the client credentials flow cannot authenticate as a human user with a delegated token.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
App1 is a daemon-style app registration in your tenant and App2 is a registered app in the partner tenant, so access happens with no signed-in user: App1 first gets a service principal in the partner tenant (multi-tenant app plus admin consent) and then proves its own identity to the Microsoft identity platform token endpoint. The OAuth 2.0 client credentials grant accepts exactly two credential types for a confidential client, and the options list both of them: a certificate (a public/private key pair, option A) and a client secret (option C). Because the question states that each correct answer presents a complete solution, either credential alone is sufficient — App1 does not need a certificate and a secret, it needs one of the two. This matches the source key (AC) and the dominant community pick.Why the Other Options Are Wrong
A managed identity (B) is bound to an Azure resource inside a single tenant; it has no service principal that the partner tenant can consent to, so it cannot be used to get a token for App2 — it is the right tool for same-tenant Azure resources, not for cross-tenant app access. A user account (D) is a human credential that requires interactive sign-in and yields delegated permissions, which is the wrong flow entirely for an application acting on its own behalf. A one-time password (E) is not a client credential at all; OTP codes are a user authentication factor (MFA), and no app registration can be configured with one as its authentication secret.Community Comment Notes
Shingie answers AC and frames it exactly as the exam expects, describing app-to-app authentication with the OAuth 2.0 client credentials flow and calling out "A. Certificate & C. Secret". The vote split shows the runner-up answer was AD, and armid floated the reasoning behind it — "teachically you could use guest user account, no?" — before abandoning it and posting "correcting to ac". That reversal is a useful reminder that a guest user in the partner tenant can be granted permission to a resource, but it can never serve as the credential type of App1, which is what this question asks for.Official Reference
Exam Strategy
When a scenario pairs two tenants and two registered apps, immediately map it to the client credentials grant and recall that a confidential client gets only two credential types: a client secret and a certificate. Anything describing a human factor (user account, one-time password) or a resource-bound identity (managed identity) is a distractor in this flow.
Frequently Asked Questions
Why can't App1 use a managed identity to access App2 in the partner tenant?
Managed identities are tied to an Azure resource in a single tenant and have no service principal that the partner tenant can consent to, so they cannot obtain a token for App2.
Could a guest user account in the partner tenant let App1 reach App2?
No. A guest user is a human identity used for delegated access; App1 signs in as itself, so it needs a certificate or client secret registered on the app.
Related Analysis
Practice All SC-300 Questions
Access 80 questions with complete answers and detailed explanations.
View Full SC-300 Practice Test →