Text preview & study summary
Google Cloud Professional Security Network DevOps Engineer - Security GKE CICD SRE Networking
A free sample of 5 questions from this quiz, shown in full with answer choices and explanations. No interactivity — everything is visible on this page for study and review.
Want to test your knowledge? Launch the Interactive Exam Simulator
Question 1
A Kubernetes deployment on GKE stores database passwords as environment variables hardcoded in the container image. A security audit flags this as a critical vulnerability. What is the recommended remediation?
Explanation
Hardcoded secrets in container images are a critical security risk (secrets in version control, container registries). Remediation: (1) Kubernetes Secrets store sensitive data and inject them as environment variables or volume mounts at pod startup — not in the image. (2) Better: Google Secret Manager with Workload Identity — secrets stored in Secret Manager, accessed programmatically using the pod's service account identity (no static credentials). ConfigMaps are for non-sensitive configuration. A private registry protects the image but the secret is still inside it. Environment variables in images are visible via `docker inspect`.
Question 2
An SRE team uses error budgets. Their SLO is 99.5% availability over a 30-day period. After 15 days, they've used 80% of their monthly error budget. Which SRE action is most appropriate?
Explanation
Error budget management: 99.5% SLO over 30 days = 0.5% failure allowed = ~216 minutes. 80% consumed in 15 days means the team is burning budget twice as fast as planned (on track to exhaust in ~4 more days). SRE principle: when error budget is nearly exhausted, halt risky activities (new feature deployments) and focus engineering capacity on reliability improvements. This protects the remaining budget and prevents SLO breach. Continuing normal operations risks exhausting the budget. Lowering the SLO is a business decision, not a reactive fix. Disabling monitoring is counterproductive.
Question 3
A cloud network engineer implements Cloud NAT for a private subnet. After configuration, VMs can reach the internet but the engineer notices some long-lived connections (database backups) are being dropped. What should be adjusted?
Explanation
Cloud NAT maintains a connection tracking table with idle timeouts. Long-lived TCP connections (database backups, large file transfers) that have no activity for extended periods hit the idle timeout and are dropped. Increasing the `TCP Established connection idle timeout` (default: 1200 seconds / 20 minutes) prevents premature dropping of legitimate long-lived connections. Minimum ports per VM affects how many concurrent connections a VM can maintain (relevant for high-concurrency workloads). Static NAT mapping doesn't exist in Cloud NAT. Disabling Cloud NAT eliminates the security posture.
Question 4
A company's GKE cluster was recently updated and pods are failing to pull images from Artifact Registry. The error shows `Failed to pull image: unauthorized`. What is the most likely cause?
Explanation
GKE nodes use their node service account to pull container images from Artifact Registry. The `unauthorized` error indicates the service account doesn't have permission to read from the registry. Solution: grant `roles/artifactregistry.reader` to the GKE node service account on the Artifact Registry repository (or project). If the registry is in a different project, grant the role cross-project. The API being disabled would produce a different error. Invalid tags produce "not found" errors. Cross-project registries work but require explicit IAM grants (which is essentially this same fix).
Question 5
A security engineer needs to ensure that service account keys are never created manually by any user in the organization. Which control prevents this?
Explanation
Organization Policy constraints enforce governance rules at the organization, folder, or project level, preventing policy violations regardless of IAM permissions. The `constraints/iam.disableServiceAccountKeyCreation` constraint blocks API calls that would create user-managed service account keys for all projects under the policy. IAM deny policies are more granular per-principal. SCC detects issues but doesn't prevent them. VPC-SC restricts API access by network perimeter, not key creation specifically.
