CCNA Secure identity and access Questions

Just-in-time activation is a core PIM capability that lets administrators make eligible roles available for temporary, time-boxed elevation. When a user needs elevated privileges, they activate the role for a specific duration, often with a justification, MFA check, and optional scope constraints. This reduces standing access and implements the principle of least privilege.

A Conditional Access policy with a location condition allows you to define named locations (such as specific countries or IP ranges) and explicitly block sign-ins originating from those locations. The policy is evaluated in real time during authentication, before token issuance, and can also be scoped to all cloud apps and specific users or groups. This directly enforces the requirement to restrict access by geographic location, making it the correct answer.

Sign-in risk policy is a native Microsoft Entra ID Protection capability that automates responses to risky sign-in events. It evaluates real-time and offline risk detections (like impossible travel, anonymous IP addresses, or atypical sign-in behavior) and triggers actions such as requiring multi-factor authentication or blocking access. This policy is part of the risk-based protection model, not a generic access control, and is explicitly distinct from session controls or governance features.

This configuration is correct because it precisely implements the stated requirement: the policy includes every user, explicitly excludes break-glass accounts to preserve emergency access, triggers on the Azure portal cloud app, and uses the Conditions > Locations element to scope MFA to untrusted public networks. By selecting 'Any location' except trusted IPs, the policy will prompt for MFA only when a user signs in from outside the corporate network, avoiding excessive prompts on trusted IP ranges. This matches the directive to require MFA for all users except emergency access accounts from untrusted locations.

Privileged Identity Management (PIM) lets you assign the Security Administrator role as 'eligible' rather than 'active'. The member then activates the role when needed, specifying a business justification and, if configured, obtains approval from designated approvers. This provides just-in-time, time-bound access with full audit logs, satisfying the requirement to assign the role securely and with least privilege.

Self-service password reset (SSPR) is an Azure Active Directory (Entra ID) feature that lets users reset or unlock their own passwords without administrator intervention. When enabled, users must first register authentication methods (e.g., authenticator app, phone, or security questions), which are used to verify identity during the reset flow. Because the goal is explicitly to ensure users can reset their own passwords, SSPR is the correct control—it provides the user-facing, self-directed reset capability that the other options lack.

Self-Service Password Reset requires users to first register authentication methods — such as phone numbers, the Microsoft Authenticator app, or email addresses — so those methods can be challenged during reset. By enabling SSPR and setting the registration campaign to require registration at next sign-in, the directory ensures users are prompted to register before they need a reset, which is the critical success factor for SSPR adoption. This is the correct configuration because an SSPR policy is meaningless if users have no registered methods to verify their identity.

Configuring Privileged Identity Management (PIM) to require approval for role activation enforces just-in-time (JIT) access, a core zero-trust tenet. With PIM, a role is eligible but not active; the user must request activation for a specific time window, and an approver must grant it, which limits standing privileges and reduces the attack surface. This also provides auditing and time-bound access, ensuring that privileged roles are never permanently available and that every activation is specifically authorized. This aligns with 'use least privilege access' and 'verify explicitly' because the approval step adds an explicit verification of requestor legitimacy.

FIDO2 security keys are a natively supported passwordless authentication method in Microsoft Entra ID. They use public-key cryptography via the WebAuthn/CTAP2 protocol, where the private key never leaves the hardware key and the public key is registered with the tenant. Because sign-in requires a user gesture (e.g., PIN or touch) and the key's cryptographic assertion is tied to the specific site, it is phishing-resistant and does not require a password.

Custom roles in Microsoft Entra ID allow you to define granular permissions by selecting specific tasks, such as reading audit logs or resetting passwords, that aren't combined into built-in roles. This lets you craft a role with exactly the permissions needed for a job, eliminating standing overprivileged access. By assigning such custom roles to principals, you implement least privilege at the directory level.

In Privileged Identity Management (PIM) for Microsoft Entra ID roles, role settings configure the activation policy, including whether approval is required, what justification must be submitted, and the maximum duration the role stays active. Requiring users to submit an activation request that must be both justified and approved by designated approvers is the direct control that prevents arbitrary, self-service escalation to a privileged role.

SAML certificates are used to sign the SAML response; the service provider uses the certificate's public key to validate the signature. If the certificate has expired or the configured certificate doesn't match the one trusted by the application, the SP will discard the assertion and deny sign-in. Likewise, a mismatch in the SAML configuration (e.g., Entity ID, Reply URL, or signing algorithm) will cause authentication failures even when the certificate is valid.

Security defaults provide a predefined baseline of security settings that automatically enforce MFA for all users, requiring registration through the Microsoft Authenticator app and blocking legacy authentication protocols. This is a mandatory, tenant-wide enforcement mechanism that is enabled by default for new tenants, making it a direct and comprehensive method to enforce MFA.

Entitlement Management access packages are the correct choice because they are specifically designed to govern end-user access to resources such as groups, applications, and SharePoint sites. These packages bundle resources with configurable policies for request approval, recurring access reviews, expiration, and automatic revocation when the policy ends. This enables self-service access requests while maintaining an auditable lifecycle for both internal and external users.

This is correct because lastSignInDateTime corresponds to the user's last successful interactive sign-in, which occurred on December 1. As of the review date (presumably December 15), that is only 14 days ago—well under the 30-day threshold defined by the policy. Therefore, the user is not inactive, and no further action is required.

Microsoft Entra Privileged Identity Management (PIM) delivers just-in-time privileged access by letting users activate eligible role assignments for a maximum time window, with optional approval workflows, MFA, and business justification. Because activation is time-bound and audited, PIM directly supports a privileged access strategy that requires temporary elevation with oversight.

This correctly blocks legacy authentication protocols because 'Exchange ActiveSync clients' and 'Other clients' represent legacy clients that do not support modern authentication. By targeting all users and cloud apps and blocking these client types, you prevent sign-ins that cannot enforce Windows Hello for Business or FIDO2. This is the recommended approach in Microsoft Entra ID to eliminate legacy authentication.

Microsoft Entra ID P1 or P2 license includes self-service password reset (SSPR) at either tier, so a P1 subscription is the minimum required for this feature. P1 provides full SSPR functionality for cloud-managed users, while P2 layers on advanced capabilities like Identity Protection and Privileged Identity Management that are not prerequisites for password reset. Therefore, stating P1 or P2 is the accurate licensing requirement, as P2 is not necessary.

A device compliance policy in Microsoft Intune defines the rules that an iOS device must satisfy, such as a minimum OS version, a specific model, or jailbreak detection, and then scores the device as compliant or noncompliant on a regular schedule. This compliance state is consumed by Azure AD Conditional Access to allow or block access to Exchange, SharePoint, and other corporate apps. Therefore, it directly ensures that only approved iOS devices can access—because any device that fails the policy is denied at the time of access.

FIDO2 security keys are phishing-resistant because they use public-key cryptography where the private key never leaves the device and authentication is bound to the exact relying party origin. During a phishing attack, the key’s challenge-response only works for the legitimate site’s domain, so the credential cannot be relayed to a malicious impersonator. This eliminates shared secrets and prevents man-in-the-middle relay attacks, making it a strong authenticator for Microsoft Entra ID.

This grant control checks the device compliance status reported by Microsoft Intune/Microsoft Entra ID, ensuring the device meets policies such as OS version, disk encryption, and jailbreak detection. Only devices marked as compliant by Intune are allowed access, which directly enforces the requirement to block non-compliant devices.

Microsoft Entra B2B collaboration lets partner users authenticate with their home tenant credentials, and cross-tenant access policies control inbound access. You can scope access to specific applications and revoke it by changing the policy, without managing the partner's accounts.

Conditional Access policies in report-only mode (also called reporting mode) are evaluated against the conditions and the result is logged in the sign-in logs, but the configured access controls are never applied. As a result, a Block control will not prevent the user from accessing the resource; the policy only emits a 'reportOnly: failure' entry. To enforce the block, the policy state must be set to 'Enabled' (or 'On'), which applies the Block control during authentication. This is the direct reason why the block is not in effect.

This is the correct approach because a non-gallery enterprise application acts as a container for your custom SAML application's service principal and all SSO settings. After adding it, you configure SAML 2.0 by providing the application's identifier and reply URL, uploading or generating a signing certificate, and mapping user attributes to the claims. You then assign users or groups to the enterprise application to validate access, and use the built-in test functionality to confirm the federated sign-in flow works end-to-end.

Entitlement management access packages are the correct identity governance solution because they bundle resources such as applications, groups, and SharePoint sites into packages that users can request. Access package policies can require specified custom approvers, define approval stages, set access durations, and trigger recurring access reviews. This directly satisfies the requirement for user-driven application access requests with custom approvals.

Risk-based Conditional Access policies are a core component of a security baseline because they dynamically evaluate sign-in risk and user risk in real time, enabling automatic remediation actions such as requiring MFA, blocking access, or forcing password change for compromised identities. Unlike static policies, these adapt to evolving threat signals like anonymous IP addresses, impossible travel, or atypical sign-ins, thereby reducing the attack surface without permanently disrupting legitimate users. In a baseline, this should be configured with risk thresholds (e.g., medium or higher for user risk) and paired with registration campaigns for combined security information.

Enabling access reviews in entitlement management configures recurring attestation cycles—in this case quarterly—where access packages are periodically recertified. Assigning the finance team manager as the reviewer gives a business owner the responsibility to approve, deny, or remove access at each cycle. This exactly satisfies the compliance requirement for a periodic review.

Conditional Access can target directory roles, and authentication strengths let you require specific method combinations such as phishing-resistant MFA. This directly enforces the policy for Global Administrators without changing per-user settings or relying on legacy per-user MFA, which cannot distinguish phishing-resistant methods.

Conditional Access policies operate at the authentication plane and allow granular control based on client app, IP, and risk. By targeting 'Other clients' and explicitly selecting 'Block access,' you can deny legacy protocols like POP3, IMAP4, and SMTP AUTH that bypass modern authentication and MFA, effectively closing known attack vectors for password-spraying and credential-stuffing. This is the most direct and policy-driven method to prohibit these insecure sign-ins across all users and apps.

Password hash synchronization (PHS) is the correct option because Entra ID Connect computes a one-way salted SHA256 hash of each on-premises Active Directory password and synchronizes that hash to Azure AD. This synchronized hash enables cloud authentication using the same password while also feeding downstream features such as Identity Protection's leaked credentials detection and Azure AD Password Protection's banned password list. The process is designed to be irreversible; the plaintext password is never transmitted or stored, only the derived hash, which directly fulfills the requirement to synchronize password hashes.

One-time passcode (OTP) is a built-in Microsoft Entra ID authentication method that sends a verification code to a user's verified email or phone number via SMS or email. It requires no additional app installation, hardware token, or certificate infrastructure, making it the simplest way to authenticate a user without a password. The code is time-limited and used once, providing a low-friction option for temporary or initial sign-in scenarios.

Temporary Access Pass is a time-limited, admin-issued passcode that allows a user to sign in and complete first-time onboarding, such as registering phishing-resistant credentials like FIDO2 keys or Microsoft Authenticator. It is a first-class authentication method in Microsoft Entra ID, designed as a secure temporary credential that can be used once or for a short validity window, and it supports both primary and secondary authentication scenarios, including passwordless recovery when a user loses their existing methods.

In PIM, open the role's Activation settings, enable 'Require approval to activate', and specify one or more approvers or an approver group. When an eligible member activates the role, the request is sent to those approvers, who approve or deny via the Microsoft Entra admin center or email notification. The role becomes active only after approval is granted, and you can also require justification as part of the activation request, creating a full audit trail.

This Conditional Access policy is correct because it precisely targets the Salesforce app and all users, then uses the 'Device state' filter to include only 'Unmanaged' devices, excluding managed, compliant, and hybrid-joined devices. The grant control 'Require MFA' forces an MFA challenge on those unmanaged devices, while the session control 'Sign-in frequency - Every time' ensures that even within an existing session, every sign-in to Salesforce is reauthenticated with MFA, closing the gap for stolen tokens or stale sessions. This delivers exactly the required behavior: MFA every time on unmanaged devices, without affecting managed ones.

Passwordless authentication using FIDO2 security keys or Windows Hello for Business replaces the password entirely with public/private key cryptography. The private key never leaves the device and is unlocked by a biometric gesture (fingerprint or face) or a PIN, while the public key is registered with Microsoft Entra ID. Because no shared secret is transmitted over the network, these methods are phishing-resistant and eliminate the most common attack vectors like password spraying and credential theft, making this the only option that truly removes passwords.

Password writeback is an optional feature in Microsoft Entra Connect that must be explicitly enabled in the configuration wizard, and it requires Azure AD Premium P1 or P2 licenses to be assigned to users. When enabled, password changes performed in Azure AD (for example, via self-service password reset) are written back to on-premises Active Directory, making the hybrid password bidirectional. This is the only mechanism that fulfills the requirement of writing back passwords from the cloud to on-premises.

Microsoft Entra Conditional Access for Cloud Apps (session control) is an identity-driven, real-time enforcement point that uses a reverse proxy to monitor and restrict user actions inside sanctioned cloud apps. It applies policies at the session layer, allowing you to block download, upload, cut/copy/paste, or print based on user, device, or risk signals—beyond mere sign-in conditions. This is the correct answer because it directly satisfies the requirement to monitor and control behavior in real time within a cloud app session, not just gate initial access.

Create a Conditional Access policy that targets the 'Locations' condition and specifies the relevant countries as Named Locations. When you set the access control to 'Block access', Entra ID checks the sign-in IP address at runtime and denies authentication if it maps to a blocked country. This policy must be assigned to the appropriate users and apps, and should exclude emergency access accounts to avoid tenant lockout.

The custom role's 'Actions' list includes only control-plane operations such as Microsoft.Storage/storageAccounts/read, which govern resource management actions but not blob reads. Reading blob data is a data-plane operation and must be granted via the 'dataActions' property, for example Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. Because no dataActions exist in the role definition, the analyst is denied blob read access despite having a valid role assignment.

Conditions define the specific circumstances under which the policy is evaluated, including sign-in risk (from Identity Protection), device state (compliant or hybrid joined), and location (named locations or countries). These conditions act as the 'when' of the policy, allowing the same user assignment to trigger different access requirements based on context. This is one of the three core components of a Conditional Access policy, distinct from Assignments and Access controls.

Creating a Conditional Access policy that targets privileged roles and requires MFA forces administrators to prove possession of a second authentication factor before signing in to Azure AD, the Azure portal, or Microsoft 365 admin centers. This neutralizes the risk of credential theft and password reuse because even a stolen password is insufficient alone to access high-impact administrative actions. Microsoft recommends this as a baseline control for every privileged account.

This solution correctly blocks legacy authentication as a client-app condition in Conditional Access, ensuring that protocols like POP, IMAP, and SMTP cannot bypass modern security controls. MFA is required only for non-corporate-network access by excluding trusted named locations, which minimizes user friction for internal employees. PIM with approval grants time-bound admin roles and enforces an approval workflow, while Identity Protection with automatic remediation (e.g., requiring a password change for risky users) closes the gap for identity-based threats, fully satisfying all requirements.

Certificate-based authentication (CBA) leverages X.509 digital certificates issued by a trusted certification authority to verify a user's identity. In Microsoft Entra ID, this method is supported for federated domains, where the certificate is used to authenticate against the identity provider instead of a password. It offers strong, phishing-resistant protection and is distinct from the physical smart card interaction, which is not natively supported.

Microsoft Defender for Cloud is the correct choice because it directly provides just-in-time (JIT) VM access, a feature that locks down inbound traffic to virtual machines and opens designated ports only when requested and approved. This integration sends activity data to Microsoft Sentinel for advanced threat detection and response, making it the service that operationalizes JIT for security operations.

Configuring role settings is a required step because these settings define the operational parameters of JIT activation, such as the maximum activation duration (e.g., 1 hour), whether approval is required, and whether justification and ticket information are mandatory. Without these settings, PIM cannot enforce time-bound activation or control the approval workflow, so the JIT strategy would lack governance. You must explicitly configure the settings for each role that you plan to manage with PIM.

Security Administrator is a built-in Microsoft Entra ID role that grants permission to read security information, manage security policies, and act on security alerts and incidents in Microsoft 365 Defender, Defender for Cloud, and Identity Protection. It includes important actions such as managing conditional access policies, resetting passwords, and updating MFA settings, making it an appropriate role for incident response without granting full tenant-wide control. Because it supports day-to-day security administration and remediation, it is one of the roles that can be correctly assigned to a user.

Identity Protection in Microsoft Entra ID aggregates machine-learning-based risk detections, including leaked credentials, impossible travel, anonymous IP addresses, and unfamiliar sign-in properties, into user-risk and sign-in-risk levels. You can configure risk-based Conditional Access policies to automatically require MFA or a secure password reset when risk thresholds are exceeded, providing both detection and auto-remediation. This is the service designed specifically to identify and act on identity risks.

Using a Conditional Access policy that explicitly targets the SaaS application and applies it to 'Guest or external users' scopes both the identity and the resource. Under Target resources you select the specific app, and under Users a particular external user type such as 'B2B collaboration guest' is chosen, allowing the policy to enforce conditions like MFA or session controls. This is the correct pattern because it enforces access decisions at the app boundary for exactly the intended account type without affecting internal users or other applications.

Grant controls define what the policy enforces. With an empty grantControls section, no access requirement such as require multifactor authentication is applied, so the policy evaluates as satisfied and users reach Office 365 without completing MFA.

This is a valid user-and-group assignment in a Conditional Access policy. Selecting All users scopes the policy to every account in the tenant, while the Exclude tab lets you remove specific security groups such as break-glass emergency access accounts. This is the standard way to blanket-apply a policy while preserving administrative exceptions.

A Conditional Access policy can be configured with the 'Client apps' condition to specifically block legacy authentication (e.g., basic auth over POP, IMAP, SMTP, or Exchange ActiveSync) while allowing modern OAuth 2.0 and OpenID Connect-based client flows. This provides granular control, so you can set exclusions for service accounts or privileged users and combine with session controls like MFA or sign-in frequency. This is the only option that selectively targets the authentication protocol itself without altering the modern authentication experience.

A Conditional Access policy evaluates device state at sign-in, and requiring the device be marked compliant enforces that only Intune-managed, policy-compliant devices reach the sensitive data. This directly satisfies the stem's constraint of blocking access from unmanaged devices.

Certificates rely on a public/private key pair: Azure AD stores and validates only the public key, while the private X.509 key stays protected in a certificate store or hardware security module. This removes shared client secrets from source code and configuration, and certificate expiry and rollover can be automated. Because a client secret is simply a string that can be copied or leaked, certificate-bound credentials provide substantially stronger authentication assurance for service principals.

Create a Conditional Access policy that targets the Office 365 cloud app, sets the location condition to include an untrusted named location or exclude trusted corporate IP ranges, and grants access only when MFA is satisfied. Because the scope is limited to the Office 365 application and an external location condition, internal users on the corporate trusted network are not subjected to MFA prompts, while external accesses to Exchange Online, SharePoint Online, and Teams are challenged. This is the least-privilege approach that precisely matches the stated requirement.

This ensures the manager must approve within the activation window, or the request expires.

Configuring the app to accept tokens from partner tenants as external identity providers is the core of Azure AD B2B collaboration. You register the app as a multi-tenant application or add partner tenants as trusted identity providers; users authenticate in their home tenant and receive tokens that your app validates. This allows you to grant specific partner users access while keeping your own tenant as the authority for the application.

This is correct because in Azure AD Conditional Access, the sign-in frequency session control is configured to require the user to reauthenticate after a specified time period, here 1 hour. When that interval elapses, Azure AD forces a fresh authentication prompt even if the user's browser session and tokens are still technically valid, so the user experiences a sign-in interruption. The setting is evaluated independently of the underlying session, which explains why the user is prompted again exactly after 1 hour.

Conditional access evaluates the device used at sign-in, so a compliant device does not help when the user authenticates from an unenrolled one. Requiring sign-in only from compliant devices blocks that access, satisfying the policy's device-compliance constraint.

A Conditional Access policy that requires a device to be marked as compliant works directly with Microsoft Intune's compliance policies. When a device fails to meet compliance rules (e.g., PIN required, OS version, threat level), Intune marks it as non-compliant, and Conditional Access evaluates this state at sign-in to block access to cloud apps. This is the standard enforcement mechanism for Intune-managed devices.

Conditional access evaluates include and exclude scopes, with exclusions taking precedence. Selecting 'All cloud apps' as the include and excluding 'Microsoft Entra ID Administration' satisfies the requirement to block untrusted locations everywhere except administrative access, avoiding the need to enumerate every individual app.

Conditional Access enforces the compliance gate by requiring Intune-marked compliant devices before granting Exchange Online access. Sign-in frequency set to 12 hours forces reauthentication at that interval, satisfying both the device-compliance and periodic-reauthentication constraints in one policy.

This is the correct answer because it layers three complementary controls that directly counter the attacker's tactic. Conditional Access with an authentication strength policy requiring phishing-resistant MFA (such as FIDO2 or Windows Hello) prevents credential theft and token replay that bypass ordinary MFA. The Identity Protection sign-in risk policy blocks sign-ins in real time when the risk level is high, such as those coming from anonymous IP addresses or anomalous locations. Restricting access to the Microsoft Graph API by requiring a specific role assignment ensures that only authorized identities can enumerate directory objects, closing the enumeration vector.

Conditional Access acts as the policy enforcement engine that combines user, device, location, and risk signals to require MFA or block sign-in, while Intune supplies the device compliance and configuration evidence that Conditional Access consumes. Defender for Cloud Apps extends enforcement beyond sign-in by applying session controls to discovered SaaS apps, so a flagged user can be allowed in read-only mode or prevented from uploading sensitive files. This identity-device-app trio verifies trust before access, during a session, and on the data plane, which is exactly the continuous verification model zero trust demands.

Microsoft Entra Privileged Identity Management provides eligible role assignments with approval workflows and time-bound JIT activation, so a manager must approve before the Global Administrator role becomes active. Standard role assignment cannot enforce approval or JIT.

Passwordless methods remove the shared secret from the sign-in process, so there is no password to phish or steal. Requiring FIDO2 or Windows Hello for Business for administrators significantly reduces credential theft risk because the credential is bound to a device and cannot be replayed.

When the output shows UserType 'Member', it means the user account is an internal, home-directory member of the Azure AD tenant. Such users are typically created directly in that tenant or synchronized from on-premises Active Directory via Azure AD Connect, and they belong to the tenant organization rather than being invited from outside. This is precisely the correct interpretation: the command returned a user object whose directory membership type is Member, so the user is a member of the tenant.

Conditional Access App Control, part of Microsoft Defender for Cloud Apps, integrates with Microsoft Entra ID Conditional Access to reroute user sessions through a reverse proxy, enabling real-time monitoring and control. It analyzes signals such as user behavior, device compliance, and location to enforce granular actions like blocking downloads, restricting uploads, or requiring step-up authentication during the session. This precisely matches the requirement for session-level access control based on behavior and device health, making it the correct solution.

Microsoft Purview's unified audit log is the authoritative repository for compliance-related events across Microsoft 365, including Copilot user prompts and responses. When Purview auditing is enabled at the tenant level, the audit engine records Copilot interaction metadata such as the user, timestamp, and action performed, making these records searchable in the Purview compliance portal. This audit trail can also be exported through the Office 365 Management Activity API or integrated with Microsoft Sentinel after the logs have been collected by Purview, but the core requirement is enabling Purview auditing itself.

A named location in Azure AD must exactly match the current public egress IP range of the corporate network. If the range is stale, missing, or mistakenly configured with the wrong CIDR (for example, after an ISP change or a new NAT device), the user's source IP at the office will not match the trusted location. As a result, the Conditional Access policy sees the request as coming from an untrusted network and enforces MFA even though the user is physically inside the office. Verify the public IP and CIDR range in the named location, and confirm that the office's outbound IP has not changed.

A Conditional Access policy with the "Require device to be marked as compliant" condition is the actual enforcement mechanism that blocks or grants access based on the device's current compliance status. When a user attempts to access a cloud app from an untrusted network, the policy combines location and device compliance conditions to deny access if the device is not marked compliant, or grant it if the device is compliant. This policy evaluates the compliance state in real time, using data supplied by Intune, and is the direct control that enforces the requirement.