MENU
You are responsible for designing Service A, which must compose Services B and C. You are able to apply the necessary security mechanisms to ensure that messages exchanged by Service A comply with your security requirements. However, you are not given access to the design specifications for Services B and C. Based on the information that is published about Services B and C, you cannot guarantee that these services will provide the same level of security as Service A . This limitation was placed upon you as a result of the application of which service-orientation principle?
Suggested Answer: D
Get Premium S90.18 Questions
as Interactive Web-Based Practice Test or PDF
Real Exam Format
Detailed Explanations
Instant Access
Get Your Practice Test
47 comments · newest first
EL
Eladia
11 months ago
Surprised that we can't ensure security just because of abstraction!
VA
Valentine
11 months ago
I think it's Service Loose Coupling, but I'm not 100% on that.
BE
Beula
11 months ago
Wait, are we sure it's not Service Autonomy? Seems like a gray area.
BR
Brigette
11 months ago
Totally agree, abstraction means we can't guarantee security levels.
CH
Christa
12 months ago
It's definitely about Service Abstraction. Can't see the internals!
DE
Deane
12 months ago
I keep mixing up the principles, but I think Service Autonomy makes sense here because it highlights the independence of services in terms of design and security.
KA
Kati
1 year ago
I practiced a similar question about service dependencies, and I think the answer is Service Loose Coupling since it emphasizes independence between services.
JO
Josphine
1 year ago
I'm not entirely sure, but I feel like it could also be about Service Abstraction because we don't have full visibility into Services B and C.
CO
Corinne
1 year ago
I remember studying the principles of service orientation, and I think this might relate to Service Autonomy since I can't control the other services' security.
MA
Maryrose
1 year ago
I think the key here is the security aspect. Since we can't control the security of Services B and C, that suggests the principle of Service Abstraction. We're abstracting away the internal details of those services, which limits our ability to ensure consistent security.
MI
Mitzie
1 year ago
Okay, let me break this down. We have Service A that needs to compose Services B and C, but we can't guarantee the same level of security. This limitation is due to one of the service-orientation principles. I'm leaning towards Service Autonomy, since the services seem to be operating independently.
PU
Pura
1 year ago
Hmm, I'm a bit confused by this one. The question mentions security requirements, but it's not clear how that relates to the service-orientation principles. I'll need to think this through carefully.
CA
Carin
1 year ago
This question seems straightforward. I think the answer is Service Abstraction, since the question mentions that you're not given access to the design specifications for Services B and C, which is a key principle of service abstraction.
RO
Ronny
1 year ago
This is a tricky one. I'm not entirely sure, but I'm going to go with Service Abstraction. The question mentions that we're not given access to the design specifications, which seems to fit with the idea of abstracting away the internal details of the services.
GR
Graham
1 year ago
I'm a bit confused by the wording of the question. Are we looking for the "easiest" way, or the most efficient? I might need to review the documentation on the different loop options to make sure I'm choosing the right one.
RO
Rozella
2 years ago
Can we just glue Service A, B, and C together and call it a day? No security issues if there's no separation, right? Just kidding, I'm going with D. Service Abstraction, the only way to keep our sanity.
WH
Whitley
2 years ago
Definitely, Service Abstraction is key for maintaining security in this scenario.
CY
Cyndy
2 years ago
I think Service Abstraction is the best choice here. It keeps things separate and secure.
BR
Bronwyn
2 years ago
But what about Service Loose Coupling? Wouldn't that also help with security?
SC
Scot
2 years ago
Yeah, I agree. Service Abstraction is the way to go to maintain security.
JU
Junita
2 years ago
Wow, talk about a headache. Sounds like a trust fall exercise gone wrong. I'll go with D. Service Abstraction, but I might need a nap after this one.
PA
Patria
2 years ago
Definitely D, let's hope for the best with this design.
MY
My
2 years ago
Yeah, D seems like the best choice given the situation.
EM
Emile
2 years ago
I agree, this is a tough one. I think D makes the most sense too.
ST
Stephania
2 years ago
D) Service Abstraction
SE
Sean
2 years ago
C) Service Statelessness
DA
Dawne
2 years ago
B) Service Autonomy
DA
Dana
2 years ago
A) Service Loose Coupling
FR
Francoise
2 years ago
Hold up, did they say we can't access the design specs? That's like telling a mechanic to fix a car without letting them see the engine. Gotta be D. Service Abstraction, right?
OZ
Ozell
2 years ago
I think Service Abstraction makes more sense in this scenario.
AV
Avery
2 years ago
But what about Service Loose Coupling? Could that also be a factor?
SH
Shayne
2 years ago
Yeah, I agree. It's definitely Service Abstraction.
AJ
Aja
2 years ago
I'm not sure, but I think it could also be D) Service Abstraction, as it hides the complexity of the underlying services.
BA
Barrett
2 years ago
I agree with Bernardine, because Service Autonomy allows each service to control its own security.
BE
Bernardine
2 years ago
I think the answer is B) Service Autonomy.
GR
Gracia
2 years ago
Hah, talk about a trust issue! If I can't see under the hood, how can I be sure those other services are secure? I'm going with B. Service Autonomy on this one.
NA
Natalie
2 years ago
Definitely, Service Autonomy ensures that each service can control its own security measures independently.
OL
Ollie
2 years ago
Yeah, that's why I think Service Autonomy is the right choice here.
LO
Loreen
2 years ago
I agree, it's hard to trust the security of Services B and C without access to their design specifications.
DA
Daniela
2 years ago
I think the answer is D. Service Abstraction. We're not given access to the design specs for Services B and C, so we can't guarantee their security level. Abstraction is the way to go here.
TU
Tu
2 years ago
That makes sense. Service Abstraction is about hiding complexity, which fits our situation.
ED
Edelmira
2 years ago
Yes, Service Abstraction is the correct answer. It aligns with the limitation we are facing.
FR
Francoise
2 years ago
I agree with you. Service Abstraction makes sense in this scenario.
RE
Ressie
2 years ago
D) Service Abstraction
LO
Loise
2 years ago
C) Service Statelessness
FR
Franchesca
2 years ago
B) Service Autonomy
CA
Caren
2 years ago
A) Service Loose Coupling