1. Q1. A Dockerfile copies a deployment private key into the image, uses it during the build, and removes it with a later RUN instruction. The image is pushed to a registry. What is true of the published image?

   The key is gone, because the final layer no longer contains the file and the registry stores only the flattened result of the completed build The key is gone from the image but is still recorded in the build cache on the builder host, which is the only remaining exposure to clean up The key is present only if the image was built without BuildKit, which has been the default Linux builder since Docker v23.0 and strips removed files The key still ships: the removal is a whiteout marker in a later layer, and the earlier layer still carries the plaintext file

2. Q2. An application must encrypt several gigabytes of backups using a key management service. Which arrangement is the envelope-encryption pattern?

   Send each chunk of the backup to the key management service for encryption, so the service holds every ciphertext and the application holds none Export the key from the service into the application at start-up and cache it in memory, so that the service acts only as a distribution channel Generate a data key locally, encrypt the backup with it, ask the service to encrypt the data key, and store the wrapped data key beside the ciphertext Derive the data key from the backup contents with a hash function so that identical backups produce identical keys and the storage tier can still deduplicate them without contacting the service

3. Q3. Verifying a leaf against a root alone returns "error 20 at 0 depth lookup: unable to get local issuer certificate". Verifying the same leaf against the issuing intermediate alone returns "error 2 at 1 depth lookup: unable to get issuer certificate". What distinguishes the two results?

   Error 20 means the leaf has expired at depth 0, while error 2 means the intermediate has expired at depth 1, so both are validity-window failures Error 20 means the issuer of the leaf was not available to the verifier, while error 2 means a certificate deeper in the path has an issuer that is not trusted Error 20 is a hostname-matching failure and error 2 is a certificate-purpose failure, so both are checks that run only after a complete path has already been built from the supplied files Error 20 is emitted by the client and error 2 by the server, which is why two tools looking at the same chain can disagree about whether it validates

4. Q4. A client connects to api.example.com. The certificate it receives has a Common Name of api.example.com and a Subject Alternative Name listing only internal.example.com. Under RFC 9525, what must the client do?

   Accept the connection, because the Common Name still functions as a fallback whenever no SAN entry matches the requested name Accept the connection only if the Common Name is a character-for-character copy of one of the SAN entries present in the certificate Warn that the Common Name is deprecated and then continue, because RFC 9525 deprecated the fallback rather than removing it from the specification Reject the connection, because the Common Name must not be used to identify a service and no SAN entry matches

5. Q5. An ACME-issued certificate prints an empty subject line when inspected, and its Subject Alternative Name extension is marked critical. Which statement explains this correctly?

   The subject is an empty sequence, so RFC 5280 requires the SAN to be marked critical; identity lives entirely in the SAN The critical flag is an ACME convention signalling that the certificate was issued by automation rather than by a human operator working from a signing request The certificate is malformed, because a non-empty subject is mandatory in every end-entity certificate issued under the Baseline Requirements The SAN is critical because the certificate carries more than one DNS name, and any multi-name certificate must mark the extension critical

6. Q6. A CA operator proposes issuing publicly trusted TLS server certificates carrying anyExtendedKeyUsage, so that one certificate can also serve for client authentication and other purposes. What do the Baseline Requirements say?

   It is permitted, provided the certificate also carries serverAuth so that browsers continue to accept it for TLS It is forbidden: anyExtendedKeyUsage must not appear, serverAuth must be present, and clientAuth may be present It is required for any certificate that will be presented by both ends of a connection during a mutual TLS handshake between two services It is permitted only when the issuing intermediate also carries anyExtendedKeyUsage, so that the extended key usage set is consistent along the whole path

7. Q7. You are writing the issuance profile for publicly trusted TLS certificates in 2026. What is the maximum validity the Baseline Requirements currently allow, and what should the profile plan for?

   398 days today, dropping to 200 days at some point in 2027, so the profile should be shortened once that change has actually landed 90 days today, because that is the lifetime the largest issuer uses and the Baseline Requirements follow the largest issuer in practice 200 days today, dropping to 100 days on 2027-03-15 and 47 days on 2029-03-15, so plan renewal automation that survives all three 47 days today, because the earlier limits were withdrawn once the industry agreed a single short lifetime for every publicly trusted certificate regardless of issuer

8. Q8. A hardening ticket asks you to disable RSA key exchange in the TLS 1.3 cipher suite list on a fleet of web servers. What is wrong with the request?

   Nothing is wrong; TLS 1.3 suite names begin with the key exchange method, so removing the RSA suites is exactly the right change to make A TLS 1.3 suite name specifies only the AEAD algorithm and the hash, so key exchange is not selected by the suite list at all TLS 1.3 suite names specify the key exchange and the signature algorithm but not the AEAD, so the ticket should have named the AEAD it wants removed RSA key exchange cannot be disabled in TLS 1.3 because the protocol mandates it in order to remain backwards compatible with TLS 1.2 clients

9. Q9. A network team asks whether moving a service to TLS 1.3 will hide the requested hostname from a passive observer on the path. What is the accurate answer?

   No: ClientHello and ServerHello are cleartext, so the server name and the ALPN value stay visible unless Encrypted Client Hello is in use Yes: TLS 1.3 encrypts the entire handshake including the first flight, and that is the principal change from TLS 1.2 Yes, provided the server also enables certificate status stapling, which moves the certificate and the server name into the encrypted part of the exchange No, but only because the certificate is still sent in the clear; the server name itself has been encrypted by default since TLS 1.3 was first published

10. Q10. Two hosts fail against the same endpoint. Host A reports "unable to get local issuer certificate". Host B reports "no alternative certificate subject name matches target hostname". What do the two messages tell you?

    Both are trust-store problems; host B simply runs a newer client that words the same underlying failure differently Both are naming problems; host A fails on the issuer name and host B on the subject name, so one certificate reissue fixes both hosts at once Host A has a clock problem and host B has a name resolution problem, because a client reports both classes of failure under the same exit code Host A could not build a path to a trusted anchor, while host B built the path but the name it asked for is not in the certificate

11. Q11. A runbook step says to confirm a certificate has not been revoked by querying the OCSP responder named in its Authority Information Access extension. The certificate was issued by Let's Encrypt in 2026. What happens?

    The query returns good, which confirms the certificate is currently valid and was genuinely issued by the named authority The query returns unknown, which is the responder saying the certificate has been revoked but is not yet published in a CRL There is no OCSP URL to query: it was removed from the certificates in May 2025 and the responder was switched off in August 2025 The query succeeds but must be repeated with a nonce, because RFC 9654 made the nonce extension mandatory for every request made to a publicly trusted authority

12. Q12. A renewal script computes its renewal date as notBefore plus 60 days, assuming every certificate from the public CA is valid for 90 days. Why is that assumption unsafe in 2026?

    Lifetime depends on the requested profile and on scheduled changes to the default, so the script must read notAfter from the issued certificate The 90-day lifetime applies only to certificates issued through the DNS challenge, and HTTP challenge issuance has always produced a shorter certificate Lifetimes are configured per ACME account rather than per certificate, so the script has to query the account resource before every single renewal it performs The assumption is safe: 90 days is fixed by the ACME specification, and changing it would require a new protocol version to be published and adopted first

13. Q13. An estate renewing several thousand certificates under one registered domain keeps hitting the issuance rate limit. Which change actually resolves it?

    Spread issuance across several ACME accounts, since the limit is applied per account and each additional account brings its own separate allowance Adopt ACME Renewal Information so renewals follow the CA-supplied window, because ARI-coordinated renewals are exempt from the rate limits Request certificates carrying more names each, because the certificates-per-domain limit counts distinct names rather than certificates and consolidating lowers the count Move renewals to the DNS challenge, because the challenge type decides which rate-limit bucket an order is charged against and that bucket has a larger allowance

14. Q14. A team needs a wildcard certificate and wants to keep port 80 closed on every host in the estate. Which ACME challenge type satisfies both constraints?

    HTTP-01, provided the client is configured to answer the challenge on an alternative port behind a reverse proxy TLS-SNI-01, which validates over port 443 and is the only challenge type able to issue a wildcard certificate DNS-01, because it is the only challenge type that can issue a wildcard and it needs no inbound listener TLS-ALPN-01, which runs over port 443 using the acme-tls/1 application protocol and is the required challenge type for any wildcard issuance

15. Q15. A user certificate was signed without an explicit principals option, so its principals list is empty. Every tutorial the team found says an empty list means the certificate is valid for any principal. What is the behaviour on OpenSSH 10.3 and later?

    It is valid for any principal, exactly as the tutorials describe, because this behaviour has never changed across OpenSSH releases It is valid for any principal only when the server also sets an authorised principals file, which supplies the missing list at authentication time It is rejected at signing time, because ssh-keygen refuses to sign a user certificate carrying no principals unless it is given an explicit override flag It matches nothing, so the certificate authenticates nobody; an empty list stopped meaning any principal in OpenSSH 10.3

16. Q16. A deployment job disables strict host key checking to stop a prompt from blocking automation. The remote host key later changes because the host was rebuilt. What does that setting actually do in the changed-key case?

    It accepts the changed key and silently disables several authentication and forwarding features for that session It refuses the connection outright, because the option only suppresses the prompt for a host that has never been seen before by this client It accepts the changed key and writes it into the known_hosts file, which is why the next run of the same job succeeds without any prompt at all It has no effect at all, because checking of a changed key is governed by the host key update option rather than by strict host key checking in current releases

17. Q17. A Pod reads its projected ServiceAccount token from the mounted file at start-up and caches the string for the life of the process. What breaks, and when?

    Nothing breaks: the projected token is issued once during Pod admission and stays valid for as long as the Pod itself is running The cached token eventually expires, because the projected token is Pod-bound with a default one-hour lifetime and the kubelet rewrites the file The cached token stops working at the next control-plane restart, because these tokens are signed with an in-memory key that is regenerated whenever the API server process restarts The cached token is rejected immediately, because a projected token may only be presented by the process that originally opened the file descriptor

18. Q18. A team argues that giving each application its own Kubernetes namespace gives each application its own secrets. Which statement describes the isolation property that actually holds?

    It holds: the API server enforces per-Secret ownership, so a Pod can only mount the Secrets that its own controller created It holds for reads but not for writes, because role-based access control distinguishes get from create only at the cluster scope It does not hold: anyone who can create a Pod in the namespace can use that access to read any Secret in the namespace It holds provided encryption at rest is enabled, because the encryption key is derived per namespace by the KMS provider before objects are written to etcd

19. Q19. A module marks a database password variable as sensitive. A reviewer asks whether the password is therefore kept out of the state file. What is the correct answer, and what is the current mechanism if it must be?

    No: Terraform still records sensitive values in state, and keeping one out needs an ephemeral value or a write-only argument Yes: marking a value sensitive redacts it everywhere including the state file, which is why state can safely be stored without encryption No, but it does not matter in practice, because the object-storage backend encrypts state by default and the value is therefore unreadable at rest Yes for outputs and no for resource attributes, so marking the output sensitive is enough on its own to keep the password out of the state file entirely

20. Q20. A public repository runs integration tests on the pull_request_target event so the job can reach deployment credentials held as repository secrets. A contributor opens a pull request from a fork. What is the exposure?

    None: pull requests from forks never receive secrets, and pull_request_target is simply the modern spelling of the pull_request event The fork can reach the secrets only after a maintainer approves the run, which repository settings require by default in every configuration The exposure is limited to masked values in the log, because the platform redacts every secret and every encoding of it before the log is written The workflow runs with the base repository permissions and secret access, so code influenced by the fork can exfiltrate them

21. Q21. RFC 9846 obsoletes both RFC 8446 and RFC 5246, so a single current document is the normative reference for TLS 1.3 and for the remaining TLS 1.2 requirements.

    True False

22. Q22. Because RFC 9525 removed the Common Name fallback, a certificate authority is now forbidden from placing a Common Name in a TLS server certificate.

    True False

23. Q23. Enabling OCSP Must-Staple is the reliable way to make revocation enforceable for a publicly trusted TLS certificate.

    True False

24. Q24. The nextUpdate field of a certificate revocation list is the moment the CRL expires and must no longer be relied upon.

    True False

25. Q25. Renewals coordinated through ACME Renewal Information are exempt from the issuing authority rate limits.

    True False

26. Q26. Kubernetes Secrets are encrypted by default, which is why they are stored separately from ConfigMaps.

    True False

27. Q27. There is no Kubernetes API for revoking an individual ServiceAccount token.

    True False

28. Q28. Reading a Terraform output in JSON form prints values marked sensitive in clear text.

    True False

29. Q29. In the OpenBao release used by this course an audit device cannot be enabled through the API and must be declared in the server configuration file.

    True False

30. Q30. Deleting a secret file in a later container image layer removes it from the published image.

    True False

31. Q31. Which of the following are genuinely required for revocation to have an operational effect inside a private PKI? Select every option that applies.

    A CRL distribution point that every relying party is actually configured to fetch An OCSP Must-Staple extension present on every issued leaf certificate A relying-party configuration that fails closed when the CRL is missing or stale A public certificate transparency log entry for each revoked certificate

32. Q32. A long-lived cloud credential held by a CI system has leaked. Which of the following belong in the response? Select every option that applies.

    Revoke the credential at the provider before anything else Replace it with short-lived federated identity pinned to both the audience and the subject claim Add the credential to the secret-scanner allowlist so the alert stops firing during the incident Review the provider audit log for every call made with the credential since it was issued

33. Q33. Which statements about Kubernetes certificate and token handling are accurate? Select every option that applies.

    A CertificateSigningRequest in the stable certificates API must name a signer kubeadm rotates the cluster certificate authority as part of a normal upgrade The kubelet self-rotates its client certificate from its own PKI directory rather than being renewed by kubeadm A signer issues for the smaller of the requested duration and the configured signing duration, so a long-dated request is silently shortened

34. Q34. A production TLS private key has been copied off the host by an attacker. Explain why revocation is not the control that limits the damage, and name the controls that do.

35. Q35. An engineer proposes disabling certificate verification in a client as a temporary measure so a release can ship today. State what verification actually stops, and what you would offer instead.

36. Q36. Explain the dual-credential rotation pattern and why an instant replacement so often causes an outage.

37. Q37. A workload needs a credential in order to fetch its other credentials. Explain the secret zero problem and the shapes of solution that genuinely reduce it.

38. Q38. Diagnose this failure and state the remediation, the verification and the prevention.

    At 09:14 UTC the support channel reports that a mobile client and one partner integration cannot reach api.example.com, while every browser on the office network works and the service dashboards are green. The certificate was replaced two days ago as part of a routine renewal. A capture from a laptop shows a chain of length one. The operations engineer who performed the renewal reports that the deployment ran cleanly and that opening the site in a browser confirmed the new certificate.

39. Q39. Diagnose this failure and state the remediation, the verification and the prevention.

    A batch job that has run nightly for three years fails at 02:30 with a permission error from the database. The application was migrated to dynamic credentials last week. The team lead observes that the credential works when tested by hand at 09:00 and asks whether the database is rejecting connections outside business hours. The application reads its credential once during start-up and holds a connection pool open for the life of the process, which is restarted weekly.

40. Q40. Diagnose this failure and state the remediation, the verification and the prevention.

    A cloud access key with broad permissions has been found in a repository, committed 14 months ago in a file named for a test fixture. The repository is private but has 40 contributors, several forks inside the organisation, and a mirror used by a build system. A secret-scanning alert was raised nine months ago and dismissed with the note that the value was a test placeholder. The key is still active and is referenced by a workflow that deploys to production.

Passing score: 80%. Answers are checked in this browser.