Exam Security-Operations-Engineer Topic 4 Question 27 Discussion
Actual exam question for Google's Security-Operations-Engineer exam
Question #: 27
Topic #: 4
Question #: 27
Topic #: 4
You are helping a new Google Security Operations (SecOps) customer configure access for their SOC team.
The customer's Google SecOps administrators currently have access to the Google SecOps instance. The customer is reporting that the SOC team members are not getting authorized to access the instance, but they are able to authenticate to the third-party identity provider (IdP). How should you fix the issue?
Choose 2 answers
The customer's Google SecOps administrators currently have access to the Google SecOps instance. The customer is reporting that the SOC team members are not getting authorized to access the instance, but they are able to authenticate to the third-party identity provider (IdP). How should you fix the issue?
Choose 2 answers
Suggested Answer: D,E Vote an answer
Comprehensive and Detailed Explanation
This scenario describes a common configuration task where authorization is failing despite successful authentication. The problem stems from the fact that Google SecOps uses a dual-authorization model: one for the main platform (SIEM/Chronicle) and a separate one for the SOAR module. The SOC team needs both.
The prompt states admins already have access, which confirms that prerequisite steps like linking the project (Option A) and configuring Workforce Identity Federation (Option B) are already complete. The problem is specific to the new SOC team's group.
* Fixing Instance Access (Option D):
The error "not getting authorized to access the instance" refers to the primary Google Cloud-level authorization. Access to the Google SecOps application itself is controlled by Google Cloud IAM roles on the linked project.1 The SOC team's group, which is federated from the third-party IdP, is represented as a principalSet in IAM. This principalSet must be granted an IAM role to allow sign-in. The roles/chronicle.
viewer role is the minimum predefined role required to grant this application access.
* Fixing SOAR Access (Option E):
Simply granting the IAM role (Option D) is not enough for the SOC team to perform its job. That role only gets them into the main SIEM interface. The SOAR module (for case management and playbooks) has its own internal role-based access control system. An administrator must also navigate within the SecOps platform to the SOAR Advanced Settings > Users & Groups and grant the SOC team's federated group a SOAR-specific permission, like "Basic" or "Analyst." Both steps are required to fully "fix the issue" and provide the SOC team with functional access to the platform.
Exact Extract from Google Security Operations Documents:
Identity and Access Management: Access to a Google SecOps instance using a third-party IdP relies on Workforce Identity Federation, but authorization is configured in two distinct locations.
* Google Cloud IAM: Authorization to the main SecOps instance (including the SIEM interface) is controlled by Google Cloud IAM.2 The federated identities (groups) from the third-party IdP are mapped to a principalSet. This principalSet must be granted an IAM role on the Google Cloud project linked to the SecOps instance. The roles/chronicle.viewer role is the minimum predefined role required to grant sign-in access.
* Google SecOps SOAR: Authorization for the SOAR module (for case management and playbooks) is managed independently.3 An administrator must navigate to the SOAR Advanced Settings > Users & Groups and assign a SOAR-specific role (e.g., 'Basic' or 'Analyst') to the same federated IdP group.
References:
Google Cloud Documentation: Google Security Operations > Documentation > Onboard > Configure a third-party identity provider Google Cloud Documentation: Google Security Operations > Documentation > SOAR > SOAR Administration > Users and Groups
This scenario describes a common configuration task where authorization is failing despite successful authentication. The problem stems from the fact that Google SecOps uses a dual-authorization model: one for the main platform (SIEM/Chronicle) and a separate one for the SOAR module. The SOC team needs both.
The prompt states admins already have access, which confirms that prerequisite steps like linking the project (Option A) and configuring Workforce Identity Federation (Option B) are already complete. The problem is specific to the new SOC team's group.
* Fixing Instance Access (Option D):
The error "not getting authorized to access the instance" refers to the primary Google Cloud-level authorization. Access to the Google SecOps application itself is controlled by Google Cloud IAM roles on the linked project.1 The SOC team's group, which is federated from the third-party IdP, is represented as a principalSet in IAM. This principalSet must be granted an IAM role to allow sign-in. The roles/chronicle.
viewer role is the minimum predefined role required to grant this application access.
* Fixing SOAR Access (Option E):
Simply granting the IAM role (Option D) is not enough for the SOC team to perform its job. That role only gets them into the main SIEM interface. The SOAR module (for case management and playbooks) has its own internal role-based access control system. An administrator must also navigate within the SecOps platform to the SOAR Advanced Settings > Users & Groups and grant the SOC team's federated group a SOAR-specific permission, like "Basic" or "Analyst." Both steps are required to fully "fix the issue" and provide the SOC team with functional access to the platform.
Exact Extract from Google Security Operations Documents:
Identity and Access Management: Access to a Google SecOps instance using a third-party IdP relies on Workforce Identity Federation, but authorization is configured in two distinct locations.
* Google Cloud IAM: Authorization to the main SecOps instance (including the SIEM interface) is controlled by Google Cloud IAM.2 The federated identities (groups) from the third-party IdP are mapped to a principalSet. This principalSet must be granted an IAM role on the Google Cloud project linked to the SecOps instance. The roles/chronicle.viewer role is the minimum predefined role required to grant sign-in access.
* Google SecOps SOAR: Authorization for the SOAR module (for case management and playbooks) is managed independently.3 An administrator must navigate to the SOAR Advanced Settings > Users & Groups and assign a SOAR-specific role (e.g., 'Basic' or 'Analyst') to the same federated IdP group.
References:
Google Cloud Documentation: Google Security Operations > Documentation > Onboard > Configure a third-party identity provider Google Cloud Documentation: Google Security Operations > Documentation > SOAR > SOAR Administration > Users and Groups
by Anastasia at Apr 07, 2026, 10:04 PM
0
0
0
10
Comments
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Report Comment
Commenting
You can sign-up / login (it's free).