Microsoft 365 E5 サブスクリプションと Azure サブスクリプションをお持ちの場合、以下の要件を満たす必要があります。
* ユーザーがMicrosoft 365の認証情報を使用してAzure仮想マシンにサインインできることを確認してください。
* 新しい仮想マシンを作成する権限を委任する。
各要件には何を使用すべきでしょうか？回答するには、適切な機能を正しい要件にドラッグしてください。各機能は、1回、複数回、またはまったく使用しない場合があります。コンテンツを表示するには、ペイン間の分割バーをドラッグするか、スクロールする必要がある場合があります。

Explanation:

Comprehensive and Detailed Explanation with all Microsoft SC-300: Identity and Access Administrator documents: = Based on the Microsoft SC-300: Microsoft Identity and Access Administrator official study guide, Exam Ref SC-300 , and Microsoft Learn Identity & Access Management modules, Azure provides several mechanisms to manage identity integration and role delegation between Microsoft 365 and Azure resources.
* Ensure that users can sign in to Azure virtual machines by using their Microsoft 365 credentials: This requirement refers to enabling Azure AD-based authentication for virtual machines. This capability is provided by Azure AD Managed Identities and Azure AD join support for Azure VMs. Managed identities allow Azure resources, such as virtual machines, to authenticate to Azure AD-secured services using Microsoft Entra (Azure AD) credentials, eliminating the need to manage credentials manually. As stated in the Microsoft Identity study guide:
"Azure AD-managed identities provide an automatically managed identity in Azure AD for applications or services to use when connecting to resources secured by Azure AD. This includes support for user sign-in to Azure VMs using Microsoft 365 or Azure AD credentials."
* Delegate the ability to create new virtual machines: To delegate resource creation and management in Azure, Azure role-based access control (Azure RBAC) is used. Azure RBAC enables granular access management for Azure resources by assigning roles such as Virtual Machine Contributor , Owner , or Contributor at different scopes (subscription, resource group, or resource). Microsoft documentation clarifies:
"Azure RBAC allows you to assign roles to users, groups, or service principals, granting permissions to create, modify, or delete Azure resources, including virtual machines."

タスク3
営業・マーケティングアクセスパッケージに、LinkedInアプリケーションをリソースとして追加する必要があります。
解決策は、アクセスパッケージから他のリソースを削除してはなりません。

See the Explanation for the complete step by step solution.
Explanation:
To add the LinkedIn application as a resource to the Sales and Marketing access package without removing any other resources, you can follow these steps:
Sign in to the Microsoft Entra admin center:
Ensure you have the role of Global Administrator or Identity Governance Administrator.
Navigate to Entitlement Management:
Go to Identity governance > Entitlement management > Access packages1.
Select the Sales and Marketing access package:
Find and select the Sales and Marketing access package to modify it.
Add a new resource:
Within the access package details, select Resources.
Click on + Add resource.
Search for and select the LinkedIn application from the list of available resources.
Configure the resource role:
Assign the appropriate role for the LinkedIn application that users in the Sales and Marketing access package will have.
Review and update the access package:
Ensure that the LinkedIn application has been added as a resource.
Confirm that no other resources have been removed from the access package.
Save the changes:
After reviewing, save the changes to the access package.
Communicate the update:
Notify the relevant users about the addition of the LinkedIn application to their access package.
By following these steps, you will successfully add the LinkedIn application to the Sales and Marketing access package without affecting the other resources.

最近発生したセキュリティインシデントの問題を解決する必要があります。
各インシデントに対してどのような設定を行うべきでしょうか？回答するには、適切なポリシータイプを該当する問題にドラッグしてください。各ポリシータイプは、1回、複数回、または全く使用しない場合があります。コンテンツを表示するには、ペイン間の分割バーをドラッグするか、スクロールする必要がある場合があります。
注：正解ごとに1ポイントが加算されます。

Explanation:

According to the Microsoft SC-300: Identity and Access Administrator official study guide and the Microsoft Learn "Implement and manage Azure AD Identity Protection" module, Azure AD Identity Protection detects two primary categories of risks: user risks and sign-in risks.
* User Risk Policy: A user risk represents the probability that a user ' s identity (credentials) has been compromised. Examples of user risk signals include leaked credentials , unusual sign-ins from different geographies , or sign-ins from infected devices . The Exam Ref SC-300 specifically lists "leaked credentials detected on the dark web or other compromised repositories" as the main trigger for a user risk policy. Such a policy can automatically force password change or enforce MFA to remediate the threat.
* Sign-in Risk Policy: A sign-in risk reflects the likelihood that a specific authentication attempt is not performed by the legitimate user. Sign-in risk is based on context, such as sign-ins from suspicious browsers , anonymous IP addresses (like TOR networks) , or impossible travel scenarios . The SC-300 documentation highlights these examples as conditions best handled with a sign-in risk policy, where conditional access can block or require MFA for the risky sign-in attempt.
Therefore:
* Leaked credentials are addressed through a User Risk Policy, since the account itself is compromised.
* Sign-ins from suspicious browsers and access from anonymous IP addresses are handled through Sign- in Risk Policies, as they relate to risky sessions rather than compromised identities.

お客様は、以下の表に示すキーコンテナーを含む Azure サブスクリプションをお持ちです。

このサブスクリプションには、以下の表に示すユーザーが含まれています。

6月1日、Admin4は以下の操作を実行します。
* Key Vault1 から Certificate! という名前の証明書を削除します
* KeyVault2からSecret1という名前のシークレットを削除します
以下の各記述について、正しい場合は「はい」を選択してください。そうでない場合は「いいえ」を選択してください。
注：正解ごとに1ポイントが加算されます。

Explanation:

Azure Key Vault uses soft delete with a configurable retention period (7-90 days). During this window, deleted objects can be recovered, and if purge protection is enabled, they cannot be purged until the retention period expires. The SC-300 materials describe: "Soft-delete retains keys, secrets, and certificates for the configured retention days. When purge protection is enabled, even users with purge permission cannot permanently delete objects before the retention period ends; objects remain recoverable until expiry." The Key Vault RBAC data-plane roles further clarify capabilities. The guide states: "Key Vault Administrator has full data actions, including recover and purge across keys, secrets, and certificates. Key Vault Contributor manages the vault resource and settings but does not have data-plane permissions to read, delete, purge, or recover objects. Certificates Officer can manage and recover certificates but is not granted purge." Applying this:
* Secret1 was deleted on June 1 from KeyVault2 (retention 10 days, purge protection Disabled). If it hasn' t been purged, it is recoverable any time through June 11. Admin1 (Key Vault Administrator) therefore can recover on June 7.
* Certificate1 was deleted on June 1 from KeyVault1 (retention 15 days, purge protection Enabled).
Purge is blocked until June 16 regardless of role. Additionally, Admin2 (Key Vault Contributor) lacks data-plane purge rights. Hence cannot purge on June 12.
* Admin3 (Key Vault Certificates Officer) also lacks purge permission; with purge protection still in effect, cannot purge on June 14.

お客様は、以下の表に示すグループを含む Microsoft 365 E5 サブスクリプションをお持ちです。

あなたはグループのライフサイクルを管理する計画を立てています。
どのグループに有効期限を設定できますか？また、設定できる最短のグループ有効期間はどれくらいですか？回答するには、回答欄で適切なオプションを選択してください。
注：正解ごとに1ポイントが加算されます。

Explanation:

According to the Microsoft SC-300 Study Guide and Microsoft Learn module: "Manage Microsoft 365 group lifecycles" , group expiration policies in Microsoft Entra ID apply only to Microsoft 365 groups (formerly Office 365 groups).
Group expiration is part of lifecycle management for Microsoft 365 services and helps ensure that unused groups are automatically deleted after a defined period unless renewed by the owner.
From the table:
* Group1 (Security) # Cannot be set to expire.
* Group2 (Microsoft 365) # Can be set to expire.
* Group3 (Mail-enabled security) # Cannot be set to expire.
* Group4 (Distribution) # Cannot be set to expire.
Therefore, Group2 only can have an expiration policy applied.
Regarding group lifetime, the Exam Ref SC-300 and Microsoft documentation confirm that the minimum (shortest) group lifetime that can be configured for Microsoft 365 group expiration policies is 30 days.
Microsoft Learn states:
"The group lifetime can be set to 30, 60, 90, 180, or 365 days. The minimum allowed is 30 days." This ensures group owners have sufficient time to renew or manage expiring groups before automatic deletion.