Practice Free Professional Cloud Security Engineer Exam Online Questions
Question #81
You are implementing communications restrictions for specific services in your Google Cloud organization. Your data analytics team works in a dedicated folder You need to ensure that access to BigQuery is controlled for that folder and its projects. The data analytics team must be able to control the restrictions only at the folder level
What should you do?
- A . Enforce the Restrict Resource Service Usage organization policy constraint on the folder to restrict BigQuery access. Assign the data analytics team the Organization Policy Administrator role to allow the team to manage exclusions within the folder.
- B . Create a scoped policy on the folder with a service perimeter to restrict BigQuery access. Assign the data analytics team the Access Context Manager Editor role on the scoped policy to allow the team to configure the scoped policy.
- C . Define a hierarchical firewall policy on the folder to deny BigQuery access. Assign the data analytics team the Compute Organization Firewall Policy Admin role to allow the team to configure rules for the firewall policy.
- D . Create an organization-level access policy with a service perimeter to restrict BigQuery access. Assign the data analytics team the Access Context Manager Editor role on the access policy to allow the team to configure the access policy.
Correct Answer: B
B
Explanation:
The requirement is to establish a network security boundary around a specific service (BigQuery) for resources in a Folder, while allowing the team to manage that boundary. This is the definition of using VPC Service Controls (VPC SC) with scoped policies.
VPC Service Controls (VPC SC): Used to create a service perimeter (a security boundary) around BigQuery and other Google Cloud services, which restricts API access.
Scoped Policy on the Folder: This enforces the boundary exactly at the required Folder level, as opposed to the organization level.
Access Context Manager Editor Role: Access Context Manager is the service that manages VPC SC policies (Service Perimeters and Access Levels). Granting this role on the scoped policy allows the data analytics team to fulfill the requirement to "control the restrictions."
Extracts (Conceptual Basis for VPC SC and Scoped Policies):
"Private Service Connect provides… Explicit authorization. Private Service Connect provides an authorization model that gives consumers and producers granular control, ensuring that only the intended service endpoints and no other resources can connect to a service." (Source 2.4 – VPC SC and PSC share a core architectural concept of explicit, service-oriented boundaries)
Option B is the technical implementation that matches the requirements: using a VPC SC service perimeter (for service restriction) applied as a scoped policy on the folder (for resource hierarchy scope) with Access Context Manager Editor (for team management/control).
B
Explanation:
The requirement is to establish a network security boundary around a specific service (BigQuery) for resources in a Folder, while allowing the team to manage that boundary. This is the definition of using VPC Service Controls (VPC SC) with scoped policies.
VPC Service Controls (VPC SC): Used to create a service perimeter (a security boundary) around BigQuery and other Google Cloud services, which restricts API access.
Scoped Policy on the Folder: This enforces the boundary exactly at the required Folder level, as opposed to the organization level.
Access Context Manager Editor Role: Access Context Manager is the service that manages VPC SC policies (Service Perimeters and Access Levels). Granting this role on the scoped policy allows the data analytics team to fulfill the requirement to "control the restrictions."
Extracts (Conceptual Basis for VPC SC and Scoped Policies):
"Private Service Connect provides… Explicit authorization. Private Service Connect provides an authorization model that gives consumers and producers granular control, ensuring that only the intended service endpoints and no other resources can connect to a service." (Source 2.4 – VPC SC and PSC share a core architectural concept of explicit, service-oriented boundaries)
Option B is the technical implementation that matches the requirements: using a VPC SC service perimeter (for service restriction) applied as a scoped policy on the folder (for resource hierarchy scope) with Access Context Manager Editor (for team management/control).
Question #82
You are auditing all your Google Cloud resources in the production project. You want to identity all principals who can change firewall rules.
What should you do?
- A . Use Policy Analyzer lo query the permissions compute, firewalls, create ofcompute, firewalls. Create of compute,firewalls.delete.
- B . Reference the Security Health Analytics – Firewall Vulnerability Findings in the Security Command Center.
- C . Use Policy Analyzer to query the permissions compute, firewalls, get of compute, firewalls, list.
- D . Use Firewall Insights to understand your firewall rules usage patterns.
Correct Answer: A
A
Explanation:
To identify all principals who can change firewall rules, you need to determine which users or service accounts have permissions that allow them to modify firewall rules in your Google Cloud project. The correct permissions to check for this are compute.firewalls.create and compute.firewalls.delete.
These permissions enable a user to create and delete firewall rules, respectively.
The Policy Analyzer tool in Google Cloud allows you to query and analyze IAM policies to identify which principals have specific permissions. By using Policy Analyzer, you can effectively identify all principals with the compute.firewalls.create and compute.firewalls.delete permissions.
Open Policy Analyzer: Go to the Google Cloud Console, navigate to IAM & Admin, and select Policy Analyzer.
Set Up Query: Create a new query specifying the permissions compute.firewalls.create and compute.firewalls.delete.
Run Query: Execute the query to retrieve a list of principals who have these permissions.
Review Results: Analyze the results to identify all users and service accounts with the capability to modify firewall rules.
This method ensures you have a comprehensive list of all principals who can change firewall rules, enhancing your audit and security posture.
Google Cloud Policy Analyzer Documentation
Google Cloud IAM Documentation
A
Explanation:
To identify all principals who can change firewall rules, you need to determine which users or service accounts have permissions that allow them to modify firewall rules in your Google Cloud project. The correct permissions to check for this are compute.firewalls.create and compute.firewalls.delete.
These permissions enable a user to create and delete firewall rules, respectively.
The Policy Analyzer tool in Google Cloud allows you to query and analyze IAM policies to identify which principals have specific permissions. By using Policy Analyzer, you can effectively identify all principals with the compute.firewalls.create and compute.firewalls.delete permissions.
Open Policy Analyzer: Go to the Google Cloud Console, navigate to IAM & Admin, and select Policy Analyzer.
Set Up Query: Create a new query specifying the permissions compute.firewalls.create and compute.firewalls.delete.
Run Query: Execute the query to retrieve a list of principals who have these permissions.
Review Results: Analyze the results to identify all users and service accounts with the capability to modify firewall rules.
This method ensures you have a comprehensive list of all principals who can change firewall rules, enhancing your audit and security posture.
Google Cloud Policy Analyzer Documentation
Google Cloud IAM Documentation
Question #83
Your DevOps team uses Packer to build Compute Engine images by using this process:
1 Create an ephemeral Compute Engine VM.
2 Copy a binary from a Cloud Storage bucket to the VM’s file system.
3 Update the VM’s package manager.
4 Install external packages from the internet onto the VM.
Your security team just enabled the organizational policy. consrraints/compure.vnExtemallpAccess. to restrict the usage of public IP Addresses on VMs. In response your DevOps team updated their scripts to remove public IP addresses on the Compute Engine VMs however the build pipeline is failing due to connectivity issues.
What should you do? Choose 2 answers
- A . Provision a Cloud NAT instance in the same VPC and region as the Compute Engine VM
- B . Provision an HTTP load balancer with the VM in an unmanaged instance group to allow inbound connections from the internet to your VM.
- C . Update the VPC routes to allow traffic to and from the internet.
- D . Provision a Cloud VPN tunnel in the same VPC and region as the Compute Engine VM.
- E . Enable Private Google Access on the subnet that the Compute Engine VM is deployed within.
Correct Answer: A,E
A,E
Explanation:
Provision a Cloud NAT Instance:
Cloud NAT (Network Address Translation) allows instances without external IP addresses to access the internet securely.
In the Google Cloud Console, navigate to the VPC Network section and select Cloud NAT.
Create a new Cloud NAT configuration, specifying the VPC and region where your Compute Engine VMs are deployed.
Configure Cloud NAT:
Ensure that the Cloud NAT instance is configured to provide outbound internet connectivity for the VMs in your specified subnet.
This setup allows the VMs to access the internet for package updates and external installations without requiring public IP addresses.
Enable Private Google Access:
Private Google Access allows VMs in a subnet to reach Google APIs and services using internal IP addresses.
In the Google Cloud Console, navigate to the VPC Network section and select Subnets.
Edit the subnet used by your Compute Engine VMs and enable Private Google Access.
Update DevOps Scripts:
Ensure that your DevOps scripts are updated to work with the new network configuration.
Test the build process to confirm that the VMs can access necessary resources and complete the build pipeline successfully.
Reference: Cloud NAT Documentation
Private Google Access
A,E
Explanation:
Provision a Cloud NAT Instance:
Cloud NAT (Network Address Translation) allows instances without external IP addresses to access the internet securely.
In the Google Cloud Console, navigate to the VPC Network section and select Cloud NAT.
Create a new Cloud NAT configuration, specifying the VPC and region where your Compute Engine VMs are deployed.
Configure Cloud NAT:
Ensure that the Cloud NAT instance is configured to provide outbound internet connectivity for the VMs in your specified subnet.
This setup allows the VMs to access the internet for package updates and external installations without requiring public IP addresses.
Enable Private Google Access:
Private Google Access allows VMs in a subnet to reach Google APIs and services using internal IP addresses.
In the Google Cloud Console, navigate to the VPC Network section and select Subnets.
Edit the subnet used by your Compute Engine VMs and enable Private Google Access.
Update DevOps Scripts:
Ensure that your DevOps scripts are updated to work with the new network configuration.
Test the build process to confirm that the VMs can access necessary resources and complete the build pipeline successfully.
Reference: Cloud NAT Documentation
Private Google Access
Question #84
A security audit uncovered several inconsistencies in your project’s Identity and Access Management (IAM) configuration. Some service accounts have overly permissive roles, and a few external collaborators have more access than necessary. You need to gain detailed visibility into changes to IAM policies, user activity, service account behavior, and access to sensitive projects.
What should you do?
- A . Deploy the OS Config Management agent to your VMs. Use OS Config Management to create patch management jobs and monitor system modifications.
- B . Enable the metrics explorer in Cloud Monitoring to follow the service account authentication events and build alerts linked on it.
- C . Use Cloud Audit Logs. Create log export sinks to send these logs to a security information and event management (SIEM) solution for correlation with other event sources.
- D . Configure Google Cloud Functions to be triggered by changes to IAM policies. Analyze changes by using the policy simulator, send alerts upon risky modifications, and store event details.
Correct Answer: C
C
Explanation:
The problem requires gaining "detailed visibility into changes to IAM policies, user activity, service account behavior, and access to sensitive projects" due to security inconsistencies.
Cloud Audit Logs: Cloud Audit Logs records administrative activities, data access, and system events across Google Cloud. These logs are the primary source of truth for tracking "who did what, where,
and when" in your Google Cloud environment.
Extract
Reference: "Cloud Audit Logs maintains the following audit logs for each project, folder, and
organization: Admin Activity audit logs, Data Access audit logs, System Event audit logs, Policy Denied audit logs."
Extract
Reference: "Admin Activity audit logs contain log entries for API calls or other actions that modify the configuration or metadata of resources. Data Access audit logs record API calls that read the configuration or metadata of resources, as well as user-provided data." (Google Cloud Documentation: "Cloud Audit Logs overview" – https://cloud.google.com/logging/docs/audit)
These logs directly capture:Changes to IAM policies: Recorded in Admin Activity logs.
User activity: Recorded in Admin Activity and Data Access logs.
Service account behavior: Actions performed by service accounts are logged in the same way as user actions.
Access to sensitive projects: Data Access logs, especially for sensitive data services, record access events.
Log Export Sinks: To gain "detailed visibility" and enable "correlation with other event sources," these audit logs should be exported to a centralized Security Information and Event Management (SIEM) solution. Log sinks allow you to route logs from Cloud Logging to various destinations, including BigQuery, Cloud Storage, or Pub/Sub (which can then feed into a SIEM).
Extract
Reference: "You can use sinks to route some or all of your logs to supported destinations." and "Many security information and event management (SIEM) systems can ingest logs through Cloud Pub/Sub." (Google Cloud Documentation: "Routing and storage overview | Cloud Logging" – https://cloud.google.com/logging/docs/routing-overview)
Let’s evaluate the other options:
C
Explanation:
The problem requires gaining "detailed visibility into changes to IAM policies, user activity, service account behavior, and access to sensitive projects" due to security inconsistencies.
Cloud Audit Logs: Cloud Audit Logs records administrative activities, data access, and system events across Google Cloud. These logs are the primary source of truth for tracking "who did what, where,
and when" in your Google Cloud environment.
Extract
Reference: "Cloud Audit Logs maintains the following audit logs for each project, folder, and
organization: Admin Activity audit logs, Data Access audit logs, System Event audit logs, Policy Denied audit logs."
Extract
Reference: "Admin Activity audit logs contain log entries for API calls or other actions that modify the configuration or metadata of resources. Data Access audit logs record API calls that read the configuration or metadata of resources, as well as user-provided data." (Google Cloud Documentation: "Cloud Audit Logs overview" – https://cloud.google.com/logging/docs/audit)
These logs directly capture:Changes to IAM policies: Recorded in Admin Activity logs.
User activity: Recorded in Admin Activity and Data Access logs.
Service account behavior: Actions performed by service accounts are logged in the same way as user actions.
Access to sensitive projects: Data Access logs, especially for sensitive data services, record access events.
Log Export Sinks: To gain "detailed visibility" and enable "correlation with other event sources," these audit logs should be exported to a centralized Security Information and Event Management (SIEM) solution. Log sinks allow you to route logs from Cloud Logging to various destinations, including BigQuery, Cloud Storage, or Pub/Sub (which can then feed into a SIEM).
Extract
Reference: "You can use sinks to route some or all of your logs to supported destinations." and "Many security information and event management (SIEM) systems can ingest logs through Cloud Pub/Sub." (Google Cloud Documentation: "Routing and storage overview | Cloud Logging" – https://cloud.google.com/logging/docs/routing-overview)
Let’s evaluate the other options:
Question #85
A customer deploys an application to App Engine and needs to check for Open Web Application Security Project (OWASP) vulnerabilities.
Which service should be used to accomplish this?
- A . Cloud Armor
- B . Google Cloud Audit Logs
- C . Cloud Security Scanner
- D . Forseti Security
Correct Answer: C
C
Explanation:
Reference: https://cloud.google.com/security-scanner/
Web Security Scanner supports categories in the OWASP Top Ten, a document that ranks and provides remediation guidance for the top 10 most critical web application security risks, as determined by the Open Web Application Security Project (OWASP). https://cloud.google.com/security-command-center/docs/concepts-web-security-scanner-overview#detectors_and_compliance
C
Explanation:
Reference: https://cloud.google.com/security-scanner/
Web Security Scanner supports categories in the OWASP Top Ten, a document that ranks and provides remediation guidance for the top 10 most critical web application security risks, as determined by the Open Web Application Security Project (OWASP). https://cloud.google.com/security-command-center/docs/concepts-web-security-scanner-overview#detectors_and_compliance
Question #86
Your Security team believes that a former employee of your company gained unauthorized access to Google Cloud resources some time in the past 2 months by using a service account key. You need to confirm the unauthorized access and determine the user activity.
What should you do?
- A . Use Security Health Analytics to determine user activity.
- B . Use the Cloud Monitoring console to filter audit logs by user.
- C . Use the Cloud Data Loss Prevention API to query logs in Cloud Storage.
- D . Use the Logs Explorer to search for user activity.
Correct Answer: D
D
Explanation:
Objective: Ensure that a Cloud Storage bucket in Project A can only be readable from Project B and prevent data access or copying to Cloud Storage buckets outside the network, even with correct credentials.
Solution: Use VPC Service Controls to create a security perimeter.
Steps:
Step 1: Open the Google Cloud Console.
Step 2: Navigate to the VPC Service Controls page.
Step 3: Create a new service perimeter.
Step 4: Add Project A and Project B to the service perimeter.
Step 5: Include Cloud Storage service in the perimeter configuration.
Step 6: Define access levels to ensure that only resources within the perimeter can access the Cloud Storage bucket.
By setting up a VPC Service Controls perimeter, you can enforce security boundaries that restrict data access and movement to within defined projects, providing an extra layer of protection beyond IAM permissions.
Reference: VPC Service Controls Overview
Configuring VPC Service Controls
D
Explanation:
Objective: Ensure that a Cloud Storage bucket in Project A can only be readable from Project B and prevent data access or copying to Cloud Storage buckets outside the network, even with correct credentials.
Solution: Use VPC Service Controls to create a security perimeter.
Steps:
Step 1: Open the Google Cloud Console.
Step 2: Navigate to the VPC Service Controls page.
Step 3: Create a new service perimeter.
Step 4: Add Project A and Project B to the service perimeter.
Step 5: Include Cloud Storage service in the perimeter configuration.
Step 6: Define access levels to ensure that only resources within the perimeter can access the Cloud Storage bucket.
By setting up a VPC Service Controls perimeter, you can enforce security boundaries that restrict data access and movement to within defined projects, providing an extra layer of protection beyond IAM permissions.
Reference: VPC Service Controls Overview
Configuring VPC Service Controls
Question #87
Your organization uses Google Workspace Enterprise Edition tor authentication. You are concerned about employees leaving their laptops unattended for extended periods of time after authenticating into Google Cloud. You must prevent malicious people from using an employee’s unattended laptop to modify their environment.
What should you do?
- A . Create a policy that requires employees to not leave their sessions open for long durations.
- B . Review and disable unnecessary Google Cloud APIs.
- C . Require strong passwords and 2SV through a security token or Google authenticate.
- D . Set the session length timeout for Google Cloud services to a shorter duration.
Correct Answer: D
D
Explanation:
Access Google Cloud Console:
Log in to the Google Cloud Console with administrative privileges. Navigate to the "IAM & Admin" section. Set Session Length Timeout:
Go to the "Settings" page within IAM & Admin.
Locate the "Session control" settings.
Configure the session length timeout to a shorter duration, such as 15 or 30 minutes. This ensures that user sessions expire automatically after the specified time of inactivity.
Apply and Enforce the Policy:
Save the changes and ensure the new session timeout policy is applied across all users and services.
Communicate the new policy to employees, highlighting the importance of session security and the rationale behind the change.
Additional Security Measures:
Consider implementing additional measures such as automatic screen locks and secure session management practices.
Educate employees on the importance of logging out of their sessions and securing their devices when not in use.
Reference: Google Cloud IAM Documentation
Session Management Best Practices
D
Explanation:
Access Google Cloud Console:
Log in to the Google Cloud Console with administrative privileges. Navigate to the "IAM & Admin" section. Set Session Length Timeout:
Go to the "Settings" page within IAM & Admin.
Locate the "Session control" settings.
Configure the session length timeout to a shorter duration, such as 15 or 30 minutes. This ensures that user sessions expire automatically after the specified time of inactivity.
Apply and Enforce the Policy:
Save the changes and ensure the new session timeout policy is applied across all users and services.
Communicate the new policy to employees, highlighting the importance of session security and the rationale behind the change.
Additional Security Measures:
Consider implementing additional measures such as automatic screen locks and secure session management practices.
Educate employees on the importance of logging out of their sessions and securing their devices when not in use.
Reference: Google Cloud IAM Documentation
Session Management Best Practices
Question #88
Your organization is rolling out a new continuous integration and delivery (CI/CD) process to deploy infrastructure and applications in Google Cloud Many teams will use their own instances of the CI/CD workflow It will run on Google Kubernetes Engine (GKE) The CI/CD pipelines must be designed to securely access Google Cloud APIs
What should you do?
- A . • 1 Create a dedicated service account for the CI/CD pipelines
• 2 Run the deployment pipelines in a dedicated nodes pool in the GKE cluster
• 3 Use the service account that you created as identity for the nodes in the pool to authenticate to the Google Cloud APIs - B . • 1 Create service accounts for each deployment pipeline
• 2 Generate private keys for the service accounts
• 3 Securely store the private keys as Kubernetes secrets accessible only by the pods that run the specific deploy pipeline - C . • 1 Create individual service accounts (or each deployment pipeline
• 2 Add an identifier for the pipeline in the service account naming convention
• 3 Ensure each pipeline runs on dedicated pods
• 4 Use workload identity to map a deployment pipeline pod with a service account - D . • 1 Create two service accounts one for the infrastructure and one for the application deployment
• 2 Use workload identities to let the pods run the two pipelines and authenticate with the service accounts
• 3 Run the infrastructure and application pipelines in separate namespaces
Correct Answer: C
C
Explanation:
To securely access Google Cloud APIs from CI/CD pipelines running on Google Kubernetes Engine (GKE), follow these steps:
Create Service Accounts:
Create individual service accounts for each CI/CD pipeline. This ensures isolation and minimal permissions per pipeline.
Use a naming convention that includes an identifier for each pipeline, such as pipeline-a-sa, pipeline-b-sa, etc.
Configure Kubernetes Service Accounts:
Create Kubernetes service accounts for each CI/CD pipeline pod.
Map Kubernetes Service Accounts to Google Service Accounts:
Use Workload Identity to associate Kubernetes service accounts with the corresponding Google service accounts. This allows the pods to authenticate to Google Cloud APIs securely.
Example command to bind the Kubernetes service account to the Google service account:
gcloud iam service-accounts add-iam-policy-binding –role roles/iam.workloadIdentityUser — member "serviceAccount:<PROJECT_ID>.svc.id.goog[<NAMESPACE>/<KSA_NAME>]" <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
Deploy CI/CD Pipelines:
Ensure each pipeline runs in dedicated pods that use the specific Kubernetes service accounts configured earlier.
This setup ensures that each pipeline has the necessary permissions to interact with Google Cloud APIs securely, adhering to the principle of least privilege.
Reference
Using Workload Identity
Managing Service Accounts
C
Explanation:
To securely access Google Cloud APIs from CI/CD pipelines running on Google Kubernetes Engine (GKE), follow these steps:
Create Service Accounts:
Create individual service accounts for each CI/CD pipeline. This ensures isolation and minimal permissions per pipeline.
Use a naming convention that includes an identifier for each pipeline, such as pipeline-a-sa, pipeline-b-sa, etc.
Configure Kubernetes Service Accounts:
Create Kubernetes service accounts for each CI/CD pipeline pod.
Map Kubernetes Service Accounts to Google Service Accounts:
Use Workload Identity to associate Kubernetes service accounts with the corresponding Google service accounts. This allows the pods to authenticate to Google Cloud APIs securely.
Example command to bind the Kubernetes service account to the Google service account:
gcloud iam service-accounts add-iam-policy-binding –role roles/iam.workloadIdentityUser — member "serviceAccount:<PROJECT_ID>.svc.id.goog[<NAMESPACE>/<KSA_NAME>]" <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
Deploy CI/CD Pipelines:
Ensure each pipeline runs in dedicated pods that use the specific Kubernetes service accounts configured earlier.
This setup ensures that each pipeline has the necessary permissions to interact with Google Cloud APIs securely, adhering to the principle of least privilege.
Reference
Using Workload Identity
Managing Service Accounts
Question #88
Your organization is rolling out a new continuous integration and delivery (CI/CD) process to deploy infrastructure and applications in Google Cloud Many teams will use their own instances of the CI/CD workflow It will run on Google Kubernetes Engine (GKE) The CI/CD pipelines must be designed to securely access Google Cloud APIs
What should you do?
- A . • 1 Create a dedicated service account for the CI/CD pipelines
• 2 Run the deployment pipelines in a dedicated nodes pool in the GKE cluster
• 3 Use the service account that you created as identity for the nodes in the pool to authenticate to the Google Cloud APIs - B . • 1 Create service accounts for each deployment pipeline
• 2 Generate private keys for the service accounts
• 3 Securely store the private keys as Kubernetes secrets accessible only by the pods that run the specific deploy pipeline - C . • 1 Create individual service accounts (or each deployment pipeline
• 2 Add an identifier for the pipeline in the service account naming convention
• 3 Ensure each pipeline runs on dedicated pods
• 4 Use workload identity to map a deployment pipeline pod with a service account - D . • 1 Create two service accounts one for the infrastructure and one for the application deployment
• 2 Use workload identities to let the pods run the two pipelines and authenticate with the service accounts
• 3 Run the infrastructure and application pipelines in separate namespaces
Correct Answer: C
C
Explanation:
To securely access Google Cloud APIs from CI/CD pipelines running on Google Kubernetes Engine (GKE), follow these steps:
Create Service Accounts:
Create individual service accounts for each CI/CD pipeline. This ensures isolation and minimal permissions per pipeline.
Use a naming convention that includes an identifier for each pipeline, such as pipeline-a-sa, pipeline-b-sa, etc.
Configure Kubernetes Service Accounts:
Create Kubernetes service accounts for each CI/CD pipeline pod.
Map Kubernetes Service Accounts to Google Service Accounts:
Use Workload Identity to associate Kubernetes service accounts with the corresponding Google service accounts. This allows the pods to authenticate to Google Cloud APIs securely.
Example command to bind the Kubernetes service account to the Google service account:
gcloud iam service-accounts add-iam-policy-binding –role roles/iam.workloadIdentityUser — member "serviceAccount:<PROJECT_ID>.svc.id.goog[<NAMESPACE>/<KSA_NAME>]" <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
Deploy CI/CD Pipelines:
Ensure each pipeline runs in dedicated pods that use the specific Kubernetes service accounts configured earlier.
This setup ensures that each pipeline has the necessary permissions to interact with Google Cloud APIs securely, adhering to the principle of least privilege.
Reference
Using Workload Identity
Managing Service Accounts
C
Explanation:
To securely access Google Cloud APIs from CI/CD pipelines running on Google Kubernetes Engine (GKE), follow these steps:
Create Service Accounts:
Create individual service accounts for each CI/CD pipeline. This ensures isolation and minimal permissions per pipeline.
Use a naming convention that includes an identifier for each pipeline, such as pipeline-a-sa, pipeline-b-sa, etc.
Configure Kubernetes Service Accounts:
Create Kubernetes service accounts for each CI/CD pipeline pod.
Map Kubernetes Service Accounts to Google Service Accounts:
Use Workload Identity to associate Kubernetes service accounts with the corresponding Google service accounts. This allows the pods to authenticate to Google Cloud APIs securely.
Example command to bind the Kubernetes service account to the Google service account:
gcloud iam service-accounts add-iam-policy-binding –role roles/iam.workloadIdentityUser — member "serviceAccount:<PROJECT_ID>.svc.id.goog[<NAMESPACE>/<KSA_NAME>]" <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
Deploy CI/CD Pipelines:
Ensure each pipeline runs in dedicated pods that use the specific Kubernetes service accounts configured earlier.
This setup ensures that each pipeline has the necessary permissions to interact with Google Cloud APIs securely, adhering to the principle of least privilege.
Reference
Using Workload Identity
Managing Service Accounts
Question #90
A customer needs to prevent attackers from hijacking their domain/IP and redirecting users to a malicious site through a man-in-the-middle attack.
Which solution should this customer use?
- A . VPC Flow Logs
- B . Cloud Armor
- C . DNS Security Extensions
- D . Cloud Identity-Aware Proxy
Correct Answer: C
C
Explanation:
DNSSEC ― use a DNS registrar that supports DNSSEC, and enable it. DNSSEC digitally signs DNS communication, making it more difficult (but not impossible) for hackers to intercept and spoof. Domain Name System Security Extensions (DNSSEC) adds security to the Domain Name System (DNS) protocol by enabling DNS responses to be validated. Having a trustworthy Domain Name System (DNS) that translates a domain name like www.example.com into its associated IP address is an increasingly important building block of today’s web-based applications. Attackers can hijack this process of domain/IP lookup and redirect users to a malicious site through DNS hijacking and man-in-the-middle attacks. DNSSEC helps mitigate the risk of such attacks by cryptographically signing DNS records. As a result, it prevents attackers from issuing fake DNS responses that may misdirect browsers to nefarious websites. https://cloud.google.com/blog/products/gcp/dnssec-now-available-in-cloud-dns
C
Explanation:
DNSSEC ― use a DNS registrar that supports DNSSEC, and enable it. DNSSEC digitally signs DNS communication, making it more difficult (but not impossible) for hackers to intercept and spoof. Domain Name System Security Extensions (DNSSEC) adds security to the Domain Name System (DNS) protocol by enabling DNS responses to be validated. Having a trustworthy Domain Name System (DNS) that translates a domain name like www.example.com into its associated IP address is an increasingly important building block of today’s web-based applications. Attackers can hijack this process of domain/IP lookup and redirect users to a malicious site through DNS hijacking and man-in-the-middle attacks. DNSSEC helps mitigate the risk of such attacks by cryptographically signing DNS records. As a result, it prevents attackers from issuing fake DNS responses that may misdirect browsers to nefarious websites. https://cloud.google.com/blog/products/gcp/dnssec-now-available-in-cloud-dns