Cert prep · Terraform Authoring and Operations Pro · AWS DevOps Engineer Pro (DOP-C02) · CKA · CKS
Secrets, trust and cluster hardening
Practice self-check. Answers stay in this page so you can grade yourself. This is not a scored exam.
Twelve questions. Objectives: Terraform Pro 2 and 6; DOP-C02 tasks 6.1, 6.2 and 6.3; CKA cluster architecture and servicing and networking; CKS cluster hardening, microservice vulnerabilities, supply chain and runtime security. Companion lab: Terraform lab 12, sensitive values and credentials.
Lab download.Starter is the tree you edit. Worked answer is a separate file; open it after the starter passes. Terraform exactly 1.10.5 and one download of hashicorp/aws 6.71.0. Mock provider: no credentials and no cloud spend. The starter's hx-lab12-not-a-real-key, hx-lab12-not-a-real-secret, and hx-lab12-change-me values are fake defaults the exercise tells you to remove. All lab requirements.
Q1 · Terraform Pro objective 2, sensitive outputs
A configuration declares the output db_connection_string with sensitive = true. A CI smoke-test step needs the plain-text string in a shell variable, without surrounding quotes, while the normal apply log must keep hiding it. From the CLI of the same working directory, which approach returns the value?
Answer: C. The -raw flag prints a string output value on its own, without quotes or formatting, which makes it suitable for assigning to a shell variable. Running terraform output with no name redacts sensitive outputs as <sensitive>, the apply summary also shows <sensitive> for the output, and the plan shows (sensitive value) for attributes derived from sensitive values. Source: output block reference, sensitive, https://developer.hashicorp.com/terraform/language/block/output; Use outputs to expose module data, Sensitive values in outputs, https://developer.hashicorp.com/terraform/language/values/outputs
Q2 · Terraform Pro objective 2, secrets and state
An auditor finds the database password in plain text inside the state object in S3, even though the variable and the output are both marked sensitive. The team's goal is to omit the value from state and plan files entirely, not merely to hide or encrypt it, and they run Terraform 1.11 or later. Which change meets the goal?
Answer: A. Ephemeral resources and write-only arguments are the documented way to use a secret without Terraform persisting it in state or plan files. The sensitive flag only redacts CLI output and the value is still stored in state, backend encryption only protects the stored object at rest, and state locking has no effect on which values are stored. Source: Manage sensitive data in your configuration (Omit values from state and plan files; Use write-only arguments), https://developer.hashicorp.com/terraform/language/manage-sensitive-data
Q3 · Terraform Pro objective 6, HCP Terraform dynamic credentials
An HCP Terraform workspace runs against AWS using a static access key stored as a sensitive workspace variable. Security wants short-lived credentials generated for each run and no long-lived AWS key stored anywhere. Which configuration meets this requirement?
Answer: D. Dynamic provider credentials use an OIDC trust between HCP Terraform and AWS so each run assumes the role and receives temporary credentials, with no stored key. Rotating the key, passing it through a provider-block variable and committing a credentials file all still rely on a long-lived access key stored in HCP Terraform or in the repository. Source: Use dynamic credentials with the AWS provider (Configure AWS; Configure HCP Terraform, required environment variables), https://developer.hashicorp.com/terraform/cloud-docs/dynamic-provider-credentials/aws-configuration
Q4 · DOP-C02 task 6.1, identity and access management at scale, SCPs
A new OU in AWS Organizations has an SCP that allows ec2:* and s3:*, and the default full-access SCP was removed from that OU. A role in a member account of the OU has no identity-based policies attached, and the buckets in the account have no bucket policies. What happens when the role calls s3:ListBucket?
Answer: B. SCPs only set the maximum permissions available, so an identity-based or resource-based policy must still grant the access. An SCP allow is not a grant, member-account roles have no implicit administrator rights, and SCPs attach to the root, OUs and accounts (not to roles) while still affecting the roles in those accounts. Source: Service control policies (SCPs), SCP effects on permissions, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
Q5 · DOP-C02 task 6.2, security controls and data protection, KMS rotation
A compliance rule requires the cryptographic material of a symmetric customer managed KMS key (origin AWS_KMS) to be rotated. The key encrypts S3 objects and EBS volumes. Applications must keep using the same key ID and ARN, and existing data must not be re-encrypted. What should the team do?
Answer: A. Automatic rotation generates new key material for the same KMS key, so the key ID and ARN stay the same and KMS keeps older material to decrypt older ciphertext. A new key has a different key ID and does not re-encrypt existing data, key material cannot be imported into a key with AWS_KMS origin, and a deleted key cannot be recreated with the same ID while data encrypted under it becomes undecryptable. Source: Rotate AWS KMS keys, How key rotation works, https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
Q6 · DOP-C02 task 6.3, security monitoring and auditing, CloudTrail
Auditors ask the team to prove, with evidence, that the CloudTrail log files delivered to S3 were not modified or deleted after delivery. The trail already delivers to a dedicated bucket. Which approach provides that proof?
Answer: C. Log file integrity validation writes signed digest files hourly, and validate-logs uses them to verify that log files were not changed or deleted. Versioning keeps old versions but gives no signed proof, Insights detects unusual API activity rather than file tampering, and a CloudWatch Logs delivery is just another copy with no validation. Source: Validating CloudTrail log file integrity, How it works, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html
Q7 · CKA cluster architecture, RBAC
A ClusterRole named secret-reader already exists. Developer dave must be able to read Secrets only in the development namespace, and the team wants to reuse that one ClusterRole rather than copy its rules into a new Role. Which approach meets this?
Answer: B. A RoleBinding may reference a ClusterRole, and the permissions are then granted only inside the RoleBinding's own namespace. A ClusterRoleBinding grants cluster-wide and is not namespaced, a RoleBinding in default only grants within default, and ClusterRole rules have no namespace field. Source: Using RBAC Authorization, RoleBinding and ClusterRoleBinding, https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding
Q8 · CKA servicing and networking, NetworkPolicy
Namespace db has a NetworkPolicy that selects the database Pods. Ingress must be allowed only from Pods labelled role=client that are running in namespaces labelled user=alice. Which shape of the ingress.from rule does this?
Answer: D. When namespaceSelector and podSelector sit in the same from entry, they are combined, selecting the matching Pods in the matching namespaces. Two separate entries are ORed (any Pod in alice's namespaces, or role=client Pods in the policy's own namespace), a lone podSelector only matches Pods in the policy's namespace, and a node CIDR ipBlock does not select Pods by label. Source: Network Policies, NetworkPolicy resource (namespaceSelector and podSelector), https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource
Q9 · CKS cluster hardening, ServiceAccount tokens
A Deployment's Pods never call the Kubernetes API, but every Pod mounts a ServiceAccount token that an attacker with shell access could use. The ServiceAccount is shared with other workloads that do need the token, so it must not be changed in a way that affects them. What is the correct fix?
Answer: A. The Pod spec value of automountServiceAccountToken takes precedence over the ServiceAccount's value, so only these Pods stop mounting the token. Setting it on the shared ServiceAccount affects the other workloads that need the token, deleting RoleBindings removes permissions but the token is still mounted, and a read-only root filesystem does not stop the token volume mounted at /var/run/secrets/kubernetes.io/serviceaccount. Source: Configure Service Accounts for Pods, Opt out of API credential automounting, https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting
Q10 · CKS minimize microservice vulnerabilities, Pod Security Admission
Namespace prod currently has no Pod Security Admission labels. Policy says Pods that violate the baseline standard must be rejected, while Pods that violate restricted must still be admitted but show a warning to the user who creates them. Which labels implement this?
Answer: D. The enforce mode rejects violating Pods and the warn mode only returns a user-facing warning, so each standard is paired with the right mode. The audit mode never rejects Pods, enforce: restricted rejects restricted violations, and the privileged level allows everything so nothing is rejected. Source: Pod Security Admission, Pod Security Admission labels for namespaces, https://kubernetes.io/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces
Q11 · CKS supply chain security, image digests
CI scans registry.example.com/edge/api:1.4 and the build passes, but the registry owner could later push a different image to the same tag. The Pod spec must run exactly the scanned content every time a container starts, on any node. What should the team do?
Answer: B. An image digest identifies exact content, so the container runtime can only run that content regardless of what the tag points to later. With Always the node pulls whatever the tag points to now, the latest tag is just another movable tag, and with IfNotPresent a node that already holds a different image under that tag keeps running it. Source: Images, Image names and Image pull policy (digests), https://kubernetes.io/docs/concepts/containers/images/#image-names
Q12 · CKS monitoring, logging and runtime security, audit policy
The cluster's audit policy must record who created, updated or read Secrets and when, but must not write Secret contents (request or response bodies) into the audit log. Rules are evaluated in order and the first matching rule sets the audit level. Which rule meets this?
Answer: C. The Metadata level logs request metadata such as user, timestamp and resource, but not request or response bodies, and an earlier position makes it win over broader rules. RequestResponse logs both bodies, Request logs the request body which holds the Secret data on create and update, and None records nothing at all. Source: Auditing, Audit policy (audit levels), https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/#audit-policy