Use IAM Roles Anywhere with per-device certificates for least-privilege EFS access and amazon-efs-utils on the devices
A company deploys an application on on-premises devices in the company’s on-premises data center. The company uses an AWS Direct Connect connection between the data center and the company's AWS account. During initial setup of the on-premises devices and during application updates, the application needs to retrieve configuration files from an Amazon Elastic File System (Amazon EFS) file system. All traffic from the on-premises devices to Amazon EFS must remain private and encrypted. The on-premises devices must follow the principle of least privilege for AWS access. The company's DevOps team needs the ability to revoke access from a single device without affecting the access of the other devices. Which combination of steps will meet these requirements? (Choose two.)
Community Votes
100% of anonymous learners picked answer BD. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Per-device certificates mapped through an IAM Roles Anywhere profile are what make revocation granular and least privilege: removing one certificate from the trust anchor or profile revokes only that device, and the role carries only the EFS client access policy rather than full administrative access (B). The amazon-efs-utils package supports mounting over a Direct Connect VPN using TLS, which satisfies the private and encrypted traffic requirement, whereas the native Linux NFS client carries the traffic in the clear over the network path (D versus E).
Three requirements apply: traffic must stay private and encrypted over the Direct Connect connection, each device must follow least privilege, and access must be revocable for a single device without affecting the others. Generating a certificate per device in AWS Private Certificate Authority, creating an IAM Roles Anywhere trust anchor and profile over a role with the AmazonElasticFileSystemClientReadWriteAccess managed policy, and using aws_signing_helper on the devices gives each device its own revocable temporary credentials scoped to EFS client access. Mounting with the amazon-efs-utils package keeps the traffic within the VPN and encrypted by EFS.
Creating one IAM user per device with the AmazonElasticFileSystemFullAccess policy (A) — long-lived IAM access keys per device violate least privilege, and the full-access policy grants far more than EFS client access. Using a single IAM user shared by all devices (C) — trungtd identified both failures: one shared credential cannot be revoked for a single device without affecting all of them, and it cannot demonstrate per-device identity. Using the native Linux NFS client (E) — NFS traffic is not encrypted, so the requirement that traffic remain private and encrypted is not met; amazon-efs-utils mounts EFS with TLS.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Three constraints shape the design. Least privilege and per-device revocation require a distinct, revocable identity per device rather than shared long-lived credentials, which is what per-device certificates in AWS Private Certificate Authority combined with an IAM Roles Anywhere trust anchor and profile provide: each device presents its own certificate, receives its own temporary credentials scoped to the role, and revoking that certificate revokes only that device. The role is granted the AmazonElasticFileSystemClientReadWriteAccess managed policy, which is exactly the EFS client access the devices need and nothing more, satisfying least privilege (B). Separately, the amazon-efs-utils package mounts EFS over TLS, so traffic traverses the Direct Connect connection encrypted, which the native Linux NFS client cannot do since NFS traffic is unencrypted (D). B and D are the correct combination.Why the Other Options Are Wrong
A creates an IAM user with an access key and secret key for each device, attaches the AmazonElasticFileSystemFullAccess policy, and configures the AWS CLI on the devices with those credentials. Long-lived IAM user keys distributed to devices are a poor security posture, and the full-access policy grants broad administrative permissions rather than the EFS client access the devices need, so least privilege is violated. C creates a single IAM user with keys for all devices and the AmazonElasticFileSystemClientReadWriteAccess policy. trungtd identified both defects: a single shared credential makes it impossible to revoke access for one device without affecting every other device, and it provides no per-device identity. E uses the native Linux NFS client to mount the file system, which carries the traffic unencrypted and therefore fails the requirement that all traffic from the on-premises devices to Amazon EFS remain private and encrypted; amazon-efs-utils achieves TLS for the mount. B and D are correct.Community Comment Notes
Community voted B,D unanimously. KaranNishad enumerated the B steps in full, from per-device certificates in Private CA through the trust anchor, the role with AmazonElasticFileSystemClientReadWriteAccess, and the profile consumed via aws_signing_helper. trungtd gave the decisive reasons for rejecting the alternatives: creating individual IAM users with full access does not follow least privilege, and using a single IAM user for all devices does not allow revoking access for one device. getadroit cited the AWS blog post on Amazon EFS on-premises access via Direct Connect and VPC, which describes exactly this amazon-efs-utils over VPN design. No alternative received support.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →