Exams / SCS-C03 / Study guide / Encryption between nodes and services (EMR, EKS, SageMaker AI, Nitro)
Encryption between nodes and services (EMR, EKS, SageMaker AI, Nitro): SCS-C03 study notes and practice questions
What to know about Encryption between nodes and services (EMR, EKS, SageMaker AI, Nitro) for the SCS-C03 exam, from the Data Protection domain (18% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions ask how to protect data moving between parts of one workload, such as cluster nodes, training containers or pods. Each service has its own switch, and some traffic is encrypted without any setting. Know which is which before choosing.
Service controls
Amazon EMR uses a security configuration to turn on in-transit encryption between cluster nodes and at-rest encryption for local disks and for EMRFS data in S3. The security configuration is chosen when the cluster is created.
Amazon SageMaker AI training jobs offer inter-container traffic encryption for distributed training. You set it when you create the job. It is a deliberate option, not a default.
Nitro-based EC2 instances encrypt traffic between supported instances automatically, with no setting. Check the instance type list for the rule’s Region and instance family before relying on it.
Amazon EKS clusters on Kubernetes 1.28 or later encrypt all Kubernetes API data, including secrets, with envelope encryption by default, using an AWS owned key. Choose a customer managed KMS key when the scenario needs key control or audit. This protects data at rest in the control plane. It does not encrypt traffic between pods.
Pod-to-pod encryption needs application TLS or a service mesh that issues mutual TLS certificates. It is a design choice, not a KMS setting.
How to choose
Scenario wording
Pick
Encrypt traffic between EMR nodes and encrypt the cluster’s data at rest
EMR security configuration
Encrypt traffic between containers during distributed training
SageMaker AI inter-container traffic encryption
Encrypt traffic between pods in a cluster
Service mesh mutual TLS or application TLS
Kubernetes secrets must be encrypted under a key the company controls
EKS envelope encryption with a customer managed KMS key
Encrypt traffic between EC2 nodes with no configuration change
Nitro-based instances, after checking support
Common traps
Assuming EKS encrypts pod traffic because it encrypts secrets. Those are two separate controls.
Choosing a KMS key to fix network encryption. KMS encrypts data and keys. It does not encrypt packets.
Encrypting only in transit when the rule also says at rest. Both halves are needed, and each has its own setting.
Expecting an EMR security configuration to be added after launch. Plan it at cluster creation.
Assuming every instance pair gets Nitro encryption. It applies only between supported instance types on supported paths, so check before relying on it.
A health network runs nightly Apache Spark jobs on Amazon EMR over patient claims data. Compliance rules require that data be encrypted in transit between the cluster nodes and encrypted at rest on the storage attached to each node. The team cannot allow unencrypted traffic, even briefly, when a cluster starts.
The clusters are created from an automated template, and the security team wants the settings enforced for every cluster, not set by hand. The team holds its own TLS certificates in a private S3 bucket.
Which solution meets these requirements?
Choose one answer.
AA. Create an EMR security configuration with in-transit encryption using the certificates in the private bucket, and EBS at-rest encryption with a customer managed KMS key. Reference it from the cluster template.
BB. Turn on at-rest encryption only, using the default EBS encryption setting. Add a bootstrap action that installs TLS on each node after the cluster starts, so that in-transit encryption is ready before the first job runs.
CC. Place the cluster in private subnets with a security group that allows traffic only from the team's VPC. The private network path keeps the traffic off the internet, so no extra encryption setting is needed.
DD. Set the cluster to read and write all job data in Amazon S3 with SSE-S3, and rely on S3 encryption to protect traffic between the Spark nodes and the bucket.
Show the answer and explanation
Answer: A
A. Right: Correct. A security configuration applies the in-transit and at-rest settings when the cluster starts, so every cluster built from the template gets them. Referencing the configuration from the template enforces it without manual steps. Learn more: Data encryption in Amazon EMR (opens in a new tab)
B. Wrong: Bootstrap actions run after the cluster starts, so early traffic can be unencrypted, which the team forbids. Default EBS encryption covers the volumes, but it does not encrypt traffic between the nodes.
C. Wrong: Private subnets keep traffic off the internet, but they do not encrypt traffic between the nodes. The compliance rule names encryption in transit, so network placement alone does not meet it.
D. Wrong: SSE-S3 encrypts objects at rest in S3, not the traffic between Spark nodes, and it does not cover the EBS volumes on each node. This option covers only part of the requirement.
Explanation
EMR security configurations set in-transit and at-rest encryption together, and they apply when the cluster starts. Referencing one from the cluster template enforces it for every cluster. Bootstrap timing, network placement, and S3 encryption each cover only part of the compliance rule.
Want more on Encryption between nodes and services (EMR, EKS, SageMaker AI, Nitro)? The 5 full-length practice sets have 6 more Encryption between nodes and services (EMR, EKS, SageMaker AI, Nitro) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Encryption between nodes and services (EMR, EKS, SageMaker AI, Nitro)